📅 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.
Jorge Timón [ARCHIVE] /
npub1fx…cl2d8
2023-06-07 17:45:40
in reply to nevent1q…eetq
Author Public Key
npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8Published at
2023-06-07 17:45:40Event JSON
{
"id": "1578394baac7273aee34fb0c0a773f7fbe265423d791a069deeb12f3a9f86a07",
"pubkey": "498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84",
"created_at": 1686159940,
"kind": 1,
"tags": [
[
"e",
"558b0da1f3869961bbef0556878e1dd6b9ae37e86128bc130bab17f5332c918d",
"",
"root"
],
[
"e",
"0e1105741ee1b56b8afacc84091d5f8273e21dd96323b449a9de0e8a24fc1619",
"",
"reply"
],
[
"p",
"4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73"
]
],
"content": "📅 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.",
"sig": "6a99782af2a44513e1073c15f5b9202e245cb9698d617506ca57d35f9fdefbcd8462f177bb52f15c10b3d49fdfd29dc84d8b6258328dd8aa07d48ea68d7361cf"
}