From 19caed45a190aee8a0e7792d8e819d6de6ee5ae6 Mon Sep 17 00:00:00 2001 From: Antoine Poinsot Date: Wed, 20 May 2026 16:41:18 -0400 Subject: [PATCH 1/4] bip-0054: rephrase Timewarp motivation --- bip-0054.md | 18 ++++++++---------- 1 file changed, 8 insertions(+), 10 deletions(-) diff --git a/bip-0054.md b/bip-0054.md index 7eb277f02f..efdc08669b 100644 --- a/bip-0054.md +++ b/bip-0054.md @@ -21,16 +21,14 @@ case block validation time, prevent Merkle tree weaknesses, and avoid duplicate This proposal addresses a number of long-standing vulnerabilities and weaknesses in the Bitcoin protocol. Bundling these fixes together amortizes the fixed cost of deploying a Bitcoin soft fork. -The timewarp bug permits a majority hashrate attacker to arbitrarily increase the block rate, -allowing them to steal block subsidy from future miners and increase validation costs to nodes that -have to deal with the increased average transaction rate. By strategically setting the block -timestamp, the [timewarp bug][SE timewarp] lets miners bring down the difficulty to its minimum -within 38 days of starting the attack. The existence of this bug not only significantly empowers a -51% attacker, but also makes it notably harder to reason about miners' incentives. It could indeed -be in the interest of short-sighted miners as well as short-sighted users to exploit this -vulnerability in a small enough proportion to increase the block rate without fatally hurting the -network, as the effectively increased block space would — all other things being equal — bring fee -rates down for users. +The [timewarp bug][SE timewarp] makes it possible for a majority-hashrate attacker to arbitrarily +lower mining difficulty, and therefore arbitrarily increase the block rate. In the worst case, an +attacker can bring down the difficulty to its minimum within 38 days of starting the attack. Besides +empowering a 51% attacker, the presence of this bug makes it harder to reason about miners' +incentives. Accelerating the block rate allows an attacker to steal block subsidy from future +miners and increases available block space. It may be in the interest of short-sighted users and +miners to exploit this vulnerability to materially increase the block rate without fatally hurting +the network. Specially crafted blocks may be expensive to process, with validation times ranging from a few minutes up to more than an hour on lower-end devices. Long block validation times are a nuisance to From ec24fd371cd8cf1aabe3afcc63385155dea5c00d Mon Sep 17 00:00:00 2001 From: Antoine Poinsot Date: Thu, 21 May 2026 10:54:23 -0400 Subject: [PATCH 2/4] bip-0054: more correct worst case validation times The sentence was misleading, with 'lower end devices' potentially applying to the whole range, and the range itself being understated. --- bip-0054.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/bip-0054.md b/bip-0054.md index efdc08669b..8eaf1073dc 100644 --- a/bip-0054.md +++ b/bip-0054.md @@ -30,11 +30,11 @@ miners and increases available block space. It may be in the interest of short-s miners to exploit this vulnerability to materially increase the block rate without fatally hurting the network. -Specially crafted blocks may be expensive to process, with validation times ranging from a few -minutes up to more than an hour on lower-end devices. Long block validation times are a nuisance to -users, increasing the cost to independently fully validate the consensus rules. In addition they can -be used by miners to attack their competition, creating perverse incentives, centralization -pressures and leading to reduced network security. +Specially crafted blocks may be expensive to process, [taking up to][Delving worst block] several +minutes to validate even on high-end devices, and up to a few hours on lower-end devices. Long block +validation times are a nuisance to users, increasing the cost to independently fully validate the +consensus rules. In addition they can be used by miners to attack their competition, creating +perverse incentives, centralization pressures and leading to reduced network security. In computing a block's Merkle root, a transaction with exactly 64 bytes of non-witness data can be interpreted both as an intermediate node in the tree and as a leaf in the tree. This makes it @@ -234,6 +234,7 @@ post]. A third workaround is to change the Merkle proof structure by requiring i provided as the single-SHA256 of their preimage, instead of the double-SHA256. See [here][Sergio 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 [BIP-XXXX]: https://github.com/TheBlueMatt/bips/blob/7f9670b643b7c943a0cc6d2197d3eabe661050c2/bip-XXXX.mediawiki [BIP34]: https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki From b75238ffb3059fa1857f1858f9bc99f8cbf7ea67 Mon Sep 17 00:00:00 2001 From: Antoine Poinsot Date: Thu, 21 May 2026 10:04:45 -0400 Subject: [PATCH 3/4] 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 8eaf1073dc..133d92de3d 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 From 6c61126d742cade35cf658a1ca9565d530a35613 Mon Sep 17 00:00:00 2001 From: Antoine Poinsot Date: Thu, 21 May 2026 10:35:56 -0400 Subject: [PATCH 4/4] bip-0054: mention Luke's extranonce concern in rationale --- bip-0054.md | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/bip-0054.md b/bip-0054.md index 133d92de3d..7ea1a38b38 100644 --- a/bip-0054.md +++ b/bip-0054.md @@ -118,7 +118,13 @@ early [bip-0034][BIP34] violations also allows applications to recover the block 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]. +Consensus Cleanup activation, regardless of the [bip-0034][BIP34] activation status[^12]. One person +[raised the concern][miningdev nLockTime] that the `nLockTime` field would be an ideal extranonce +for ASIC controllers if such controllers ever became a bottleneck in mining operations. Others +[replied][miningdev nLockTime] that the same benefits could be achieved by using a dummy output +instead, should that ever become necessary. The authors [believe][ML remaining concerns] the +benefits of using `nLockTime` to differentiate coinbase transactions outweigh the theoretical +cost of making it unavailable for extranonce rolling by ASIC controllers. ## Backward compatibility @@ -251,3 +257,5 @@ MERKLEBLOCK] for a full description. [inquisition-implem]: https://github.com/darosior/bitcoin/tree/2509_inquisition_consensus_cleanup [Core 30.0]: https://bitcoincore.org/en/releases/30.0 [Core validation.cpp BIP34]: https://github.com/bitcoin/bitcoin/blob/390e7d61bd531505bb3d13f38316c282b85ed1dd/src/validation.cpp#L2401-L2459 +[miningdev nLockTime]: https://groups.google.com/g/bitcoinminingdev/c/jlqlNHHNSNk +[ML remaining concerns]: https://gnusha.org/pi/bitcoindev/UsKuvCXXhSAnNVx5a0K2UfP3srAr3slW9mcOjtYk9LnolaOXfWrW9jpqbxsQQPkyQuZogkhz2Hbfwii2VsTm79vRDpgKduxk35hpBu_t7Do=@protonmail.com/