-
Notifications
You must be signed in to change notification settings - Fork 6k
BIP 54: grammar improvements #2151
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
9409c94
353b6a8
d61f45d
29c0675
af954ff
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -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 | ||
|
Comment on lines
+106
to
+107
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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?
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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).
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.