Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 10 additions & 12 deletions bip-0054.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand All @@ -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.

Expand Down Expand Up @@ -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
Comment thread
murchandamus marked this conversation as resolved.
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
Comment on lines +106 to +107
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

English newbie question: why prefer "concatenation" to "catenation"? Isn't it just more letter for the very same meaning? Is it simply that it's more natural to use the longer word?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They’re synonyms, but concatenation is the standard term in computer science and much more commonly used (maybe about a magnitude more often).

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TIL! I hadn't previously known that "catenation" was a word!

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
Expand Down