From b75238ffb3059fa1857f1858f9bc99f8cbf7ea67 Mon Sep 17 00:00:00 2001 From: Antoine Poinsot Date: Thu, 21 May 2026 10:04:45 -0400 Subject: [PATCH] bip-0054: rephrase/dedup motivation and rationale for BIP 34 cleanup The rationale was duplicating some of the motivation. The motivation had a sentence that read weird. While rephrasing the sentence, take the opportunity to link to the now-proposed Utreexo BIP. Also remove a duplicate link reference. --- bip-0054.md | 32 ++++++++++++-------------------- 1 file changed, 12 insertions(+), 20 deletions(-) diff --git a/bip-0054.md b/bip-0054.md index 8eaf1073..133d92de 100644 --- a/bip-0054.md +++ b/bip-0054.md @@ -45,12 +45,10 @@ any other user of Merkle proofs, to rely on one of the available workarounds[^13 necessary in the first place. Since [bip-0034][BIP34] activation, explicit [bip-0030][BIP30] validation is not necessary until -block height 1,983,702[^0]. Mandating new coinbase transactions be different from the early -[bip-0034][BIP34] violations makes it possible to get rid of [bip-0030][BIP30] validation forever. -Besides its unnecessary cost, another downside of [bip-0030][BIP30] validation is that it cannot be -performed by Utreexo clients. Finally, leveraging the coinbase transaction's `nLockTime` field -allows applications to recover the block height corresponding to a coinbase transaction without -having to parse Script. +block height 1,983,702[^0]. Resuming [bip-0030][BIP30] validation would unnecessarily increase block +validation overhead and preclude alternative full node designs (such as [bip-0182][BIP182] Utreexo). +Enforcing that new coinbase transactions are different from the early [bip-0034][BIP34] violations +makes it possible to get rid of [bip-0030][BIP30] validation forever. ## Specification @@ -114,17 +112,13 @@ invalidating 64-byte transactions, fixing the vulnerability without Merkle proof rely on any workaround or even know one is necessary in the first place. See [this post][64 bytes debate] for an attempt at summarizing the arguments for both sides of this debate. -Several blocks prior to [bip-0034][BIP34] activation contain a coinbase transaction whose scriptSig -contains a valid [bip-0034][BIP34] commitment to a future block height. This offers an opportunity -to duplicate these coinbase transactions in the future[^10] and for this reason [bip-0030][BIP30] -validation will need to be re-activated from block 1,983,702. A simple way to prevent this is to -mandate that future coinbase transactions vary from coinbase transactions before [bip-0034][BIP34] -activation. There are multiple ways of achieving this, but setting and enforcing the timelock for -the coinbase transaction makes it so all coinbase transactions past Consensus Cleanup activation -could not have been valid before this height and therefore cannot be a duplicate[^11]. This -simplifies both reasoning and client implementation, since the [bip-0030][BIP30] check can be -skipped entirely past Consensus Cleanup activation, regardless of the [bip-0034][BIP34] activation -status[^12]. +The `nLockTime` field of transactions is a natural place to store a block height and is currently +unused in coinbase transactions. Using it to enforce that new coinbase transactions differ from +early [bip-0034][BIP34] violations also allows applications to recover the block height without +having to parse Script. Leveraging the existing timelock mechanism makes the check self-contained: +the same coinbase transaction cannot have been valid in a previous block[^11]. This simplifies both +reasoning and client implementation, since the [bip-0030][BIP30] check can be skipped entirely past +Consensus Cleanup activation, regardless of the [bip-0034][BIP34] activation status[^12]. ## Backward compatibility @@ -215,8 +209,6 @@ implemented caching that made it vulnerable to this attack. See [this writeup][S Suhas Daftuar for a detailed explanation. Invalidating 64-byte transactions may avoid this risk, but the issue is largely orthogonal to this proposal: it is fundamentally about caching validation status for malleable blocks. -[^10]: See [here][BIP34 list] for a full list of the heights of historical blocks including a valid -bip-0034 height commitment and the corresponding future block height. [^11]: Technically it could be argued a duplicate could in principle always be possible before block 31,001 when `nLockTime` enforcement [was originally soft-forked][Harding nLockTime]. But treating coinbase transactions as not having duplicate past Consensus Cleanup activation would be consistent @@ -236,6 +228,7 @@ MERKLEBLOCK] for a full description. [Delving worst block]: https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/93 [BIP30]: https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki +[BIP182]: https://github.com/bitcoin/bips/pull/1923 [BIP-XXXX]: https://github.com/TheBlueMatt/bips/blob/7f9670b643b7c943a0cc6d2197d3eabe661050c2/bip-XXXX.mediawiki [BIP34]: https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki [BIP16 specs]: https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki#specification @@ -251,7 +244,6 @@ MERKLEBLOCK] for a full description. [Sergio post]: https://bitslog.com/2018/06/09/leaf-node-weakness-in-bitcoin-merkle-tree-design [Sergio MERKLEBLOCK]: https://bitslog.com/2018/08/21/simple-change-to-the-bitcoin-merkleblock-command-to-protect-from-leaf-node-weakness-in-transaction-merkle-tree/ [64 bytes debate]: https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/41 -[BIP34 list]: https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/4 [Harding nLockTime]: https://bitcoin.stackexchange.com/questions/90229/nlocktime-in-bitcoin-core [Delving duplicable]: https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/4 [Core 0.16.1]: https://bitcoincore.org/en/releases/0.16.1