rich1.0npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8https://nostr.ae/npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8njumphttps://nostr.ae📅 Original date posted:2015-12-08 📝 Original message:On Wed, Dec 9, 2015 at 12:59 AM, Gregory Maxwell via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote: > On Tue, Dec 8, 2015 at 3:12 PM, Gavin Andresen via bitcoin-dev > <bitcoin-dev at lists.linuxfoundation.org> wrote: > We already have consensus critical enforcement there, the height, > which has almost never been problematic. (A popular block explorer > recently misimplemented the var-int decode and suffered an outage). It would be also a nice opportunity to move the height to a more accessible place. For example CBlockHeader::hashMerkleRoot (and CBlockIndex's) could be replaced with a hash of the following struct: struct hashRootStruct { uint256 hashMerkleRoot; uint256 hashWitnessesRoot; int32_t nHeight; } > From a risk reduction perspective, I think it is much preferable to > perform the primary change in a backwards compatible manner, and pick > up the data reorganization in a hardfork if anyone even cares. But then all wallet software will need to adapt their software twice. Why introduce technical debt for no good reason? > I think thats generally a nice cadence to split up risks that way; and > avoid controversy. Uncontroversial hardforks can also be deployed with small risks as described in BIP99.