bitcoin/bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2026-06-01 17:15:27 +00:00
Code Issues Releases Wiki Activity

bip-0054: rephrase/dedup motivation and rationale for BIP 34 cleanup

Browse Source 
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.
This commit is contained in:
Antoine Poinsot
2026-05-21 10:04:45 -04:00
parent ec24fd371c
commit b75238ffb3
1 changed files with 12 additions and 20 deletions
Download Patch File Download Diff File Expand all files Collapse all files

32
bip-0054.md
View File

@@ -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