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

Merge pull request #2170 from darosior/bip54_rationale_additions

Browse Source 
BIP 54: improve and deduplicate parts of rationale and motivation
This commit is contained in:
Murch
2026-05-21 12:06:24 -07:00
committed by GitHub
parent 242f7d2605 6c61126d74
commit a766a6e127
1 changed files with 34 additions and 35 deletions
Download Patch File Download Diff File Expand all files Collapse all files

69
bip-0054.md
View File

@@ -21,22 +21,20 @@ 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 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. 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, The [timewarp bug][SE timewarp] makes it possible for a majority-hashrate attacker to arbitrarily
allowing them to steal block subsidy from future miners and increase validation costs to nodes that lower mining difficulty, and therefore arbitrarily increase the block rate. In the worst case, an
have to deal with the increased average transaction rate. By strategically setting the block attacker can bring down the difficulty to its minimum within 38 days of starting the attack. Besides
timestamp, the [timewarp bug][SE timewarp] lets miners bring down the difficulty to its minimum empowering a 51% attacker, the presence of this bug makes it harder to reason about miners'
within 38 days of starting the attack. The existence of this bug not only significantly empowers a incentives. Accelerating the block rate allows an attacker to steal block subsidy from future
51% attacker, but also makes it notably harder to reason about miners' incentives. It could indeed miners and increases available block space. It may be in the interest of short-sighted users and
be in the interest of short-sighted miners as well as short-sighted users to exploit this miners to exploit this vulnerability to materially increase the block rate without fatally hurting
vulnerability in a small enough proportion to increase the block rate without fatally hurting the the network.
network, as the effectively increased block space would — all other things being equal — bring fee
rates down for users.
Specially crafted blocks may be expensive to process, with validation times ranging from a few Specially crafted blocks may be expensive to process, [taking up to][Delving worst block] several
minutes up to more than an hour on lower-end devices. Long block validation times are a nuisance to minutes to validate even on high-end devices, and up to a few hours on lower-end devices. Long block
users, increasing the cost to independently fully validate the consensus rules. In addition they can validation times are a nuisance to users, increasing the cost to independently fully validate the
be used by miners to attack their competition, creating perverse incentives, centralization consensus rules. In addition they can be used by miners to attack their competition, creating
pressures and leading to reduced network security. 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 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 interpreted both as an intermediate node in the tree and as a leaf in the tree. This makes it
@@ -47,12 +45,10 @@ any other user of Merkle proofs, to rely on one of the available workarounds[^13
necessary in the first place. necessary in the first place.
Since [bip-0034][BIP34] activation, explicit [bip-0030][BIP30] validation is not necessary until 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 block height 1,983,702[^0]. Resuming [bip-0030][BIP30] validation would unnecessarily increase block
[bip-0034][BIP34] violations makes it possible to get rid of [bip-0030][BIP30] validation forever. validation overhead and preclude alternative full node designs (such as [bip-0182][BIP182] Utreexo).
Besides its unnecessary cost, another downside of [bip-0030][BIP30] validation is that it cannot be Enforcing that new coinbase transactions are different from the early [bip-0034][BIP34] violations
performed by Utreexo clients. Finally, leveraging the coinbase transaction's `nLockTime` field makes it possible to get rid of [bip-0030][BIP30] validation forever.
allows applications to recover the block height corresponding to a coinbase transaction without
having to parse Script.
## Specification ## Specification
@@ -116,17 +112,19 @@ 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 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. 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 The `nLockTime` field of transactions is a natural place to store a block height and is currently
contains a valid [bip-0034][BIP34] commitment to a future block height. This offers an opportunity unused in coinbase transactions. Using it to enforce that new coinbase transactions differ from
to duplicate these coinbase transactions in the future[^10] and for this reason [bip-0030][BIP30] early [bip-0034][BIP34] violations also allows applications to recover the block height without
validation will need to be re-activated from block 1,983,702. A simple way to prevent this is to having to parse Script. Leveraging the existing timelock mechanism makes the check self-contained:
mandate that future coinbase transactions vary from coinbase transactions before [bip-0034][BIP34] the same coinbase transaction cannot have been valid in a previous block[^11]. This simplifies both
activation. There are multiple ways of achieving this, but setting and enforcing the timelock for reasoning and client implementation, since the [bip-0030][BIP30] check can be skipped entirely past
the coinbase transaction makes it so all coinbase transactions past Consensus Cleanup activation Consensus Cleanup activation, regardless of the [bip-0034][BIP34] activation status[^12]. One person
could not have been valid before this height and therefore cannot be a duplicate[^11]. This [raised the concern][miningdev nLockTime] that the `nLockTime` field would be an ideal extranonce
simplifies both reasoning and client implementation, since the [bip-0030][BIP30] check can be for ASIC controllers if such controllers ever became a bottleneck in mining operations. Others
skipped entirely past Consensus Cleanup activation, regardless of the [bip-0034][BIP34] activation [replied][miningdev nLockTime] that the same benefits could be achieved by using a dummy output
status[^12]. 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 ## Backward compatibility
@@ -217,8 +215,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 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 the issue is largely orthogonal to this proposal: it is fundamentally about caching validation
status for malleable blocks. 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 [^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 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 coinbase transactions as not having duplicate past Consensus Cleanup activation would be consistent
@@ -236,7 +232,9 @@ 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 provided as the single-SHA256 of their preimage, instead of the double-SHA256. See [here][Sergio
MERKLEBLOCK] for a full description. 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 [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 [BIP-XXXX]: https://github.com/TheBlueMatt/bips/blob/7f9670b643b7c943a0cc6d2197d3eabe661050c2/bip-XXXX.mediawiki
[BIP34]: https://github.com/bitcoin/bips/blob/master/bip-0034.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 [BIP16 specs]: https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki#specification
@@ -252,7 +250,6 @@ MERKLEBLOCK] for a full description.
[Sergio post]: https://bitslog.com/2018/06/09/leaf-node-weakness-in-bitcoin-merkle-tree-design [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/ [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 [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 [Harding nLockTime]: https://bitcoin.stackexchange.com/questions/90229/nlocktime-in-bitcoin-core
[Delving duplicable]: https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/4 [Delving duplicable]: https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/4
[Core 0.16.1]: https://bitcoincore.org/en/releases/0.16.1 [Core 0.16.1]: https://bitcoincore.org/en/releases/0.16.1
@@ -260,3 +257,5 @@ MERKLEBLOCK] for a full description.
[inquisition-implem]: https://github.com/darosior/bitcoin/tree/2509_inquisition_consensus_cleanup [inquisition-implem]: https://github.com/darosior/bitcoin/tree/2509_inquisition_consensus_cleanup
[Core 30.0]: https://bitcoincore.org/en/releases/30.0 [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 [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/