BIP 54: Consensus Cleanup

darosior commented at 5:22 pm on March 26, 2025: member

This is a BIP draft for a Consensus Cleanup soft fork.

This proposal builds upon Matt Corallo’s 2019 proposal, which i set to revive at the end of 2023. I eventually shared my research in a Delving Bitcoin post in early 2024 (along with a semi-private companion post for the redacted sensitive details). A number of people contributed ideas, testing and otherwise fruitful discussion. This led to settling on a list of mitigations, which i updated the mailing list about in February 2025.

I think it’s now ready to be officially published as a BIP.

jonatack added the label New BIP on Mar 26, 2025

in bip-cc.md:14 in 098894f04f outdated

 9+  Type: Standards Track
10+  Created: 2025-03-17
11+  License: CC0-1.0
12+```
13+
14+# Abstract

vostrnad commented at 8:17 pm on March 26, 2025:

(applies to the other headings as well)

0## Abstract

darosior commented at 8:29 pm on March 31, 2025:

Is it an established guideline? I don’t mind doing it, just curious where this comes from.

vostrnad commented at 8:55 pm on March 31, 2025:

From my experience, a first-level heading is only meant for the top of a page or document. I’ve never seen a Markdown/Mediawiki document with more than one first-level heading, and all other BIPs seem to follow this convention as well (in that they only have second-level headings and lower).

in bip-cc.md:19 in 098894f04f outdated

13+
14+# Abstract
15+
16+Introduce new consensus rules in order to fix the timewarp attack, reduce the worst case block
17+validation, prevent Merkle tree weaknesses and avoid duplicate transactions without
18+[bip-0030][BIP30] validation.

vostrnad commented at 8:17 pm on March 26, 2025:

The abstract should usually start with “This BIP/document proposes/introduces…”, something like:

0This document proposes changes to consensus rules in order to fix the timewarp attack, reduce the worst case block
1validation time, prevent Merkle tree weaknesses and avoid duplicate transactions without
2[bip-0030][BIP30] validation.

in bip-cc.md:22 in 098894f04f outdated

17+validation, prevent Merkle tree weaknesses and avoid duplicate transactions without
18+[bip-0030][BIP30] validation.
19+
20+# Motivation
21+
22+This proposal addresses a number of long standing vulnerabilities and weaknesses in the Bitcoin

vostrnad commented at 8:17 pm on March 26, 2025:

0This proposal addresses a number of long-standing vulnerabilities and weaknesses in the Bitcoin

in bip-cc.md:23 in 098894f04f outdated

18+[bip-0030][BIP30] validation.
19+
20+# Motivation
21+
22+This proposal addresses a number of long standing vulnerabilities and weaknesses in the Bitcoin
23+protocol. Bundling those fixes together allows to overcome the fixed cost of deploying a Bitcoin

vostrnad commented at 8:17 pm on March 26, 2025:

0protocol. Bundling these fixes together allows to overcome the fixed cost of deploying a Bitcoin

in bip-cc.md:27 in 098894f04f outdated

21+
22+This proposal addresses a number of long standing vulnerabilities and weaknesses in the Bitcoin
23+protocol. Bundling those fixes together allows to overcome the fixed cost of deploying a Bitcoin
24+soft fork.
25+
26+The timewarp bug permits a majority hashrate attacker to arbitrarily increase the block rate,

vostrnad commented at 8:17 pm on March 26, 2025:

A bullet list might be better than paragraphs for describing the individual vulnerabilities.

Sjors commented at 9:28 am on March 27, 2025:

Agreed, at least something to guide the reader when the topic changes.

darosior commented at 8:33 pm on March 31, 2025:

I disagree. I dislike the tendency to use lists as a replacement for properly conveying the flow in words. There is literally one section per mitigation, i don’t think having bullet points instead of paragraph will make this any clearer.

Sjors commented at 8:06 am on April 1, 2025:

You’re welcome to improve the flow if you prefer that. Right now there’s paragraph transitions like this:

… bring fee rates down for users.

Specially crafted blocks may be expensive to process, …

in bip-cc.md:37 in 098894f04f outdated

32+of short-sighted miners as well as short-sighted users to exploit this vulnerability in a small
33+enough proportion to increase the block rate without fatally hurting the network, as the effectively
34+increased block space would - all others things equal - bring fee rates down for users.
35+
36+Specially crafted blocks may be expensive to process, with validation times ranging from a few
37+minutes up to more than a hour on lower end devices. Long block validation times are a nuisance to

vostrnad commented at 8:17 pm on March 26, 2025:

0minutes up to more than an hour on lower-end devices. Long block validation times are a nuisance to

in bip-cc.md:40 in 098894f04f outdated

35+
36+Specially crafted blocks may be expensive to process, with validation times ranging from a few
37+minutes up to more than a hour on lower end devices. Long block validation times are a nuisance to
38+users, increasing the cost to independently fully validate the consensus rules. In addition they can
39+be used by miners to attack their competition, creating perverse incentives, centralization
40+pressures and reduced network security.

vostrnad commented at 8:17 pm on March 26, 2025:

This sentence needs improving, how about:

0be used by miners to attack their competition, creating perverse incentives and centralization
1pressures and reducing network security.

darosior commented at 8:35 pm on March 31, 2025:

The comma you replace in your suggestion is there on purpose to avoid the “and” repetition. Taking the s/ed/ing/ in the form of “leading to reduced security”.

in bip-cc.md:42 in 098894f04f outdated

37+minutes up to more than a hour on lower end devices. Long block validation times are a nuisance to
38+users, increasing the cost to independently fully validate the consensus rules. In addition they can
39+be used by miners to attack their competition, creating perverse incentives, centralization
40+pressures and reduced network security.
41+
42+In computing a block's Merkle root, a 64 bytes transaction can be interpreted as an intermediate

vostrnad commented at 8:17 pm on March 26, 2025:

0In computing a block's Merkle root, a 64-byte transaction can be interpreted as an intermediate

in bip-cc.md:44 in 098894f04f outdated

39+be used by miners to attack their competition, creating perverse incentives, centralization
40+pressures and reduced network security.
41+
42+In computing a block's Merkle root, a 64 bytes transaction can be interpreted as an intermediate
43+node in the tree in addition to a leaf. This makes it possible to fake inclusion proofs by
44+pretending a 64 bytes block transaction is an inner node, as well as to pretend the inner nodes on

vostrnad commented at 8:17 pm on March 26, 2025:

0pretending a 64-byte block transaction is an inner node, as well as to pretend the inner nodes on

in bip-cc.md:52 in 098894f04f outdated

46+
47+Since [bip-0034][BIP34] activation, explicit [bip-0030][BIP30] validation is not necessary until
48+block height 1,983,702[^0].  Mandating new coinbase transactions be different from the early
49+[bip-0034][BIP34] violations makes it possible to get rid of [bip-0030][BIP30] validation forever.
50+Besides its unnecessary cost, another downside of [bip-0030][BIP30] validation is that it cannot be
51+performed by Utreexo clients. Finally, leveraging the coinbase transaction's `nLockTime` field

vostrnad commented at 8:17 pm on March 26, 2025:

utreexo is usually not capitalized:

0performed by utreexo clients. Finally, leveraging the coinbase transaction's `nLockTime` field

darosior commented at 8:38 pm on March 31, 2025:

Why? I’ve always seen it named with the first letter capitalized, including on their Github.

vostrnad commented at 8:44 pm on March 31, 2025:

I was looking mainly at https://github.com/utreexo/utreexod which uses the lowercase version, but indeed https://github.com/utreexo/biptreexo uses the capitalized one, so feel free to leave as is.

in bip-cc.md:53 in 098894f04f outdated

48+block height 1,983,702[^0].  Mandating new coinbase transactions be different from the early
49+[bip-0034][BIP34] violations makes it possible to get rid of [bip-0030][BIP30] validation forever.
50+Besides its unnecessary cost, another downside of [bip-0030][BIP30] validation is that it cannot be
51+performed by Utreexo clients. Finally, leveraging the coinbase transaction's `nLockTime` field
52+allows applications to recover the block height corresponding to a coinbase transaction without
53+having to parse Bitcoin Script.

vostrnad commented at 8:17 pm on March 26, 2025:

The “Bitcoin” disambiguation is definitely not needed here:

0having to parse Script.

darosior commented at 8:38 pm on March 31, 2025:

Sure… :shrug:

in bip-cc.md:60 in 098894f04f outdated

54+
55+# Specification
56+
57+For all blocks after activation the following new rules apply.
58+
59+Given a block at height `N`:

vostrnad commented at 8:17 pm on March 26, 2025:

Just like in the previous section, a bullet list might be better than paragraphs for describing the individual fixes. (see also the original consensus cleanup draft for formatting)

darosior commented at 8:40 pm on March 31, 2025:

I think my document is significantly better formatted than the original draft. Re bullet points see me earlier response. I’m not taking this suggestion.

in bip-cc.md:61 in 098894f04f outdated

55+# Specification
56+
57+For all blocks after activation the following new rules apply.
58+
59+Given a block at height `N`:
60+- if `N % 2016` is equal to `0` the `nTime` field of the block must be set to a value higher than or

vostrnad commented at 8:17 pm on March 26, 2025:

Not all implementation call the timestamp nTime, so just calling it “timestamp” might be preferable.

darosior commented at 8:41 pm on March 31, 2025:

Yeah this was a point of contention when i was drafting this. However if i want to move away from Bitcoin Core lingo i should be consistent and apply it everywhere (nTime, nLockTime, nSequence, scriptSig, scriptPubKey, etc..). Will leave it as is for now.

vostrnad commented at 9:20 pm on March 31, 2025:

From what I can tell, the other terms you mention enjoy pretty wide use outside of Bitcoin Core, however you could definitely replace them in line with Murch’s transaction terminology BIP (i.e. locktime, sequence, input script and output script).

Sjors commented at 8:12 am on April 1, 2025:

The Murch BIP seems like a good place to start. It uses the term “lock time” with “Synonym: nLockTime”. So I guess that’s normal language vs. suggested variable name? “The lock time is given by nLockTime.”

The BIP also mentions a few cases where you should not use a Bitcoin Core variable, e.g. VarInt.

darosior commented at 7:48 pm on April 1, 2025:

Changed “nTime field” for “timestamp”.

in bip-cc.md:73 in 098894f04f outdated

68+scriptSig and previous output's scriptPubKey, including the P2SH redeemScript. If the total is
69+strictly higher than `2500`, the transaction is invalid. The accounting is the same as for
70+[bip-0016][BIP16 specs]: a `CHECKSIG` operation accounts for `1` and a `CHECKMULTISIG` accounts for
71+the number of public keys associated, or `20` if the number of public keys is greater than `16`. A
72+`CHECKMULTISIG` not directly preceded by a minimally-pushed number between `1` and `16` (included)
73+accounts for `20`.

vostrnad commented at 8:17 pm on March 26, 2025:

This should probably be rewritten, as it first introduces one accounting method (count the number of CHECKSIG and CHECKMULTISIG and check if the count is less than or equal to 2500) and only then changes the accounting for CHECKMULTISIG.

darosior commented at 8:42 pm on March 31, 2025:

Suggestions welcome, i wrote this a few times when i wrote the document. This is the clearest i could come up with. Alternatives made the sentence too heavy.

vostrnad commented at 9:17 pm on March 31, 2025:

Here is my attempt at rewriting the section, with the main goal to avoid implying that 2500 is the maximum count of CHECKSIG and CHECKMULTISIG opcodes before explaining how they actually contribute to the total:

0A limit is set on the number of potentially executed signature operations in validating a
1transaction. It applies to all transactions in the block except the coinbase transaction[^1]. For
2each input in the transaction, count the number of `CHECKSIG` and `CHECKMULTISIG` in the input
3scriptSig and previous output's scriptPubKey, including the P2SH redeemScript. A `CHECKSIG`
4operation contributes 1 to the total, and a `CHECKMULTISIG` contributes the number of public
5keys associated, or 20 if the number of public keys is greater than 16. A `CHECKMULTISIG` not
6directly preceded by a minimally-pushed number between 1 and 16 (included) contributes 20 to
7the total. If the total is strictly higher than 2500, the transaction is invalid.

darosior commented at 6:33 pm on April 1, 2025:

Took your suggestion of only mentioning the limit at the end. Reworded to fit in @Sjors’ point about explicitly mentioning the VERIFY counterparts to the operations. How do you find it now?

vostrnad commented at 8:20 pm on April 1, 2025:

Looks good now. Personally I wouldn’t use backticks for numbers (like I would for variable names), that doesn’t seem to be a common style (including in BIPs), and the current version isn’t even consistent about it, but that’s beside the point of this thread.

darosior commented at 9:05 pm on April 2, 2025:

Removed backticks for numbers all across the document.

in bip-cc.md:83 in 098894f04f outdated

78+and its `nSequence` field must not be equal to `0xffffffff`.
79+
80+# Rationale
81+
82+The restrictions on the timestamp of the first and last blocks of a difficulty adjustment period fix
83+the timewarp and Murch-Zawy vulnerabilities[^3]. The latter poses mostly theoretical concerns but is

vostrnad commented at 8:17 pm on March 26, 2025:

0the timewarp and Murch–Zawy vulnerabilities[^3]. The latter poses mostly theoretical concerns but is

darosior commented at 8:46 pm on March 31, 2025:

I remember hearing English had different dashes, but i didn’t expect it’d come up as a Pull Request review comment one day! I’m not even sure how to produce those, and to be honest this is probably not the best use of our time.

vostrnad commented at 9:40 pm on March 31, 2025:

Yes, the en dash (–) is commonly used to connect names in a compound name to distinguish them from a double-barrelled name which uses a hyphen (-). That’s how you know, for example, that the Gell-Mann–Okubo mass formula was named after two people, Gell-Mann and Okubo.

If you’re not sure how to produce an en dash, copypasting it is fine too 😉 Alternatively, if neither Murch nor Zawy care about not being mistaken for the same person named Murch-Zawy, feel free to leave as is.

darosior commented at 4:40 pm on April 1, 2025:

I for one have never seen @murchandamus and @zawy12 in the same room at the same time!

darosior commented at 5:00 pm on April 1, 2025:

Done.

in bip-cc.md:86 in 098894f04f outdated

81+
82+The restrictions on the timestamp of the first and last blocks of a difficulty adjustment period fix
83+the timewarp and Murch-Zawy vulnerabilities[^3]. The latter poses mostly theoretical concerns but is
84+extremely low risk to fix: the duration of an adjustment period has never been, and should never be,
85+negative. The former is fixed by preventing the timestamp of the first block of a difficulty period
86+to be lower than the previous block's, with a two hours grace period. A [previous

vostrnad commented at 8:17 pm on March 26, 2025:

0from being lower than the previous block's, with a two-hour grace period. A [previous

in bip-cc.md:87 in 098894f04f outdated

82+The restrictions on the timestamp of the first and last blocks of a difficulty adjustment period fix
83+the timewarp and Murch-Zawy vulnerabilities[^3]. The latter poses mostly theoretical concerns but is
84+extremely low risk to fix: the duration of an adjustment period has never been, and should never be,
85+negative. The former is fixed by preventing the timestamp of the first block of a difficulty period
86+to be lower than the previous block's, with a two hours grace period. A [previous
87+proposal][BIP-XXXX] to fix timewarp used a ten minutes grace period instead, also adopted for

vostrnad commented at 8:17 pm on March 26, 2025:

0proposal][BIP-XXXX] to fix timewarp used a ten-minute grace period instead, also adopted for

in bip-cc.md:89 in 098894f04f outdated

84+extremely low risk to fix: the duration of an adjustment period has never been, and should never be,
85+negative. The former is fixed by preventing the timestamp of the first block of a difficulty period
86+to be lower than the previous block's, with a two hours grace period. A [previous
87+proposal][BIP-XXXX] to fix timewarp used a ten minutes grace period instead, also adopted for
88+[testnet4][BIP94 timewarp]. Out of an abundance of caution and because it only trivially worsens the
89+block rate increase under attack, a two hours grace period is used here[^4].

vostrnad commented at 8:17 pm on March 26, 2025:

0block rate increase under attack, a two-hour grace period is used here[^4].

in bip-cc.md:102 in 098894f04f outdated

 97+Such a limit reduces the worst case block validation time by a factor of 40 and drastically
 98+increases the preparation cost of an attack to make it uneconomical for a miner[^6]. The `2500`
 99+value was chosen as the tightest value that did not make any non-pathological standard transaction
100+invalid[^7].
101+
102+In the presence of 64 bytes transactions a block header's Merkle root may be valid for different

vostrnad commented at 8:18 pm on March 26, 2025:

0In the presence of 64-byte transactions a block header's Merkle root may be valid for different

in bip-cc.md:103 in 098894f04f outdated

 98+increases the preparation cost of an attack to make it uneconomical for a miner[^6]. The `2500`
 99+value was chosen as the tightest value that did not make any non-pathological standard transaction
100+invalid[^7].
101+
102+In the presence of 64 bytes transactions a block header's Merkle root may be valid for different
103+sets of transactions. This is because in the Merkle tree construction a 64 bytes transaction may be

vostrnad commented at 8:18 pm on March 26, 2025:

0sets of transactions. This is because in the Merkle tree construction a 64-byte transaction may be

in bip-cc.md:104 in 098894f04f outdated

 99+value was chosen as the tightest value that did not make any non-pathological standard transaction
100+invalid[^7].
101+
102+In the presence of 64 bytes transactions a block header's Merkle root may be valid for different
103+sets of transactions. This is because in the Merkle tree construction a 64 bytes transaction may be
104+interpreted as the catenation of two 32 bytes hashes, or the catenation of two 32 bytes hashes may

vostrnad commented at 8:18 pm on March 26, 2025:

0interpreted as the catenation of two 32-byte hashes, or the catenation of two 32-byte hashes may

in bip-cc.md:107 in 098894f04f outdated

102+In the presence of 64 bytes transactions a block header's Merkle root may be valid for different
103+sets of transactions. This is because in the Merkle tree construction a 64 bytes transaction may be
104+interpreted as the catenation of two 32 bytes hashes, or the catenation of two 32 bytes hashes may
105+be interpreted as a transaction. The former allows to fake a block inclusion proof and the latter
106+makes it such that for a valid block the Merkle root in the block header is not a unique identifier
107+for the corresponding list of valid transactions[^8]. 64 bytes transactions can only contain an

vostrnad commented at 8:18 pm on March 26, 2025:

0for the corresponding list of valid transactions[^8]. 64-byte transactions can only contain an

in bip-cc.md:108 in 098894f04f outdated

103+sets of transactions. This is because in the Merkle tree construction a 64 bytes transaction may be
104+interpreted as the catenation of two 32 bytes hashes, or the catenation of two 32 bytes hashes may
105+be interpreted as a transaction. The former allows to fake a block inclusion proof and the latter
106+makes it such that for a valid block the Merkle root in the block header is not a unique identifier
107+for the corresponding list of valid transactions[^8]. 64 bytes transactions can only contain an
108+output Script that lets anyone spend the funds, or burns them.  They have also been non-standard for

vostrnad commented at 8:18 pm on March 26, 2025:

0output script that lets anyone spend the funds, or burns them.  They have also been non-standard for

Sjors commented at 9:56 am on March 27, 2025:

64 bytes transactions can only contain an output Script that lets anyone spend the funds, or burns them.

It would be good to elaborate on these two specific claims.

If you can additionally demonstrate that any 64 byte transaction is (“third party”) malleable in a way that adds or removes a byte, then that would completely alleviate any concerns about confiscatory surface.

Sjors commented at 10:35 am on March 27, 2025:

@Christewart’s draft BIP seems to to make the claim that this is indeed the case:

Pre-segwit 64-byte transactions that spend a nonstandard utxo that are inherently malleable.

https://github.com/Christewart/bips/blob/2024-12-20-64bytetxs/bip-XXXX.mediawiki#pre-segwit-64-byte-transactions

I don’t fully understand the reasoning though.

Sjors commented at 10:59 am on March 27, 2025:

Asked on Stack Exchange: https://bitcoin.stackexchange.com/questions/125971/can-any-consensus-valid-64-byte-transaction-be-third-party-malleated-to-change

darosior commented at 8:51 pm on March 31, 2025:

Rationale?

vostrnad commented at 9:02 pm on March 31, 2025:

“Script” is the name of the scripting language, while a “script” is any program written in Script. See this handy diagram I’ve made, and for even more details check out Murch’s transaction terminology BIP.

darosior commented at 2:34 pm on April 1, 2025:

It seems the only actionable item left in this review comment is:

It would be good to elaborate on these two specific claims.

I’m not sure how to elaborate further than that. I think this is enough for the reader to think about it and convince themselves it is the case and more information would just be superfluous. Closing this but feel free to reopen if you have a suggestion.

in bip-cc.md:111 in 098894f04f outdated

106+makes it such that for a valid block the Merkle root in the block header is not a unique identifier
107+for the corresponding list of valid transactions[^8]. 64 bytes transactions can only contain an
108+output Script that lets anyone spend the funds, or burns them.  They have also been non-standard for
109+6 years at the time this is written. It was suggested the known vulnerabilities could instead be
110+mitigated by committing to the Merkle tree depth in the header's version field[^9]. The authors
111+believe it is preferable to address the root cause by invalidating 64 bytes transactions. This

vostrnad commented at 8:18 pm on March 26, 2025:

0believe it is preferable to address the root cause by invalidating 64-byte transactions. This

in bip-cc.md:115 in 098894f04f outdated

110+mitigated by committing to the Merkle tree depth in the header's version field[^9]. The authors
111+believe it is preferable to address the root cause by invalidating 64 bytes transactions. This
112+approach also fixes the vulnerability without developers of SPV verifiers having to implement the
113+mitigation or to know it is necessary in the first place.
114+
115+Several blocks prior to [bip-0034][BIP34] activation contain a coinbase transaction such as its

vostrnad commented at 8:18 pm on March 26, 2025:

0Several blocks prior to [bip-0034][BIP34] activation contain a coinbase transaction whose

in bip-cc.md:153 in 098894f04f outdated

149+[^1]: Technically this limit *cannot* apply to a coinbase transaction as the size of its sole
150+input's scriptSig is limited.
151+[^2]: The locktime validation, which is also performed for coinbase transactions, enforces that the
152+nLockTime value is the last block at which a transaction is invalid, not the first one at which it
153+is valid.
154+[^3]: The timewarp attack is described [here][SE timewarp] and the Murch-Zawy attack [here][Delving

vostrnad commented at 8:18 pm on March 26, 2025:

0[^3]: The timewarp attack is described [here][SE timewarp] and the Murch–Zawy attack [here][Delving

darosior commented at 8:52 pm on March 31, 2025:

Let’s discuss those in one place: #1800 (review). Closing this one.

in bip-cc.md:174 in 098894f04f outdated

169+[^7]: A non-pathological transaction would have a public key per signature operation and at least
170+one signature per input. Per standardness a single P2SH input may not have more than 15 signature
171+operations. Even by using 1-of-15 `CHECKMULTISIG`s a transaction would bump against the maximum
172+standard transaction size before running into the newly introduced limit. To run against the newly
173+introduced limit but not the transaction size a transaction would need to spend P2SH inputs with a
174+redeem script similar to `CHECKSIG DROP CHECKSIG DROP ..`. This type of redeem script serves no

vostrnad commented at 8:18 pm on March 26, 2025:

0redeem script similar to `CHECKSIG DROP CHECKSIG DROP ...`. This type of redeem script serves no

darosior commented at 9:03 pm on March 31, 2025:

Really?..

(see what i did here?)

vostrnad commented at 8:19 pm on March 26, 2025: contributor

First pass of review, mostly copy editing suggestions so far.

in bip-cc.md:62 in 098894f04f outdated

56+
57+For all blocks after activation the following new rules apply.
58+
59+Given a block at height `N`:
60+- if `N % 2016` is equal to `0` the `nTime` field of the block must be set to a value higher than or
61+  equal to the value of the `nTime` field of block at height `N-1` minus `7200`;

mzumsande commented at 9:13 pm on March 26, 2025:

Maybe reword this to make it clearer that minus 7200 is subtracted from the value of nTime, and not from height N-1 (so that no one unfamiliar with the context could read it as “block at height N - 7201”).

darosior commented at 9:16 pm on March 31, 2025:

Is this better?

0  equal to the value minus `7200` of the `nTime` field of block at height `N-1`;

darosior commented at 8:27 pm on April 16, 2025:

I’m not sure how i could phrase it with “minus 7200” not following N-1 that is also not too heavy. But i’m not sure it’s necessary, especially when rendered it seems fairly clear:

So i’m going to close this, let me know if you have a suggestion and i’ll reopen.

in bip-cc.md:66 in 098894f04f outdated

60+- if `N % 2016` is equal to `0` the `nTime` field of the block must be set to a value higher than or
61+  equal to the value of the `nTime` field of block at height `N-1` minus `7200`;
62+- if `N % 2016` is equal to `2015` the `nTime` field of the block must be set to a value higher than
63+  or equal to the value of the `nTime` field of block at height `N-2015`.
64+
65+A limit is set on the number of potentially executed signature operations in validating a

Sjors commented at 9:35 am on March 27, 2025:

Maybe:

… in validating the inputs of a transaction.

And then explain the coinbase exception:

[^1]: The scriptSig of a coinbase input is not executed. Even if it were, its size is constrained such that the limit introduced in this BIP can’t be reached.

darosior commented at 4:44 pm on April 1, 2025:

I think dis-disambiguating “transaction inputs” is redundant with “signature operations in validating”. Signature validation always occurs in validating a transaction’s inputs.

As for the footnote i already have a similar one:

[^1]: Technically this limit cannot apply to a coinbase transaction as the size of its sole input’s scriptSig is limited.

Sjors commented at 8:26 am on April 2, 2025:

Someone might wonder if we’re including signature operations in the scriptPubKey for e.g. bare multisig. That’s also covered by the term “potentially executed”. Still, I think stating that the rule only impacts inputs is more clear than making it implicit.

darosior commented at 9:11 pm on April 2, 2025:

There is no need to wonder. It is clearly specified “For each input in the transaction, count the number of CHECKSIG and CHECKMULTISIG in the input scriptSig and previous output’s scriptPubKey”. I don’t think this can be clearer: i don’t see how an implementer could be mislead to go through the transaction outputs instead.

in bip-cc.md:68 in 098894f04f outdated

63+  or equal to the value of the `nTime` field of block at height `N-2015`.
64+
65+A limit is set on the number of potentially executed signature operations in validating a
66+transaction. It applies to all transactions in the block except the coinbase transaction[^1]. For
67+each input in the transaction, count the number of `CHECKSIG` and `CHECKMULTISIG` in the input
68+scriptSig and previous output's scriptPubKey, including the P2SH redeemScript. If the total is

Sjors commented at 9:42 am on March 27, 2025:

Let’s also explictly state that, unlike sigops accounting:

The witness is ignored
There is no 4x adjustment for non-segwit, because of (1)

I assume you also want to include OP_CHECKSIGVERIFY and OP_CHECKMULTISIGVERIFY, even though they require actually valid signatures to keep going.

darosior commented at 4:48 pm on April 1, 2025:

I don’t think we should talk about witnesses or the segwit sigops discount. This explicitly mentions scriptPubKey (with bip16 redeemScript) and scriptSig.

Good point for the VERIFY version of opcodes.

Sjors commented at 8:28 am on April 2, 2025:

I don’t think we should talk about witnesses or the segwit sigops discount.

That’s going to confuse people. Unless you come up with completely different terminology, it’s logical to assume legacy sigops are multiplied by 4.

darosior commented at 9:08 pm on April 2, 2025:

The specifications you are commenting on literally spell out the algorithm to count the operations and the limit itself. I don’t see what here is confusing, or why an implementer would somehow introduce a magic 4x multiplier out of the blue. However i can see how discussing segwit sigop discount or mentioning the 4x multiplier used in other contexts could get people confused.

in bip-cc.md:130 in 098894f04f outdated

125+# Backward compatibility
126+
127+This proposal only tightens the block validation rules: there is no block that is valid under the
128+rules proposed in this BIP but not under the existing Bitcoin consensus rules. As a consequence
129+these changes are backward-compatible with unupgraded node software. That said, the authors strongly
130+encourage node operators to upgrade in order to fully validate all consensus rules.

Sjors commented at 10:09 am on March 27, 2025:

You should elaborate on the changes miners SHOULD and MUST make. Either in this section or one specifically for miners.

“MUST” in order to avoid accidentally producing an invalid block under the new rules
“SHOULD” to avoid accidentally producing an invalid block under the current rules, as well to ensure that they only have to upgrade their node software when the fork activates.

They MUST run software that respects the mintime field of getblocktemplate (BIP 22 / 33) at the time of activation. They SHOULD do so already

They SHOULD run node software that sets mintime in a way that doesn’t violate the timewarp rule, i.e. Bitcoin Core >= v29.

They MUST set nLockTime in their coinbase transactions once the rule takes effect. They MAY or SHOULD (?) do it earlier.

They MUST run bitcoin node software that considers 64 byte transactions non-standard (e.g. Bitcoin Core > v?).

They MUST run bitcoin node software with standardness rules that already effectively enforce the new sigop restriction.

If they mine non-standard transactions, they MUST carefully consider the risks.

darosior commented at 4:59 pm on April 1, 2025:

I’m not sure about this. That miners should respect the mintime is not new, not a change they need to make and would be out of place here. That miner should run software that enforces the new consensus rules makes sense for any soft fork and is not specific to this BIP, or to miners specifically for that matter. The same goes for the rest.

Sjors commented at 8:33 am on April 2, 2025:

Which previous soft fork required miners to upgrade their full stack to produce valid blocks, rather than just their node? E.g. SegWit didn’t, because by default blocks don’t mandate a witness commitment.

A miner could simply upgrade their node, which is only need to prevent mining on top of an invalid block. They weren’t required to upgrade their stratum code immediately to produce SegWit blocks.

mintime isn’t new, but still a good reminder. And upgrading their stratum v1 stack to something that supports a completely new BIP, otherwise they won’t set nLockTime, is absolutely critical. And it shouldn’t come as an implementation detail surprise after this BIP is widely accepted.

darosior commented at 9:01 pm on April 2, 2025:

Sorry, what in this BIP do you believe requires upgrading the Stratum v1 protocol?

Sjors commented at 12:29 pm on April 3, 2025:

The changes to the coinbase need to be added to getblocktemplate and Stratum v1 software which relies on that RPC needs to use these fields.

darosior commented at 3:06 pm on April 3, 2025:

This is not a change in the Stratum v1 protocol. GBT changes have historically been part of a different BIP (see for instance bip-0145) and this is what i intend to do here, if at all necessary.

Sjors commented at 1:41 pm on April 4, 2025:

BIP 145 was optional. Miners weren’t required to upgrade before SegWit activation, they could do so whenever they felt like mining a segwit block. It even has documentation on how to support unupgraded miners.

It’s fine to define these details in another BIP, but this BIP should point out that it’s mandatory and has to be done before activation.

Sjors commented at 1:47 pm on April 4, 2025:

Some historical discussion about how long it took for miners to upgrade their pool software after SegWit activated: https://bitcoin.stackexchange.com/q/86208/4948

murchandamus commented at 3:42 pm on April 4, 2025:

I second @Sjors here, even if some of the requirements were already present in similar form, it doesn’t hurt to explicitly mention them here.

Sjors commented at 10:22 am on March 27, 2025: member

Concept ACK on the timewarp and Murch-Zawy fix, as well as the 64 byte transaction ban.

I still need to think about the worst case validation fix more, though the approach seems reasonable.

With respect to the nLockTime change, I need to get a sense of what pool software should take into account, especially since Bitoin Core does not construct the coinbase transaction.

We don’t strictly need this change until height 1,983,702, but it seems better to enforce it at the same time as the rest of these changes. Otherwise we might end up with accidental forks several decades from now with nobody remembering this BIP.

I also still need to see and study the implementation(s), outside the timewarp fix, which I’m fairly familiar with by now.

in bip-cc.md:155 in 098894f04f outdated

151+[^2]: The locktime validation, which is also performed for coinbase transactions, enforces that the
152+nLockTime value is the last block at which a transaction is invalid, not the first one at which it
153+is valid.
154+[^3]: The timewarp attack is described [here][SE timewarp] and the Murch-Zawy attack [here][Delving
155+Murch-Zawy].
156+[^4]: A bug in testnet4 pushed blocks' timestamps in the future when exploited, revealing how some

fjahr commented at 4:00 pm on March 27, 2025:

nit: FWIW, the min-difficulty blocks were definitely a feature, requested to be kept around from Testnet3 in the Testnet4 PR (here, here) and specified in the BIP. Instead of exploited I would say “overused” or “maxed out”

darosior commented at 2:22 pm on April 1, 2025:

Yeah, “bug” is not a correct characterization since it was intentional. However i think “exploited” is fair since people apparently assumed all participants would always be honest, and, well, they are not.

I went with “abused” to use a little bit less loaded language:

0[^4]: The testnet4 exception pushed blocks' timestamps in the future when abused, revealing how some

What do you think?

fjahr commented at 2:25 pm on April 1, 2025:

maybe s/exception/difficulty exception/ but otherwise sounds good to me!

in bip-cc.md:55 in 098894f04f outdated

50+Besides its unnecessary cost, another downside of [bip-0030][BIP30] validation is that it cannot be
51+performed by Utreexo clients. Finally, leveraging the coinbase transaction's `nLockTime` field
52+allows applications to recover the block height corresponding to a coinbase transaction without
53+having to parse Bitcoin Script.
54+
55+# Specification

fjahr commented at 4:06 pm on March 27, 2025:

I agree with @Christewart on the ML that it would be better to have this split up into multiple BIPs. If you decide to keep it as one BIP you should probably number the new rules so they can be more easily referenced. This is something that was requested of BIP94 in #1782 as well.

darosior commented at 2:41 pm on March 28, 2025:

As i replied on the mailing list thread, i am not going to split this BIP into parts as i think it would unnecessarily increase overhead and could impede progress. I am happy to assign numbers to the rules though, if you find it makes them easier to be referenced.

darosior commented at 2:28 pm on April 1, 2025:

I tried doing this but i couldn’t find a way that did not add unnecessary clutter. It just seems seems to me that introducing numbers does not make the rules easier to reference. For instance “The Consensus Cleanup timewarp fix” is just clearer and less confusing than “The Consensus Cleanup rule 1”.

ariard commented at 10:07 pm on March 28, 2025: none

There might be a problem with the math in this BIP.

Exposing said problem clearly might be a $5k a day wreck the whole LN style of exploit.

Asking for a friend who is curious on how to handle said problem.

darosior commented at 4:43 pm on March 30, 2025: member

@ariard i made sure you are on the private thread, if you want to discuss potentially sensitive details please do so there. Alternatively feel free to contact me privately.

darosior force-pushed on Mar 31, 2025

darosior force-pushed on Apr 1, 2025

in bip-cc.md:4 in 404010f176 outdated

0@@ -0,0 +1,206 @@
1+```
2+  BIP: ?
3+  Title: Consensus Cleanup

murchandamus commented at 6:47 pm on April 1, 2025:

0  Layer: Consensus (soft fork)
1  Title: Consensus Cleanup

in bip-cc.md:10 in 404010f176 outdated

 5+          Matt Corallo <bips@bluematt.me>
 6+  Comments-Summary: No comments yet.
 7+  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-?
 8+  Status: Draft
 9+  Type: Standards Track
10+  Created: 2025-03-17

murchandamus commented at 6:48 pm on April 1, 2025:

According to BIP 2, the created date contains the date a number was assigned.

0  Created: ?

murchandamus commented at 6:49 pm on April 1, 2025: contributor

Just a quick first look and some editorial comments as I see that this is still being edited and already getting quite a bit of feedback.

darosior force-pushed on Apr 1, 2025

darosior commented at 7:50 pm on April 1, 2025: member

Thanks everyone for the review thus far. I think i’ve addressed everything.

darosior force-pushed on Apr 2, 2025

in bip-cc.md:18 in 21a9cd52a0 outdated

13+```
14+
15+## Abstract
16+
17+This document proposes new consensus rules in order to fix the timewarp attack, reduce the worst
18+case block validation time, prevent Merkle tree weaknesses and avoid duplicate transactions without

murchandamus commented at 2:51 pm on April 4, 2025:

0case block validation time, prevent Merkle tree weaknesses, and avoid duplicate transactions without

darosior commented at 2:08 pm on April 7, 2025:

This is on purpose. I thought it was a mistake to use a comma before a conjunction, as it’s the case in French. Turns out in English it’s more complicated than that.

In the case of an enumeration like here, “Grammar-Monster” says that a comma is to be used for American English but not for British English.

As the set of rules surrounding commas before a conjunction in English is so simple, they even summarized it an algorithm! TIL:

in bip-cc.md:28 in 21a9cd52a0 outdated

23+This proposal addresses a number of long-standing vulnerabilities and weaknesses in the Bitcoin
24+protocol. Bundling these fixes together allows to overcome the fixed cost of deploying a Bitcoin
25+soft fork.
26+
27+The timewarp bug permits a majority hashrate attacker to arbitrarily increase the block rate,
28+allowing them to steal block subsidy from future miners, and increase validation costs to nodes that

murchandamus commented at 2:56 pm on April 4, 2025:

No comma here makes it clearer that the increase of the block rate is causing the stealing of block subsidy and increased validation cost:

0allowing them to steal block subsidy from future miners and increase validation costs to nodes that

in bip-cc.md:61 in 21a9cd52a0 outdated

56+## Specification
57+
58+For all blocks after activation the following new rules apply.
59+
60+Given a block at height `N`:
61+- if `N % 2016` is equal to 0 the timestamp of the block must be set to a value higher than or

murchandamus commented at 3:00 pm on April 4, 2025:

0- if `N % 2016` is equal to 0, the timestamp of the block must be set to a value higher than or

in bip-cc.md:64 in 21a9cd52a0 outdated

59+
60+Given a block at height `N`:
61+- if `N % 2016` is equal to 0 the timestamp of the block must be set to a value higher than or
62+  equal to the value of the timestamp of block at height `N-1` minus 7200;
63+- if `N % 2016` is equal to 2015 the timestamp of the block must be set to a value higher than
64+  or equal to the value of the timestamp of block at height `N-2015`.

murchandamus commented at 3:01 pm on April 4, 2025:

0  or equal to the value of the timestamp of the block at height `N-2015`.

in bip-cc.md:67 in 21a9cd52a0 outdated

62+  equal to the value of the timestamp of block at height `N-1` minus 7200;
63+- if `N % 2016` is equal to 2015 the timestamp of the block must be set to a value higher than
64+  or equal to the value of the timestamp of block at height `N-2015`.
65+
66+A limit is set on the number of potentially executed signature operations in validating a
67+transaction. It applies to all transactions in the block except the coinbase transaction[^1]. For

murchandamus commented at 3:08 pm on April 4, 2025:

Active voice is usually preferred in technical writing, because it is clearer:

0The number of potentially executed signature operations in validating a
1transaction is limited. The limit applies to all transactions except coinbase transactions[^1]. For

darosior commented at 2:14 pm on April 7, 2025:

This is not active voice?

murchandamus commented at 11:28 pm on April 15, 2025:

You are right, it’s not.

in bip-cc.md:69 in 21a9cd52a0 outdated

64+  or equal to the value of the timestamp of block at height `N-2015`.
65+
66+A limit is set on the number of potentially executed signature operations in validating a
67+transaction. It applies to all transactions in the block except the coinbase transaction[^1]. For
68+each input in the transaction, count the number of `CHECKSIG` and `CHECKMULTISIG` in the input
69+scriptSig and previous output's scriptPubKey, including the P2SH redeemScript. The accounting is the

murchandamus commented at 3:13 pm on April 4, 2025:

The P2SH redeem script is part of the input script, so I was surprised that it is explicitly mentioned here.

vostrnad commented at 4:06 pm on April 4, 2025:

I’m not, the redeem script is just a data push in the input script, and it’s only when the previous output matches the P2SH template that it gets special treatment. Not mentioning it explicitly would definitely make it ambiguous as to whether it’s included in the count.

in bip-cc.md:96 in 21a9cd52a0 outdated

91+
92+Disabling some Script operations and functionalities was [previously proposed][BIP-XXXX] to reduce
93+the worst case block validation time but was met with resistance due to confiscation concerns[^5]. A
94+delicate balance needs to be struck between minimizing the confiscation risks of a mitigation, even
95+if merely theoretical, and bounding the costs one could impose on all other users of the system. To
96+this effect a limit on the number of potentially executed signature operations pinpoints exactly the

murchandamus commented at 3:17 pm on April 4, 2025:

I would read “to pinpoint” as “precisely locate”, but from the context I think a meaning of “to prevent” would be more fitting:

0this effect a limit on the number of potentially executed signature operations mitigates exactly the

darosior commented at 2:20 pm on April 7, 2025:

I think this suggestion changes the meaning. What i intend to convey is exactly how you would read it: it precisely disable the harmful behaviour to avoid making uninteresting-but-harmless usage invalid.

in bip-cc.md:97 in 21a9cd52a0 outdated

92+Disabling some Script operations and functionalities was [previously proposed][BIP-XXXX] to reduce
93+the worst case block validation time but was met with resistance due to confiscation concerns[^5]. A
94+delicate balance needs to be struck between minimizing the confiscation risks of a mitigation, even
95+if merely theoretical, and bounding the costs one could impose on all other users of the system. To
96+this effect a limit on the number of potentially executed signature operations pinpoints exactly the
97+harmful behaviour, leaving maximum flexibility in how Script functionalities may have been used.

murchandamus commented at 3:21 pm on April 4, 2025:

Perhaps:

0harmful behaviour, reducing the flexibility of Script functionality the least.

vostrnad commented at 4:11 pm on April 4, 2025:

I like that the current version says “may have been used”, it emphasizes that this change only affects legacy scripts that aren’t meant to be used anymore. We aren’t really reducing the flexibility of Script as a whole.

darosior commented at 2:55 pm on April 7, 2025:

Agree with Vojtěch. Not taking the suggestion.

in bip-cc.md:109 in 21a9cd52a0 outdated

104+sets of transactions. This is because in the Merkle tree construction a 64-byte transaction may be
105+interpreted as the catenation of two 32-byte hashes, or the catenation of two 32-byte hashes may
106+be interpreted as a transaction. The former allows to fake a block inclusion proof and the latter
107+makes it such that for a valid block the Merkle root in the block header is not a unique identifier
108+for the corresponding list of valid transactions[^8]. 64-byte transactions can only contain an
109+output script that lets anyone spend the funds, or burns them.  They have also been non-standard for

murchandamus commented at 3:24 pm on April 4, 2025:

I just noticed that you use “output script” here, but “scriptPubKey” before. It would be preferable that the same term is used to refer to the same abstract concept throughout the document.

darosior commented at 2:22 pm on April 7, 2025:

Yes. I like your terminology BIP, but i think i will go for the more common scriptPubKey instead.

in bip-cc.md:110 in 21a9cd52a0 outdated

105+interpreted as the catenation of two 32-byte hashes, or the catenation of two 32-byte hashes may
106+be interpreted as a transaction. The former allows to fake a block inclusion proof and the latter
107+makes it such that for a valid block the Merkle root in the block header is not a unique identifier
108+for the corresponding list of valid transactions[^8]. 64-byte transactions can only contain an
109+output script that lets anyone spend the funds, or burns them.  They have also been non-standard for
110+6 years at the time this is written. It was suggested the known vulnerabilities could instead be

murchandamus commented at 3:24 pm on April 4, 2025:

06 years at the time this is written. It was suggested that the known vulnerabilities could instead be

in bip-cc.md:120 in 21a9cd52a0 outdated

115+
116+Several blocks prior to [bip-0034][BIP34] activation contain a coinbase transaction whose scriptSig
117+contains a valid [bip-0034][BIP34] commitment to a future block height. This offers an opportunity
118+to duplicate these coinbase transactions in the future[^10] and for this reason [bip-0030][BIP30]
119+validation will need to be re-activated from block 1,983,702. A simple way to prevent this is to
120+mandate that future coinbase transactions vary slightly from coinbase transactions before

murchandamus commented at 3:27 pm on April 4, 2025:

0mandate that future coinbase transactions vary from coinbase transactions before

in bip-cc.md:121 in 21a9cd52a0 outdated

116+Several blocks prior to [bip-0034][BIP34] activation contain a coinbase transaction whose scriptSig
117+contains a valid [bip-0034][BIP34] commitment to a future block height. This offers an opportunity
118+to duplicate these coinbase transactions in the future[^10] and for this reason [bip-0030][BIP30]
119+validation will need to be re-activated from block 1,983,702. A simple way to prevent this is to
120+mandate that future coinbase transactions vary slightly from coinbase transactions before
121+[bip-0034][BIP34] activation. There are multiple ways of achieving this, but enforcing the timelock

murchandamus commented at 3:28 pm on April 4, 2025:

0[bip-0034][BIP34] activation. There are multiple ways of achieving this, but setting and enforcing the timelock

in bip-cc.md:130 in 21a9cd52a0 outdated

125+## Backward compatibility
126+
127+This proposal only tightens the block validation rules: there is no block that is valid under the
128+rules proposed in this BIP but not under the existing Bitcoin consensus rules. As a consequence
129+these changes are backward-compatible with unupgraded node software. That said, the authors strongly
130+encourage node operators to upgrade in order to fully validate all consensus rules.

murchandamus commented at 3:30 pm on April 4, 2025:

This doesn’t seem complete. The requirement to set and enforce the locktime is not backward-compatible for block producers.

darosior commented at 2:35 pm on April 7, 2025:

I’m confused. This seems to directly follow for any consensus change: miners must take steps to produce blocks valid according to the new rules. I don’t mind adding a sentence to this effect, but as far as i know the backwards compatibility section has always been used to discuss the backwards compatibility from the point of view of end users, not miners (since by definition block producers need to adapt if we are going to change block validity). See for instance the backwards compatibility section of the SegWit soft fork. Why change now?

darosior commented at 2:53 pm on April 7, 2025:

I tried adding something to this effect but anything i come up with just seems needlessly redundant and vague. For instance:

0This proposal only tightens the block validation rules: there is no block that is valid under the
1rules proposed in this BIP but not under the existing Bitcoin consensus rules. As a consequence
2these changes are backward-compatible with unupgraded node software. That said, the authors strongly
3encourage node operators to upgrade in order to fully validate all consensus rules.
4
5As with any consensus change, miners need to take precautions to produce blocks compatible with the
6new rules. In particular this BIP introduces restrictions on the coinbase transaction and block
7header timestamp, which are often set by closed source pool software.

zawy12 commented at 1:01 pm on April 9, 2025:

Instead of “This proposal only tightens the block validation rules: there is no block that is valid under the rules proposed in this BIP but not under the existing Bitcoin consensus rules. As a consequence these changes are backward-compatible with unupgraded node software. That said, the authors strongly encourage node operators to upgrade in order to fully validate all consensus rules.” I would say “The proposal tightens the block validation rules. It doesn’t invalidate any existing blocks to be backwards-compatible. Nodes should upgrade to ensure future blocks that are invalid under the proposal are not validated.”

murchandamus commented at 11:39 pm on April 15, 2025:

AFAIU,

Backward-compatible means new software being able to read data generated by old software.
Forward-compatible means old software being able to read data generated by new software.

How about:

0-This proposal only tightens the block validation rules: there is no block that is valid under the
1-rules proposed in this BIP but not under the existing Bitcoin consensus rules. As a consequence
2-these changes are backward-compatible with unupgraded node software. That said, the authors strongly
3-encourage node operators to upgrade in order to fully validate all consensus rules.
4+This proposal only tightens the block validation rules: any block that would be valid under the
5+rules proposed in this BIP is valid under the existing Bitcoin consensus rules. As a consequence
6+these changes are forward-compatible to unupgraded node software. That said, the authors strongly
7+encourage node operators to upgrade in order to fully validate all consensus rules.
8+
9+Block producers will need to upgrade to new software to produce valid blocks per the new rules.

darosior commented at 8:22 pm on April 16, 2025:

0+any block that would be valid under the
1+rules proposed in this BIP is valid under the existing Bitcoin consensus rules. As a consequence
2+these changes are forward-compatible to unupgraded node software.

This is backward. The changes are backward-compatible with unupgraded nodes. Nodes are forward-compatible with future soft forks.

0+Block producers will need to upgrade to new software to produce valid blocks per the new rules.

Again, this is by definition true of any single soft fork. I don’t see why we should start mentioning now as if it was something specific to Consensus Cleanup.

I don’t think there is much more to do here.

murchandamus commented at 10:29 pm on April 16, 2025:

I see that I will have to be careful to be more precise in this pull request.

I’m just thinking that you will get a bunch of readers to whom it is not obvious that miners have to upgrade for a soft fork, and where e.g., SegWit did accept some portion of old blocks, this change will require them to upgrade. Therefore, I think it wouldn’t be unreasonable to mention that miners will have to upgrade to produce valid blocks, even if it may seem obvious.

darosior commented at 8:48 pm on April 17, 2025:

As this has been requested by different people, i have added more information regarding compatibility. As @Sjors also pointed out earlier, what we are concerned about here is miners producing blocks that are valid according to these new rules. I have therefore added a new “Miner forward compatibility” section which gives more details about this topic. Let me know what you think.

https://github.com/bitcoin/bips/blob/24f0707cd639d6ec28b0f9e1a407daae8ac8fdda/bip-0054.md?plain=1#L132-L148

murchandamus commented at 11:49 pm on April 17, 2025:

LGTM

Sjors commented at 7:24 am on April 18, 2025:

Link to what I wrote above: #1800 (review)

Only bit that’s missing, maybe to add in the timewarp section, is that they must ensure the mintime field of getblocktemplate is honoured, or use curtime without modification. Although it’s true they should do that already, in the past 10 years afaik they would never have produced an invalid block when using pool machine clock time. Having increased the grace period from 10 minutes to two hours also makes it extremely unlikely to run into this.

But if miners are looking at their coinbase generation code anyway, they should check this.

darosior commented at 8:15 pm on April 18, 2025:

I think this is unnecessarily heavy and confusing, but i added a sentence about how miners should use curtime or mintime from getblocktemplate and not a timestamp pulled out of nowhere. Let me know if you think the sentence to this effect can be materially improved.

Sjors commented at 10:34 am on April 21, 2025:

That looks fine.

murchandamus commented at 3:40 pm on April 4, 2025: contributor

This proposal looks mostly complete from an editorial standpoint. In a few segments, the style could be even more prosaic—the document could be a bit clearer by avoiding passive voice and directly referencing subjects and objects of sentences than referencing via noun phrases and pronouns. Some abstract ideas are referenced with different terms. It would be preferable if the same term is used for the same concept throughout.

in bip-cc.md:78 in 21a9cd52a0 outdated

73+preceded by a minimally-pushed number between 1 and 16 (included) accounts for 20. If the
74+total is strictly higher than 2500, the transaction is invalid.
75+
76+Transactions whose witness-stripped serialized size is exactly 64 bytes are made invalid.
77+
78+The coinbase transaction's `nLockTime` field must be set to the height of the block minus 1[^2]

luke-jr commented at 9:20 pm on April 4, 2025:

nLockTime is the most ideal location to put an extranonce, so it seems like a bad idea to burn it for no good reason.

Sjors commented at 1:27 pm on April 7, 2025:

@luke-jr why would miners switch to something different from the current extraNonce?

darosior commented at 3:45 pm on April 7, 2025:

It would have been better to bring up conceptual feedback on the mailing list. “For no good reason” is unnecessarily aggressive, the point here is not to make things invalid just for the sake of it. Please engage charitably to foster productive discussions.

To your point, it’s my understanding that nLockTime makes for a good extranonce because it’s serialized at the very end of the coinbase transaction. Rolling it does not require re-hashing the whole transaction as you can just cache a midstate for the first 64 bytes. Could you provide more details about how you expect it to be used exactly, and under what circumstances the operation it improves may become a bottleneck?

luke-jr commented at 4:16 am on April 10, 2025:

@luke-jr why would miners switch to something different from the current extraNonce?

There is no “current extraNonce”. Extranonces can be anywhere in theory. But this particular location, as @darosior says, minimises the need to re-hash a lot of data to roll it. That means it can more practically be done on ASICs or MCUs with nearly no latency.

Sjors commented at 11:18 am on April 15, 2025:

Can you do the same with an output? Since a coinbase doesn’t have any inputs to sign (which commit to outputs), rolling an OP_RETURN output should be just as easy and there’s no space limit?

darosior commented at 2:01 pm on April 15, 2025:

@luke-jr i see how it might be useful in theory but i don’t think it would be in realistic conditions. Could you describe (ideally on the ML or Delving thread) the specifics of a future ASIC design where it would matter?

darosior commented at 2:22 pm on April 21, 2025:

I’m moving this discussion to the Delving thread. Please @luke-jr provide more details there so your objection can be addressed.

luke-jr commented at 6:45 pm on April 22, 2025:

I don’t use Delving

darosior commented at 7:10 pm on April 22, 2025:

Then can you please share details about your objection somewhere? Anywhere. Here, the dev mailing list, not Delving, 0bin, whatever.

Just sharing vague concerns without details makes it really hard to address your objection. And i trust it is not your intention to prevent having an objective discussion about the tradeoff being made here.

darosior force-pushed on Apr 7, 2025

ariard commented at 7:07 pm on April 7, 2025: none

@ariard i made sure you are on the private thread, if you want to discuss potentially sensitive details please do so there. Alternatively feel free to contact me privately.

The friend said the potential problem is not related on the timewarp fix.

murchandamus commented at 8:05 pm on April 11, 2025: contributor

@ariard i made sure you are on the private thread, if you want to discuss potentially sensitive details please do so there. Alternatively feel free to contact me privately.

The friend said the potential problem is not related on the timewarp fix.

Hi @ariard, if you don’t intend to contribute constructively, could you please refrain from posting in this repository?

murchandamus commented at 3:40 am on April 12, 2025: contributor

Let’s call this BIP 54. Please update the table entry preamble and title correspondingly.

murchandamus renamed this:
~~Consensus Cleanup BIP draft~~
BIP 54: Consensus Cleanup
on Apr 12, 2025

darosior force-pushed on Apr 14, 2025

darosior commented at 7:52 pm on April 14, 2025: member

Updated to BIP54.

darosior force-pushed on Apr 17, 2025

ariard commented at 0:45 am on April 18, 2025: none

Let’s call this BIP 54. Please update the table entry preamble and title correspondingly.

This doesn’t say what is the BIP editorial policy followed here in matter of distributing multiple consensus changes in different BIPs as we have here 4 proposed fixes gathered in a single document (timewarp, worst-case-block, disallow 64-byte, avoid duplicate txn). Other people in the community on the mailing list, not me, have also questioned to have it spread in multiple documents.

darosior force-pushed on Apr 18, 2025

bitcoin deleted a comment on Apr 18, 2025

jonatack commented at 8:55 pm on April 18, 2025: member

This doesn’t say what is the BIP editorial policy followed here in matter of distributing multiple consensus changes in different BIPs as we have here 4 proposed fixes gathered in a single document (timewarp, worst-case-block, disallow 64-byte, avoid duplicate txn). Other people in the community on the mailing list, not me, have also questioned to have it spread in multiple documents. @ariard Yes, per BIP2, “It is highly recommended that a single BIP contain a single key proposal or new idea. The more focused the BIP, the more successful it tends to be. If in doubt, split your BIP into several well-focused ones.” That said, I have not yet looked at the scopes of BIPs 53 and 54 to determine a preference.

jonatack commented at 8:58 pm on April 18, 2025: member

@ariard I’ve removed the off-topic comment. Better to air those kinds of issues in a personal blog post. Let’s remain focused here on technical review, please.

darosior commented at 9:11 pm on April 18, 2025: member

For what it’s worth i have already addressed the suggestion to split this BIP into 4 twice on the mailing list. Last occurrence is here. Unless compelling arguments in favour of doing so are given i do not plan on addressing it a third time.

bitcoin deleted a comment on Apr 18, 2025

jonatack commented at 9:58 pm on April 18, 2025: member

@darosior @ariard I’ve edited the off-topic stuff. Let’s move forward. Thanks!

bitcoin deleted a comment on Apr 18, 2025

ariard commented at 10:31 pm on April 20, 2025: none

@ariard I’ve removed the off-topic comment. Better to air those kinds of issues in a personal blog post. Let’s remain focused here on technical review, please.

Here the comment I made from the HTML record I have stamped in the chain at the time of publication.

 0         <task-lists disabled sortable>
 1 <table class="d-block user-select-contain" data-paste-markdown-skip>
 2   <tbody class="d-block">
 3     <tr class="d-block"> 
 4       <td class="d-block comment-body markdown-body  js-comment-body">
 5           <blockquote>
 6 <p dir="auto">Hi <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/ariard/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/ariar      d">@ariard</a>, if you don’t intend to contribute constructively, could you please refrain from posting in this repository?</p>
 7 </blockquote>
 8 <p dir="auto"><a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/murchandamus/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/mu      rchandamus">@murchandamus</a> And you could please ask to your f*cking boss <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/morcos/hovercard" data-octo-click="hovercard-link-click" data-octo      -dimensions="link_type:self" href="https://github.com/morcos">@morcos</a> to present me public excuses to have instructed one of his attorney in March 2023 in forwarding a completely defaming legal letter, of which the crux was abou      t a bitcoin open-source matters?</p>
 9 <p dir="auto">The attorney was very polite and courteous. However as I said so at the time <a href="https://diyhpl.us/~bryan/irc/bitcoin/bitcoin-dev/linuxfoundation-pipermail/lightning-dev/2023-March/003887.txt" rel="nofollow">in my       email on the mailing list</a>, I don’t think he was very competent in the field he was having a say: "<em>Second, the lawyer issuing the letter sounds to be one specialist in labor law, not really cryptocurrencies and FOSS software      </em>”.</p>
10 <p dir="auto">That the integrality of the Bitcoin community minus myself is trusting Chaincode or any their affiliates for consensus changes, that’s their choice not mine. I’m saying this in all civility.</p>
11 <hr>
12 <p dir="auto">More seriously, as the friend said it’s not related to timewarp fix, and I’ve already spend time reviewing the <a href="https://groups.google.com/g/bitcoindev/c/tKETFYnEtng" rel="nofollow">timewarp fixes</a> and I’ll p      ersonally review more what is related in this BIP to the timewarp fixed.</p>
13       </td>
14     </tr>
15   </tbody>
16 </table>
17 </task-lists>

@jonatack

For the records, the disagreement between Alex Morcos / Chaincode and myself that is referenced by the attorney letter shared on the lightning mailing list in 2023 was about the “moral hazard” when some people or organization arrogate themselves to arbitrarily kick-out another contributor from the common communication channels or in-person spaces of the bitcoin development process, including when it’s concerning a consensus matter. This train of behaviors in flagrant violation of the local law of their own country (e.g what say us judicial rulings on impartial party in employment law).

Free access to common communication channels or in-person spaces of the bitcoin development process by an already established contributor and as such guaranteeing the decentralization of development process, in no way it’s a personal issue so if I can ask you to justify why you think it’s “off-topic”, I would appreciate @jonatack.

Be sure and certain, I’ve been confronted in private by some people 10 or 20 years older than me on a potential conflict of interest in this industry circa 2022. However (a) They never f*cking pointed out what would have been indeed a real conflict of interest and where I’ve been ethically adamant since 2019 while no one ever asking me to have that level of ethical rigor, indeed for trains of actions related to security vulnerabilities, when you have to fully separate your emotions and other bias from what you’re coldly and calmly doing, sometimes under time-pressure.

(b) They were fully aware about what is a conflict of interest in more traditional industries, though instead of following these guidelines in lack of better, they freaked out and acted emotionally against myself. And here I’m talking about people that everyone knows in the industry and who are clearly in position of independence. They was even one who went to threat during phone calls “that X has power and you should shut up”.

So I’m not going to apologize to have to air those concerns here and not on another forum or blog post. At the end, if there is a vulnerability affecting the whole ecosystem due to “arrangements with friends” due to the poor current bitcoin development culture, I might be one of the s*cker who has to spend nights attempting to correct that. Like I did in the past. Less likely you Jon, with all my respects.

So in the light of those elements, and in the light of the judicial ruling 2023 raising the question what is “power” or “control” in the bitcoin development process, explicitly quoting who has access to github admin perms here, I think I’m legitimate to ask you why do you think it’s “off-topic” @jonatack. More why you’re convinced to decide what is on-topic and what is off-topic.

They’re rude words, though you’re a rude boy, someone I respect so I’m interested to have your viewpoint in all eagerness.

By the way for anyone with permission access to the github in capacity to moderate the post, should I say that after china in 2018 afaict, there were very recently over the last weeks another major juridiction recognizing the force of blockchain timestamps as judicial evidences that you can use in front of courts.

ariard commented at 10:52 pm on April 20, 2025: none

For what it’s worth i have already addressed the suggestion to split this BIP into 4 twice on the mailing list. Last occurrence is here. Unless compelling arguments in favour of doing so are given i do not plan on addressing it a third time.

“Those BIPs had much more content to them. The specifications of the Consensus Cleanup is trivial in comparison:”

It’s different, last time with BIP 340 / BIP 341 / BIP 342, it was a script-level change, which was fully self-contained behind a P2TR segwit version. One can be fine to never use Taproot spend, and be relatively safe-guarded from any design issues in the script extension. Here, for the timewarp fixes, the worst-block validations, the duplicate transaction it has an impact on miners template pooling, though also downstream softwares.

There is an additional effort for the champion indeed to maintain one BIP for each fix, though it’s facilitate for any reviewer or people who are writing downstream software what goes in every BIP. It’s also lowering the bar if we have to extend the BIP with dedicate policy rules. E.g BIP141 is bundling policy rules and consensus rules in a single document.

This does not say that the mitigation cannot be all activated at the same time, there is indeed an ecosystem wide-cost for activating soft-fork, at minima the number of limited nVersion bits in the blocks available for that.

For the single aspect of adding more policy rules in the coming fututre, with their rationales and how it can impact downstream softwares, it’s worthy to split them, in my opinion.

“The fact that each of these mitigations was researched and discussed at length by multiple people over the past year gives me confidence to move forward with every single one of those.”

This is a bit of an empty argument, imho. This is only saying that indeed the BIP have been so far researched and discussed at length. Not pointing out the benefit to unbundle the fixes for documenting either future policy rules shipped with them or extend specific rationale in footnotes for each mitigation.

Saying this, I’ll go to keep reviewing the time-warp fixes. It’s good for the hypothetical long-term impact on second-layers if timewarp is not addressed.

ariard commented at 11:06 pm on April 20, 2025: none

judicial ruling 2023

This judicial ruling, I forgot to add the hyperlink: https://www.judiciary.uk/wp-content/uploads/2023/02/Tulip-v-Van-Der-Laan-judgment-030223.pdf

ariard commented at 9:48 pm on April 21, 2025: none

test.

in bip-0054.md:35 in b1a59cadb0 outdated

30+timestamp, the timewarp bug lets miners bring down the difficulty to its minimum within 38 days of
31+starting the attack. The existence of this bug not only significantly empowers a 51% attacker, but
32+also makes it notably harder to reason about miners' incentives. It could indeed be in the interest
33+of short-sighted miners as well as short-sighted users to exploit this vulnerability in a small
34+enough proportion to increase the block rate without fatally hurting the network, as the effectively
35+increased block space would - all others things equal - bring fee rates down for users.

murchandamus commented at 8:48 pm on April 22, 2025:

0increased block space would — all other things equal — bring fee rates down for users.

darosior commented at 2:51 pm on April 23, 2025:

Thanks, done.

Ariard6 commented at 10:17 pm on April 22, 2025: none

I talked with Jon offline. I respect Jon a lot and I told him I’ll temporize on this issue.

About the ban of my main github accoint, I’ll just seat on it with absolute no care and use pop-up account when I wish to contribute on the repository – you know it’s the wild open internet, not your private workplace where you can just fired people when they disagree with you.

Let’s remind, let’s remind that the moderation guidelines were established with the explicit approval of 13 contributors only, all of them are economically dependent directly or indirectly from chaincode or block inc shareholders. And in this what we call “decentralization” in bitcoin…

We already verified github term of service there what I’m doing is perfectly legal. However, what is completely illegal has been (a) the establishment of the moderation guidelines last year and (b) the present ban is illegal even under their own rules as there is no public proof they consult all the maintainers in a public channel (as set for in contrib/verify-commits/trusted-keys.

In my perspective and with the state of information available, people with the moderation permissions on Github have been intimidated or coerced by Chaincode folks to take such action. Maybe with threats that their bitcoin foss grants would be cancelled if they do not take a specific line of actions. or that they would be kicked-off from the next invitation-only dev meetings.

One cannot forward attorney letter to someone for complete bullshit, and then go to ask to “trust” the moderators. If I’m also vehement on this issue, it’s because according to a friend there is a pending security issue to weigh for one of the mitigation brought by this BIP, though no way this is going to be shared with folks that have spent the last years backstabbing you, or any of their affiliates.

About independance, back in the time they were 2 cofounders of blockstream who used to have independance protections in their legal contracts. Especially to not be pressured in their decision-making in that kind of situation. Why that kind of practice has not become an industry standard, at least for anyone who is maintainer it’s very unclear…

I’m taking in good faith Matthew Zipkin’s words in the other issue to consult with specific attorneys to clarify the legal questions about the “moderation guidelines” establishment and what an “impartial party” effictively means in a decentralized community of contributors all over the world. But the clock is ticking…

I’ll purse the review of the timewarp fix and that time keep my comments centered on technical matters.

IMHO it’s good to make progress on the timewarp fix.

in bip-0054.md:62 in b1a59cadb0 outdated

57+
58+For all blocks after activation the following new rules apply.
59+
60+Given a block at height `N`:
61+- if `N % 2016` is equal to 0, the timestamp of the block must be set to a value higher than or
62+  equal to the value of the timestamp of block at height `N-1` minus 7200;

murchandamus commented at 11:23 pm on April 22, 2025:

Written out this just sounds a bit ambiguous to me. Perhaps add a formula for a precise statement:

0- if `N % 2016` is equal to 0, the timestamp of the block must be set to a value higher than or
1  equal to the value of the timestamp of block at height `N-1` minus 7200;
2  i.e., `t(N) ≥ t(N−1) − 7200`

darosior commented at 2:53 pm on April 23, 2025:

(here and below)

I think that both writing it out and writing it in pseudocode is unnecessarily heavy. I would choose the written out version over pseudocode since a BIP is a text document. Therefore i will keep the existing version.

murchandamus commented at 7:59 pm on April 23, 2025:

Mildly disagree. BIPs are technical documentation, not prose. The main purpose is to convey complex information accurately and concisely. I suggested adding the inequation, because I felt that it presents the information more accessibly than the sentence. It’s not a blocker for me, though.

jonatack commented at 10:31 pm on April 23, 2025:

Agree with @murchandamus.

in bip-0054.md:64 in b1a59cadb0 outdated

59+
60+Given a block at height `N`:
61+- if `N % 2016` is equal to 0, the timestamp of the block must be set to a value higher than or
62+  equal to the value of the timestamp of block at height `N-1` minus 7200;
63+- if `N % 2016` is equal to 2015, the timestamp of the block must be set to a value higher than
64+  or equal to the value of the timestamp of the block at height `N-2015`.

murchandamus commented at 11:27 pm on April 22, 2025:

0  or equal to the value of the timestamp of the block at height `N-2015`;
1  i.e., `t(N) ≥ t(N−2015)`

in bip-0054.md:76 in b1a59cadb0 outdated

71+`CHECKMULTISIG`/`CHECKMULTISIGVERIFY` accounts for the number of public keys associated, or 20 if
72+the number of public keys is greater than 16. A `CHECKMULTISIG`/`CHECKMULTISIGVERIFY` not directly
73+preceded by a minimally-pushed number between 1 and 16 (included) accounts for 20. If the
74+total is strictly higher than 2500, the transaction is invalid.
75+
76+Transactions whose witness-stripped serialized size is exactly 64 bytes are made invalid.

murchandamus commented at 11:30 pm on April 22, 2025:

The new rule is that it’s invalid, not that it is made invalid, right?

0Transactions whose witness-stripped serialized size is exactly 64 bytes are invalid.

darosior commented at 2:54 pm on April 23, 2025:

Sure. Done.

in bip-0054.md:104 in b1a59cadb0 outdated

 96+this effect a limit on the number of potentially executed signature operations pinpoints exactly the
 97+harmful behaviour, leaving maximum flexibility in how Script functionalities may have been used.
 98+Such a limit reduces the worst case block validation time by a factor of 40 and drastically
 99+increases the preparation cost of an attack to make it uneconomical for a miner[^6]. The 2500
100+value was chosen as the tightest value that did not make any non-pathological standard transaction
101+invalid[^7].

murchandamus commented at 11:45 pm on April 22, 2025:

“The 2500 value” sounds weird to me. Maybe:

0increases the preparation cost of an attack to make it uneconomical for a miner[^6]. The maximum of 2500
1was chosen as the tightest value that did not make any non-pathological standard transaction
2invalid[^7].

darosior commented at 2:55 pm on April 23, 2025:

Thanks, done.

in bip-0054.md:109 in b1a59cadb0 outdated

104+sets of transactions. This is because in the Merkle tree construction a 64-byte transaction may be
105+interpreted as the catenation of two 32-byte hashes, or the catenation of two 32-byte hashes may
106+be interpreted as a transaction. The former allows to fake a block inclusion proof and the latter
107+makes it such that for a valid block the Merkle root in the block header is not a unique identifier
108+for the corresponding list of valid transactions[^8]. 64-byte transactions can only contain a
109+scriptPubKey that lets anyone spend the funds, or burns them.  They have also been non-standard for

murchandamus commented at 11:46 pm on April 22, 2025:

0scriptPubKey that lets anyone spend the funds, or one that burns them.  They have also been non-standard for

darosior commented at 2:56 pm on April 23, 2025:

Done.

in bip-0054.md:110 in b1a59cadb0 outdated

105+interpreted as the catenation of two 32-byte hashes, or the catenation of two 32-byte hashes may
106+be interpreted as a transaction. The former allows to fake a block inclusion proof and the latter
107+makes it such that for a valid block the Merkle root in the block header is not a unique identifier
108+for the corresponding list of valid transactions[^8]. 64-byte transactions can only contain a
109+scriptPubKey that lets anyone spend the funds, or burns them.  They have also been non-standard for
110+6 years at the time this is written. It was suggested that the known vulnerabilities could instead be

murchandamus commented at 11:49 pm on April 22, 2025:

This phrase might be more future proof by casting it as “since <year/date>”. E.g.:

0scriptPubKey that lets anyone spend the funds, or burns them.  64-byte transactions have also been non-standard for
16 years at the time of writing (since 2019). It was suggested that the known vulnerabilities could instead be

darosior commented at 2:59 pm on April 23, 2025:

Removed the relative date entirely and just stuck with “since 2019”.

in bip-0054.md:122 in b1a59cadb0 outdated

114+mitigation or to know it is necessary in the first place.
115+
116+Several blocks prior to [bip-0034][BIP34] activation contain a coinbase transaction whose scriptSig
117+contains a valid [bip-0034][BIP34] commitment to a future block height. This offers an opportunity
118+to duplicate these coinbase transactions in the future[^10] and for this reason [bip-0030][BIP30]
119+validation will need to be re-activated from block 1,983,702. A simple way to prevent this is to

murchandamus commented at 11:56 pm on April 22, 2025:

For argument’s sake, it would only have to be re-activated for the coinbase transactions of the ten corresponding blocks, right?

darosior commented at 4:48 pm on April 23, 2025:

Sure, but if you go this route you could even say technically it only have to be reactivated if not all of the the corresponding coinbase transaction’s outputs were spent along with a non-duplicable input.

murchandamus commented at 0:20 am on April 23, 2025: contributor

I did another full review of this proposal. Most of my comments are nits, please feel free to take or leave those as you choose.

It is my impression that iterating over the four separate issues several times in each section makes it harder to put together the full picture for the proposal. It might be easier to read this proposal if the parts of each fix were grouped more closely.

darosior force-pushed on Apr 23, 2025

darosior commented at 5:13 pm on April 23, 2025: member

It might be easier to read this proposal if the parts of each fix were grouped more closely.

I took another look. I am obviously biased but to me it seems pretty clear and easy to follow. It is a short, concise, document which discusses 4 small fixes to consensus rules. In every section each small issue is discussed in its own paragraph. The ordering is conserved across sections.

Suggestions welcome of course, but at this point i am not interested in making much further changes.

in bip-0054.md:24 in f0ca398f34 outdated

19+[bip-0030][BIP30] validation.
20+
21+## Motivation
22+
23+This proposal addresses a number of long-standing vulnerabilities and weaknesses in the Bitcoin
24+protocol. Bundling these fixes together allows to overcome the fixed cost of deploying a Bitcoin

jonatack commented at 10:05 pm on April 23, 2025:

In the sentence “Bundling…” the claim seems unsubstantiated to erroneous. How does bundling BIPs constitute a material difference in the deployment cost; the activations of both SegWit and Taproot consisted of multiple BIPs. Suggest dropping the sentence entirely.

darosior commented at 6:30 pm on April 28, 2025:

You are misinterpreting the sentence. The bundle refers to the proposal, not the BIP.

in bip-0054.md:27 in f0ca398f34 outdated

22+
23+This proposal addresses a number of long-standing vulnerabilities and weaknesses in the Bitcoin
24+protocol. Bundling these fixes together allows to overcome the fixed cost of deploying a Bitcoin
25+soft fork.
26+
27+The timewarp bug permits a majority hashrate attacker to arbitrarily increase the block rate,

jonatack commented at 10:10 pm on April 23, 2025:

The timewarp bug hasn’t been referenced prior to here in this document.

Suggest beginning with a summary listing of terms/bugs and their definitions.

darosior commented at 6:30 pm on April 28, 2025:

Fair enough. Added a link to the description of the bug.

in bip-0054.md:35 in f0ca398f34 outdated

30+timestamp, the timewarp bug lets miners bring down the difficulty to its minimum within 38 days of
31+starting the attack. The existence of this bug not only significantly empowers a 51% attacker, but
32+also makes it notably harder to reason about miners' incentives. It could indeed be in the interest
33+of short-sighted miners as well as short-sighted users to exploit this vulnerability in a small
34+enough proportion to increase the block rate without fatally hurting the network, as the effectively
35+increased block space would — all other things equal — bring fee rates down for users.

jonatack commented at 10:11 pm on April 23, 2025:

0increased block space would — all other things being equal — bring fee rates down for users.

darosior commented at 6:29 pm on April 28, 2025:

Done.

in bip-0054.md:38 in f0ca398f34 outdated

32+also makes it notably harder to reason about miners' incentives. It could indeed be in the interest
33+of short-sighted miners as well as short-sighted users to exploit this vulnerability in a small
34+enough proportion to increase the block rate without fatally hurting the network, as the effectively
35+increased block space would — all other things equal — bring fee rates down for users.
36+
37+Specially crafted blocks may be expensive to process, with validation times ranging from a few

jonatack commented at 10:13 pm on April 23, 2025:

Suggest separating the different issues in the motivation section with individual headers to improve clarity. Better yet, a focused BIP per issue and its mitigation.

darosior commented at 6:29 pm on April 28, 2025:

I am not going to take this suggestion at the moment.

in bip-0054.md:129 in f0ca398f34 outdated

124+
125+## Backward compatibility
126+
127+This proposal only tightens the block validation rules: there is no block that is valid under the
128+rules proposed in this BIP but not under the existing Bitcoin consensus rules. As a consequence
129+these changes are backward-compatible with unupgraded node software. That said, the authors strongly

jonatack commented at 10:18 pm on April 23, 2025:

0these changes are backward-compatible with non-upgraded node software. That said, the authors strongly

darosior commented at 6:29 pm on April 28, 2025:

Done.

in bip-0054.md:134 in f0ca398f34 outdated

129+these changes are backward-compatible with unupgraded node software. That said, the authors strongly
130+encourage node operators to upgrade in order to fully validate all consensus rules.
131+
132+## Miner forward compatibility
133+
134+Bitcoin Core version [0.16.1][Core 0.16.1] and later will not relay nor create block templates which

jonatack commented at 10:20 pm on April 23, 2025:

Use either “neither…nor” or “not…or”, and “that” instead of “which”

0Bitcoin Core version [0.16.1][Core 0.16.1] and later will neither relay nor create block templates that

darosior commented at 6:29 pm on April 28, 2025:

Done.

in bip-0054.md:137 in f0ca398f34 outdated

132+## Miner forward compatibility
133+
134+Bitcoin Core version [0.16.1][Core 0.16.1] and later will not relay nor create block templates which
135+include 64-byte transactions.
136+
137+Bitcoin Core version [29.0][Core 29.0] and later will not generate a block template which violates

jonatack commented at 10:21 pm on April 23, 2025:

0Bitcoin Core version [29.0][Core 29.0] and later will not generate a block template that violates

darosior commented at 6:29 pm on April 28, 2025:

Done.

in bip-0054.md:144 in f0ca398f34 outdated

139+the grace period used in this proposal, miners should use the `curtime` or `mintime` field from the
140+`getblocktemplate` result for their block's timestamp to make sure they always create blocks valid
141+according to this proposal. Note this is not a new requirement: using a timestamp lower than the
142+`mintime` field from the `getblocktemplate` result already leads to creating an invalid block.
143+
144+Bitcoin Core as of version 29.0 may relay and create a block template including a transaction which

jonatack commented at 10:22 pm on April 23, 2025:

0Bitcoin Core as of version 29.0 may relay and create a block template that includes a transaction that

darosior commented at 6:29 pm on April 28, 2025:

Done.

in bip-0054.md:146 in f0ca398f34 outdated

141+according to this proposal. Note this is not a new requirement: using a timestamp lower than the
142+`mintime` field from the `getblocktemplate` result already leads to creating an invalid block.
143+
144+Bitcoin Core as of version 29.0 may relay and create a block template including a transaction which
145+violates the signature operations limit introduced in this BIP. A newer version of Bitcoin Core
146+which makes this type of transaction non-standard should be widely adopted before this soft fork is

jonatack commented at 10:22 pm on April 23, 2025:

0that makes this type of transaction non-standard should be widely adopted before this soft fork is

(Is this a SHOULD, or a MUST?)

darosior commented at 6:29 pm on April 28, 2025:

Done. “Should” is good here.

in bip-0054.md:159 in f0ca398f34 outdated

151+We encourage mining pools to update their software to craft coinbase transactions that are
152+forward-compatible with the changes proposed in this BIP.
153+
154+## Acknowledgements
155+
156+This document builds upon an [earlier proposal][BIP-XXXX] by one of the authors.

jonatack commented at 10:24 pm on April 23, 2025:

It seems odd not to name the author here.

0This document builds upon an [earlier proposal][BIP-XXXX] by Matt Corallo.

darosior commented at 6:28 pm on April 28, 2025:

I’m curious odd as in reading odd, or as in out of place like lacking attribution? Because i’ve seen this being used before and that’s why i used it here.

darosior commented at 6:30 pm on April 28, 2025:

(Took your suggestion either way.)

jonatack commented at 10:34 pm on April 23, 2025: member

It is my impression that iterating over the four separate issues several times in each section makes it harder to put together the full picture for the proposal. It might be easier to read this proposal if the parts of each fix were grouped more closely.

Agree with @murchandamus here.

I’d prefer to see separate, focused BIPs, as recommended in both BIP 2 and BIP 3, as that would be much clearer. Failing which, then clearer separation in this draft but -0.5 to -0.9 on that.

Reference code would be better as well, as highlighted by @murchandamus in https://github.com/bitcoin/bips/pull/1800/files#r2056793498 and related.

darosior closed this on Apr 23, 2025

Sjors commented at 11:06 am on April 24, 2025: member

It would be useful to mention the implication of reaching block LOCKTIME_THRESHOLD 500,000,000: https://github.com/bitcoin/bitcoin/pull/32155/commits/84c27595162a8cc3a6cc1754ef89c7d5adecddf4#r2053224512

IIUC (if we don’t deal with this along with the 2106 problem) it just means that in the far future coinbase transactions are timelocked to 1985. This is fine, they’re still spendable and they’re still unique since we require the exact height.

At this point there’s almost 200 comments on this PR, making it practically impossible for a reviewer to see if all feedback has been addressed. And then every time someone comments on a “resolved” thread, you have to scroll all the way up and unfold them all to find.

That slightly increases my preference for having a separate BIP for each change and one to combine them (as a fresh PR).

in bip-0054.md:135 in f0ca398f34 outdated

130+encourage node operators to upgrade in order to fully validate all consensus rules.
131+
132+## Miner forward compatibility
133+
134+Bitcoin Core version [0.16.1][Core 0.16.1] and later will not relay nor create block templates which
135+include 64-byte transactions.

murchandamus commented at 2:51 pm on April 24, 2025:

The 64-byte transaction paragraph is third above, but first in this section.

darosior commented at 6:28 pm on April 28, 2025:

It was done on purpose because it seemed to be “nicer” by increasing Bitcoin Core version number. But now that you point it it does seem clearer to keep the same ordering as in the other sections. Changed in latest push.

murchandamus commented at 3:39 pm on April 24, 2025: contributor

Hey, I feel that I should ensure that I made myself clear. This proposal fulfills the editorial criteria, and I’m happy to merge it as is. Thank you for working on this project.

To be precise, my suggestion was to keep it as one document, but to consider swapping the sections and subsection ordering, i.e.:

 0Current:
 1    Motivation
 2    - Timewarp
 3    - Block validation time
 4    - Merkle tree weakness
 5    - Coinbase duplication
 6
 7    Specification
 8    - Timewarp
 9    - Block validation time
10    - Merkle tree weakness
11    - Coinbase duplication
12
13    Rationale
14    - Timewarp
15    - Block validation time
16    - Merkle tree weakness
17    - Coinbase duplication
18
19    Miner forward compatibility
20    - Timewarp
21    - Block validation time
22    - Merkle tree weakness
23    - Coinbase duplication

 0Alternative:
 1    Timewarp
 2    - Motivation
 3    - Specification
 4    - Rationale
 5    - Miner forward compatibility
 6
 7    Block validation time
 8    - Motivation
 9    - Specification
10    - Rationale
11    - Miner forward compatibility
12
13    Merkle tree weakness
14    - Motivation
15    - Specification
16    - Rationale
17    - Miner forward compatibility
18
19    Coinbase duplication
20    - Motivation
21    - Specification
22    - Rationale
23    - Miner forward compatibility

It seems to me that this has a similar benefit as what people may be trying to achieve when they suggest splitting it into several BIPs. Given that multiple reviewers made similar suggestions, I figured it might be worth seeing what the document with the alternative order would look like instead of just speculating about it.

I reordered the content of this document (with minimal other changes to capture the sentences that applied to all fixes) in https://github.com/murchandamus/bips/commit/6f2b322e8fa06a041eea26a15ae403440bde097c. Please see the preview of the document with the alternative ordering, and the preview of the current document for comparison.

I prefer the alternative order as it seems more natural to me. I believe that it presents the information in a more accessible manner as the topics are grouped rather than the topic switching with every paragraph. I think it would make the document easier to read and to reference. I don’t think it is necessary to split it to four documents, but wouldn’t be opposed to that either.

To reiterate, this document already fulfills the editorial requirements, so I’m happy to merge it as is if that’s your preference whenever you have had a chance to address existing review.

Sjors commented at 6:48 am on April 25, 2025: member

Murch’s structure makes sense too. Perhaps another way to deal with the hard-to-review-ness of the current PR is to merge it at some stage and then continue editing via issues and pull requests? Those could be grouped in a Project.

darosior commented at 6:28 pm on April 28, 2025: member

Thank you @murchandamus for the clarification and for putting together your suggested alternative structure. Unfortunately i’m not going to take it, in my opinion having 4 sections with each a motivation-specs-rationale is confusing and makes it unnecessarily longer.

darosior reopened this on Apr 28, 2025

darosior force-pushed on Apr 28, 2025

Consensus Cleanup BIP draft 1ee43519dd

darosior force-pushed on Apr 28, 2025

darosior commented at 6:33 pm on April 28, 2025: member

It would be useful to mention the implication of reaching block LOCKTIME_THRESHOLD 500,000,000

Good point. I could have something akin to https://github.com/bitcoin/bitcoin/pull/32155#discussion_r2054067055 in the rationale? But i don’t think this should hold up this PR.

murchandamus commented at 8:47 pm on April 28, 2025: contributor

Alright. LGTM, then.

Sjors commented at 7:49 am on April 29, 2025: member

I think it’s fine to merge the current version as a Draft and then have others edit it further. I’m happy to review pull requests that do so, maybe add me as a Deputy?

jonatack assigned jonatack on Apr 29, 2025

jonatack commented at 10:23 pm on April 29, 2025: member

I prefer the alternative order as it seems more natural to me. I believe that it presents the information in a more accessible manner as the topics are grouped rather than the topic switching with every paragraph. I think it would make the document easier to read and to reference.

Agree.

I think it’s fine to merge the current version as a Draft and then have others edit it further. I’m happy to review pull requests that do so, maybe add me as a Deputy?

SGTM, ACK 1ee43519dd2520fbd8ad5c264bd4198acdba4863 (thank you for the latest updates)

jonatack merged this on Apr 29, 2025

jonatack closed this on Apr 29, 2025

Sjors commented at 10:45 am on April 30, 2025: member

So I don’t forget, in order to make sure miners set nLockTime and nSequence correctly, we could have getblocktemplate add !bip54 to its rules result field (at the moment of activation).

At the same time, like Bitcoin Core does with SegWit, clients add bip54 to the rules field in their request to indicate that they can handle it (any time before activation). Some time before activation Bitcoin Core could start emitting warnings if miners haven’t set this yet.

Per BIP9 using ! in the getblocktemplate response means that a miner must not use this template unless they’ve implemented the required changes. Bitcoin Core currently even refuses to make a template if segwit isn’t set.

We could then either:

expect miners to just implement this by using the existing height parameter; or
provide the required nLockTime and a suggested nSequence (only 1 bit is required)

Doing (2) would be more in line with what we already do in Stratum v2.

This can be its own BIP similar to BIP145 for SegWit. Or it can be part of this one, given that it’s much simpler.

This also ensures that, at least in Bitcoin Core, the version field will signal support if and only if the mining client supports it. Which reminds me that I need to check if / how the stratum v2 template code handles this.

darosior commented at 1:39 pm on April 30, 2025: member

maybe add me as a Deputy? @Sjors good idea, thanks for volunteering. But i think we have to wait for the editors to active BIP3 first?

BIP 54: Consensus Cleanup #1800

BIP 54: Consensus Cleanup #1800