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: more correct worst case validation times

Browse Source 
The sentence was misleading, with 'lower end devices' potentially applying to the whole range, and the range itself being understated.
This commit is contained in:
Antoine Poinsot
2026-05-21 10:54:23 -04:00
parent 19caed45a1
commit ec24fd371c
1 changed files with 6 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
bip-0054.md
View File

@@ -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 miners to exploit this vulnerability to materially increase the block rate without fatally hurting
the network. the network.
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
@@ -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 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
[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