bitcoin/bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2026-05-11 16:51:51 +00:00
Code Issues Releases Wiki Activity

BIP 54: grammar improvements (#2151)

Browse Source 
* bip54: Clarify deployment cost wording

* bip54: Clarify merkle tree wording

* bip54: Clarify sigops wording

* bip54: Clarify timewarp wording

* bip54: Clarify miner preparation cost wording
This commit is contained in:
nervana21
2026-05-07 11:24:34 +01:00
committed by GitHub
parent 2cf4272948
commit acf99fc160
1 changed files with 10 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files

22
bip-0054.md
View File

@@ -19,8 +19,7 @@ case block validation time, prevent Merkle tree weaknesses, and avoid duplicate
## Motivation
This proposal addresses a number of long-standing vulnerabilities and weaknesses in the Bitcoin
protocol. Bundling these fixes together allows to overcome 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,
allowing them to steal block subsidy from future miners and increase validation costs to nodes that
@@ -39,8 +38,8 @@ users, increasing the cost to independently fully validate the consensus rules.
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 64-byte transaction can be interpreted as an intermediate
node in the tree in addition to a leaf. This makes it possible to fake inclusion proofs by
In computing a block's Merkle root, a 64-byte transaction can be interpreted both as an intermediate
node in the tree and as a leaf in the tree. This makes it possible to fake inclusion proofs by
pretending a 64-byte block transaction is an inner node, as well as to pretend the inner nodes on
one level of the tree are the actual block transactions.
@@ -88,25 +87,24 @@ the timewarp and Murch–Zawy vulnerabilities[^3]. The latter poses mostly theor
extremely low risk to fix: the duration of an adjustment period has never been, and should never be,
negative. The former is fixed by preventing the timestamp of the first block of a difficulty period
from being lower than the previous block's, with a two-hour grace period. A [previous
proposal][BIP-XXXX] to fix timewarp used a ten-minute grace period instead, also adopted for
[testnet4][BIP94 timewarp]. Out of an abundance of caution and because it only trivially worsens the
proposal][BIP-XXXX] to fix the timewarp attack used a ten-minute grace period instead, and this
approach has been adopted for [testnet4][BIP94 timewarp]. Out of an abundance of caution and because it only trivially worsens the
block rate increase under attack, a two-hour grace period is used here[^4].
Disabling some Script operations and functionalities was [previously proposed][BIP-XXXX] to reduce
the worst case block validation time but was met with resistance due to confiscation concerns[^5]. A
delicate balance needs to be struck between minimizing the confiscation risks of a mitigation, even
if merely theoretical, and bounding the costs one could impose on all other users of the system. To
this effect a limit on the number of potentially executed signature operations pinpoints exactly the
harmful behaviour, leaving maximum flexibility in how Script functionalities may have been used.
that end, limiting potentially executed signature operations targets the exact harmful behaviour while
preserving maximal flexibility in Script usage.
Such a limit reduces the worst case block validation time by a factor of 40 and drastically
increases the preparation cost of an attack to make it uneconomical for a miner[^6]. The maximum of
increases the preparation cost of an attack, making it uneconomical for a miner[^6]. The maximum of
2500 was chosen as the tightest value that did not make any non-pathological standard transaction
invalid[^7].
In the presence of 64-byte transactions a block header's Merkle root may be valid for different sets
of transactions. This is because in the Merkle tree construction a 64-byte transaction may be
interpreted as the catenation of two 32-byte hashes, or the catenation of two 32-byte hashes may be
interpreted as a transaction. The former allows to fake a block inclusion proof and the latter makes
of transactions. This is because, in the Merkle tree construction, a 64-byte value may be
interpreted either as a transaction or as the concatenation of two 32-byte hashes. The former allows faking a block inclusion proof and the latter makes
it such that for a valid block the Merkle root in the block header is not a unique identifier for
the corresponding list of valid transactions[^8]. 64-byte transactions can only contain a
scriptPubKey that lets anyone spend the funds, or one that burns them. 64-byte transactions have