{"type":"rich","version":"1.0","author_name":"npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8","author_url":"https://nostr.ae/npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-12-08\n📝 Original message:On Wed, Dec 9, 2015 at 12:59 AM, Gregory Maxwell via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e On Tue, Dec 8, 2015 at 3:12 PM, Gavin Andresen via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e We already have consensus critical enforcement there, the height,\n\u003e which has almost never been problematic. (A popular block explorer\n\u003e recently misimplemented the var-int decode and suffered an outage).\n\nIt would be also a nice opportunity to move the height to a more\naccessible place.\nFor example CBlockHeader::hashMerkleRoot (and CBlockIndex's) could be\nreplaced with a hash of the following struct:\n\nstruct hashRootStruct\n{\nuint256 hashMerkleRoot;\nuint256 hashWitnessesRoot;\nint32_t nHeight;\n}\n\n\u003e From a risk reduction perspective, I think it is much preferable to\n\u003e perform the primary change in a backwards compatible manner, and pick\n\u003e up the data reorganization in a hardfork if anyone even cares.\n\n\nBut then all wallet software will need to adapt their software twice.\nWhy introduce technical debt for no good reason?\n\n\u003e I think thats generally a nice cadence to split up risks that way; and\n\u003e avoid controversy.\n\nUncontroversial hardforks can also be deployed with small risks as\ndescribed in BIP99."}