There are many locations in the codebase where block height values are used, even more so with Freicoin which introduces consensus-critical reference heights, which don't exist in bitcoin. In the original satoshi code, heights were simple signed int values, which on all supported platforms at the time were 32 bits in length. This unfortunately wasn't officially clarified when the type used for height storage became consensus critical with BIP34 ("height in the coinbase"). With Freicoin we used explicitly sized int32_t types for ref height storage, since with 10 minute blocks on average the field won't overflow for some 40,000 years.
However the introduction of protocol cleanup and potential future forward blocks scaling could change this. Once the protocol cleanup rules activate, which is always about 2+ years away, the block rate could be anything. And with forward blocks, compatibility blocks could even safely arrive with less than a second separation, which would exhaust the 32-bit range of the refheight field within a humanly relatable amount of time. Unlike bitcoin we don't anticipate going this route since we also have the option of increasing block size. But we shouldn't pre-maturely tie our hands; we should fix the height-field overflow issue so there isn't ever a future point (in 10 years time or in 40,000 years) where the chain goes haywire because lock heights and reference heights wrap around to negative numbers or zero.
The imminent release of v13 adds some urgency because yet another point is introduced where the consensus code depends on storage of height values: segwit inputs sign the input value, which in Freicoin must also include the reference height (the lock_height of the prior transaction).
This issue should track the extension of all consensus-critical height or timestamp fields to be of sufficient size as to work for millennia into the future, even in the face of protocol upgrades in line with what has been proposed before (e.g. the six-blocks-per-second forward blocks proposal presented at Scaling Bitcoin). Ideally this is accomplished by upgrading all absolute time or height fields to be 64 bits, but in some cases (e.g. the timestamp in the block header) it difficult to find more than a few extra bytes. Extending by even a single high-order byte moves the issue from decades to millennia away, however, which is sufficient for our design requirements.
There are many locations in the codebase where block height values are used, even more so with Freicoin which introduces consensus-critical reference heights, which don't exist in bitcoin. In the original satoshi code, heights were simple signed
intvalues, which on all supported platforms at the time were 32 bits in length. This unfortunately wasn't officially clarified when the type used for height storage became consensus critical with BIP34 ("height in the coinbase"). With Freicoin we used explicitly sizedint32_ttypes for ref height storage, since with 10 minute blocks on average the field won't overflow for some 40,000 years.However the introduction of protocol cleanup and potential future forward blocks scaling could change this. Once the protocol cleanup rules activate, which is always about 2+ years away, the block rate could be anything. And with forward blocks, compatibility blocks could even safely arrive with less than a second separation, which would exhaust the 32-bit range of the refheight field within a humanly relatable amount of time. Unlike bitcoin we don't anticipate going this route since we also have the option of increasing block size. But we shouldn't pre-maturely tie our hands; we should fix the height-field overflow issue so there isn't ever a future point (in 10 years time or in 40,000 years) where the chain goes haywire because lock heights and reference heights wrap around to negative numbers or zero.
The imminent release of v13 adds some urgency because yet another point is introduced where the consensus code depends on storage of height values: segwit inputs sign the input value, which in Freicoin must also include the reference height (the
lock_heightof the prior transaction).This issue should track the extension of all consensus-critical height or timestamp fields to be of sufficient size as to work for millennia into the future, even in the face of protocol upgrades in line with what has been proposed before (e.g. the six-blocks-per-second forward blocks proposal presented at Scaling Bitcoin). Ideally this is accomplished by upgrading all absolute time or height fields to be 64 bits, but in some cases (e.g. the timestamp in the block header) it difficult to find more than a few extra bytes. Extending by even a single high-order byte moves the issue from decades to millennia away, however, which is sufficient for our design requirements.