Hello everyone, this is broken into two parts: the first for "everyone" and the second for bitdevs. I want to start a BIP discussion but I'm not sure where the best place is, so here goes...

Thanks and have a nice day,

--

Layer: Applications Status: Draft

Bitcoin defines the halving cycle as 210,000 blocks, as defined in the file kernel/chainparams.cpp. This number was apparently chosen as an aesthetically pleasing number which equates almost exactly to 4 years, according to the ten-minute block schedule. This BIP proposes using this parameter of Bitcoin as the basis for reckoning calendar time, defined as follows.

nBlocksPerYear = 210000 / 4 // calculates to 52,500 nBlocksPerMonth = nBlocksPerYear / 12 // calculates to 4375

The calculations above produce integer results, making calendrical calculations based on block height extremely convenient. The zero-based year and month are calculated as follows, using integer division (/) and mudulo (%) based on block height h:

year = h / 52500 month = (h % 52500) / 12

Furthermore, we assume a bitcoin day length of 144 blocks. This is consistent with the target of 10-minutes per block and the 2016 blocks every two weeks for the difficulty adjustment period. This results in months of 30 days, with a small remainder:

nBlocksPerDay = 144 daysPerMonth = nBlocksPerMonth / nBlocksPerDay // calculates to 30.something

A human-friendly date can thus be displayed based upon block height, with familiar calendrical characteristics of 30 full days per month (with a partial day 31) and 12 months per year. As of this writing, the current bitcoin date is 7/24/17, 24-07-0017, or the twenty fourth day of the seventh month of the seventeenth year of Bitcoin.

This definition forms the basis for a culturally independent and socially universal calendar system which is easy to calculate, durable, and financially relevant.

Since this date will not synchronize exactly to extant calendar systems, a notation needs to be used in cases where ambiguity would result. Taking the solar day as the example, references that cross over between the solar day and the bitcoin date need to have a qualifier resolving the phase discrepancy (as is done when referring to dates in ancient calendar systems that do not align with the turn of the date at midnight). For example, the Bitcoin date of 7/24/17 would be written as November 9/10, 2024, making it clear that it touches both of those solar days. However, this format should only be used for dates in which the two calendar systems are more out of sync than in sync. For dates that are more in sync than out of sync, no overlap day should be given, because it would add ambiguity where there otherwise was none.

Layer: Consensus Status: Draft

The Bitcoin calendar (referring to the prior definition) would be more economically relevant to earthlings if the Bitcoin year actually stayed synchronized with the growing seasons of the tropical year. Currently, the Bitcoin year begins in the springtime of the northern hemisphere, but it is offset one year and there is currently nothing to keep the bitcoin year from drifting further out of synchronization with the tropical year.

To keep the Bitcoin year in sync with the seasons, the bi-weekly proof-of-work difficulty adjustment could be tailored to aim toward better alignment during every difficulty adjustment. Normally, the difficulty is adjusted upward or downward a maximum factor of 4, as defined in the file pow.cpp. The determination of the value within that range is made solely on the basis of the rate of block discovery during the prior 2016-block (two-week) period.

The existing difficulty adjustment scheme has resulted in the Bitcoin calendar generally sliding earlier every year, presumably due to the fact that the global hash rate is generally increasing rather than decreasing. The historical dates for the year beginnings and the corresponding duration of the Bitcoin year are as follows:

As can be seen, the number of days in the actual Bitcoin year are consistently fewer than the number of days in the tropical year (365.2425). Assuming the hash rate will generally continue to increase, this trend should continue, which allows us to make a convenient simplifying assumption.

Conceptually this proposal seeks to add an additional, limited offset to the work requirement based on whether the Bitcoin calendar is ahead of schedule or behind schedule, in comparison to the tropical year. We can assume based on the trends, however, that we only need to "slow down" the block rate slightly to keep it in sync with the seasons. Therefore, this proposal aims to do only that.

If the Bitcoin block height is a certain amount ahead of the calendar synchronization goal (per the trend), the difficulty would be increased one notch more than required by the normal calculation, if not already at the limit of adjustment for that period. This would make it impossible for the proposed change to overpower the existing calculation, but would still provide a gentle enough push when needed to keep the calendar in sync, thus accomplishing the purpose.

A consensus change to the proof of work calculation would normally result in a hard fork. However, in the case that we only potentially increase the difficulty and never decrease it relative to non-upgraded nodes in the network, this means that during the transition, only upgraded nodes would be at risk of rejecting blocks for not meeting the more stringent difficulty level necessary to synchronize the calendar.

The new nodes would therefore need to be programmed to yield to the non-upgraded difficulty criteria until most of the network has upgraded, at which point activation would occur (as explained below) and miners would be obliged to meet the tougher requirements demanded by all upgraded nodes. Nodes that still had not upgraded by that time would remain unaffected, since the post-activation blocks would only have more proof of work, and not less, than non-upgraded nodes require.

More importantly, an overwhelming majority of the hash rate should be fully upgraded to avoid a situation where non-upgraded, non-mining nodes are forked by a longer chain created by non-upgraded miners. A sufficient portion of the hash rate following the upgrade path would eliminate this possiblity, even for non-mining nodes that don't upgrade, because the longer chain will come from the greater hash power and there would be no financial incentive for miners to switch back to catering to a minority of non-upgraded nodes.

Upgraded nodes would delay the relaying of blocks that do not meet the more stringent requirements. This would begin as a confirmation-time penalty to upgraded nodes, but as the upgrade expands to more nodes, the effect would shift to incentivizing miners to produce blocks that conform to the upgrade in order to build on the longest chain faster.

For the longer term, it might be advisable to also implement the corresponding opposite influence on the proof of work adjustment for the case where the simplifying assumption taken above does not hold. In other words, if hash rate were to take on a trend of decreasing over a significant period of time at some point in the future leading to a Bitcoin year length greater than 365 days, the calendar drift would ideally be pushed in the other direction by a relaxing influence on the proof of work requirement instead of a tightening influence. Since this would definitely result in a hard fork relative to un-upgraded nodes, this feature, if implemented, would need to be kept inactive for much longer, and only activated if/when the number of non-upgraded nodes becomes so insignificant that a hard fork is no longer a concern.

END