Great Consensus Cleanup - Revision history

NotATether: Rewrite Great Consensus Cleanup with cited sections

2026-10-09T17:49:24Z

Rewrite Great Consensus Cleanup with cited sections

← Older revision		Revision as of 17:49, 9 October 2026
Line 1:		Line 1:
	The '''Great Consensus Cleanup''' is a proposed ~~Bitcoin~~ [[Softfork\|soft fork]] ~~specified as BIP 54 ("Consensus Cleanup") by Antoine Poinsot and Matt Corallo. It~~ would ~~tighten~~ four long-standing consensus ~~edge cases~~: a timewarp attack ~~that manipulates~~ difficulty ~~retarget timestamps~~, worst-case legacy signature~~-operation cost~~, 64-byte ~~transaction ambiguity~~ in the [[Merkle tree]], and ~~future~~ duplicate ~~coinbases~~ that would ~~force~~ a return to BIP 30 validation~~. The BIP status is Complete~~. It is ~~not a mainnet consensus rule. No activation parameters have been assigned.~~		The '''Great Consensus Cleanup''' is a proposed [[Softfork\|soft fork]] that would fix four long-standing weaknesses in Bitcoin's consensus rules: the timewarp attack on difficulty adjustment, the worst-case validation cost of legacy signature operations, the ambiguity of 64-byte transactions in the [[Merkle tree]], and the possibility of duplicate coinbase transactions that would require a return to BIP 30 validation. It is specified as BIP 54, "Consensus Cleanup", by Antoine Poinsot and Matt Corallo. The BIP has the status Complete and is not part of the mainnet consensus rules.<ref name="bip54">[https://github.com/bitcoin/bips/blob/master/bip-0054.md BIP 54: Consensus Cleanup]</ref>

	~~Matt Corallo posted an earlier cleanup draft in 2019.~~ Antoine Poinsot ~~revived the work on Delving Bitcoin in 2024 after measuring validation-time attacks~~ and ~~restating the timewarp incentive problem~~. The BIP ~~number was assigned in April 2025. Status was advanced to~~ Complete ~~after test vectors~~ and ~~a reference implementation existed, which in the BIP process means the authors consider the rules ready for an activation discussion,~~ not ~~that miners have activated them. Each item restricts currently valid blocks. The bundle is meant to amortize the coordination cost~~ of ~~a soft fork that adds no new Script features.~~

	~~After an activation height, four rules would apply. If~~ the block height N is divisible by 2016, nTime must be at least the previous block's timestamp minus 7200 seconds. If N modulo 2016 equals 2015, nTime must be at least the timestamp of the block at height N minus 2015, so that a difficulty period cannot have negative duration. The two-hour grace is looser than the 600-second bound used on [[Testnet4]], after broken pool software on testnet produced timestamps that would have violated a ten-minute grace. Median-time-past still applies.

	Non-coinbase transactions may not exceed 2500 signature operations counted as in BIP 16: each CHECKSIG counts as one, and CHECKMULTISIG counts as 1 to 16 or as 20 depending on the preceding opcode, whether or not the opcode executes. The cap is the tightest value the authors found that left non-pathological standard transactions valid. It targets constructions that made some blocks take minutes to hours to validate on ordinary hardware. It does not disable opcodes.

	A transaction whose witness-stripped serialized size is exactly 64 bytes is invalid. A 64-byte serialization can be read either as a leaf (a txid) or as an inner Merkle node (two 32-byte hashes). That ambiguity lets an SPV verifier be shown a proof for a transaction that is not in the block. Such transactions are anyone-can-spend or unspendable, have been nonstandard since 2018–2019, and have not been used on mainnet ~~since 2016~~. ~~Invalidating them removes the ambiguity for proofs of every other transaction without requiring light clients to apply a workaround.~~

	~~The coinbase's~~ [[NLockTime\|nLockTime]] must equal the block height minus 1, and nSequence must not be 0xffffffff. Combined with existing locktime semantics, that forces each new coinbase to differ from early BIP 34 violations and from previous coinbases. Nodes can then skip BIP 30 duplicate-txid checks after activation, including at the future heights where a BIP 34-era coinbase could otherwise reappear. The rule also lets software recover the height without parsing the coinbase script.

	~~The changes are backward compatible for old nodes in the soft-fork sense~~: ~~a block valid under BIP 54 is already valid today. Miners who do not upgrade would still need to follow the new rules once a majority of hash rate enforces them, or they would mine invalid blocks.~~

	~~Bitcoin Core pull request 35793 implements the validation rules without mainnet activation~~. ~~Signet experimentation has exercised related behaviour. Bitcoin Core 29.0 avoids templates that violate the proposed timestamp bounds. Bitcoin Core 30.0 avoids templates that violate the signature~~-~~operation cap~~. ~~Witness-stripped 64-byte transactions have been nonstandard to relay since 0.16.1. Some mining pools have produced coinbases that already set locktime in the~~ BIP 54 ~~way. That is forward compatibility, not version-bit signalling. No activation bit is assigned.~~

	== History ==		== History ==

NotATether: Rewrite Great Consensus Cleanup with cited sections

2026-10-09T17:41:04Z

Rewrite Great Consensus Cleanup with cited sections

@@ Line 15: / Line 15: @@
 Bitcoin Core pull request 35793 implements the validation rules without mainnet activation. Signet experimentation has exercised related behaviour. Bitcoin Core 29.0 avoids templates that violate the proposed timestamp bounds. Bitcoin Core 30.0 avoids templates that violate the signature-operation cap. Witness-stripped 64-byte transactions have been nonstandard to relay since 0.16.1. Some mining pools have produced coinbases that already set locktime in the BIP 54 way. That is forward compatibility, not version-bit signalling. No activation bit is assigned.
-== See also ==
+== History ==
-* [[Softfork]]
+Each of the four changes only restricts blocks that are valid today. The fixes are bundled into a single proposal to spread the fixed cost of deploying a Bitcoin soft fork across all of them. The proposal adds no new Script features.<ref name="bip54"/>
 * [[Testnet4]]
-* [[Taproot]]
+== Proposed rules ==
-* [[NLockTime]]
+The following rules would apply to every block after activation.<ref name="bip54"/>
-* [[Merkle tree]]
 == See also ==

NotATether: Rewrite Great Consensus Cleanup with cited sections

2026-10-09T17:33:20Z

Rewrite Great Consensus Cleanup with cited sections

← Older revision		Revision as of 17:33, 9 October 2026
Line 22:		Line 22:
	* [[NLockTime]]		* [[NLockTime]]
	* [[Merkle tree]]		* [[Merkle tree]]

			== See also ==
			* [[Softfork]]
			* [[Testnet4]]
			* [[Taproot]]
			* [[NLockTime]]
			* [[Merkle tree]]

			== References ==
			<references />

	== External links ==		== External links ==

	* [https://github.com/bitcoin/bips/blob/master/bip-0054.md BIP 54: Consensus Cleanup]		* [https://github.com/bitcoin/bips/blob/master/bip-0054.md BIP 54: Consensus Cleanup]

	* [https://github.com/bitcoin/bitcoin/pull/35793 Bitcoin Core PR 35793]		* [https://github.com/bitcoin/bitcoin/pull/35793 Bitcoin Core PR 35793]
	* [https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710 ~~Delving Bitcoin:~~ Great Consensus Cleanup ~~revival~~]		* [https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710 Great Consensus Cleanup Revival] on Delving Bitcoin
	* [https://github.com/TheBlueMatt/bips/blob/cleanup-softfork/bip-XXXX.mediawiki 2019 ~~Corallo~~ draft]		* [https://github.com/TheBlueMatt/bips/blob/cleanup-softfork/bip-XXXX.mediawiki 2019 Great Consensus Cleanup draft] by Matt Corallo

	[[Category:Technical]]		[[Category:Technical]]

NotATether: Great Consensus Cleanup: soft-fork compatibility, Core PR 35793, template guards; more external links

2026-09-26T08:33:58Z

Great Consensus Cleanup: soft-fork compatibility, Core PR 35793, template guards; more external links

← Older revision		Revision as of 08:33, 26 September 2026
Line 10:		Line 10:

	The coinbase's [[NLockTime\|nLockTime]] must equal the block height minus 1, and nSequence must not be 0xffffffff. Combined with existing locktime semantics, that forces each new coinbase to differ from early BIP 34 violations and from previous coinbases. Nodes can then skip BIP 30 duplicate-txid checks after activation, including at the future heights where a BIP 34-era coinbase could otherwise reappear. The rule also lets software recover the height without parsing the coinbase script.		The coinbase's [[NLockTime\|nLockTime]] must equal the block height minus 1, and nSequence must not be 0xffffffff. Combined with existing locktime semantics, that forces each new coinbase to differ from early BIP 34 violations and from previous coinbases. Nodes can then skip BIP 30 duplicate-txid checks after activation, including at the future heights where a BIP 34-era coinbase could otherwise reappear. The rule also lets software recover the height without parsing the coinbase script.

			The changes are backward compatible for old nodes in the soft-fork sense: a block valid under BIP 54 is already valid today. Miners who do not upgrade would still need to follow the new rules once a majority of hash rate enforces them, or they would mine invalid blocks.

			Bitcoin Core pull request 35793 implements the validation rules without mainnet activation. Signet experimentation has exercised related behaviour. Bitcoin Core 29.0 avoids templates that violate the proposed timestamp bounds. Bitcoin Core 30.0 avoids templates that violate the signature-operation cap. Witness-stripped 64-byte transactions have been nonstandard to relay since 0.16.1. Some mining pools have produced coinbases that already set locktime in the BIP 54 way. That is forward compatibility, not version-bit signalling. No activation bit is assigned.

	== See also ==		== See also ==
Line 22:		Line 26:

	* [https://github.com/bitcoin/bips/blob/master/bip-0054.md BIP 54: Consensus Cleanup]		* [https://github.com/bitcoin/bips/blob/master/bip-0054.md BIP 54: Consensus Cleanup]

			* [https://github.com/bitcoin/bitcoin/pull/35793 Bitcoin Core PR 35793]
			* [https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710 Delving Bitcoin: Great Consensus Cleanup revival]
			* [https://github.com/TheBlueMatt/bips/blob/cleanup-softfork/bip-XXXX.mediawiki 2019 Corallo draft]

	[[Category:Technical]]		[[Category:Technical]]

NotATether: Great Consensus Cleanup: 64-byte tx invalidity and coinbase locktime uniqueness

2026-09-26T08:18:55Z

Great Consensus Cleanup: 64-byte tx invalidity and coinbase locktime uniqueness

← Older revision		Revision as of 08:18, 26 September 2026
Line 6:		Line 6:

	Non-coinbase transactions may not exceed 2500 signature operations counted as in BIP 16: each CHECKSIG counts as one, and CHECKMULTISIG counts as 1 to 16 or as 20 depending on the preceding opcode, whether or not the opcode executes. The cap is the tightest value the authors found that left non-pathological standard transactions valid. It targets constructions that made some blocks take minutes to hours to validate on ordinary hardware. It does not disable opcodes.		Non-coinbase transactions may not exceed 2500 signature operations counted as in BIP 16: each CHECKSIG counts as one, and CHECKMULTISIG counts as 1 to 16 or as 20 depending on the preceding opcode, whether or not the opcode executes. The cap is the tightest value the authors found that left non-pathological standard transactions valid. It targets constructions that made some blocks take minutes to hours to validate on ordinary hardware. It does not disable opcodes.

			A transaction whose witness-stripped serialized size is exactly 64 bytes is invalid. A 64-byte serialization can be read either as a leaf (a txid) or as an inner Merkle node (two 32-byte hashes). That ambiguity lets an SPV verifier be shown a proof for a transaction that is not in the block. Such transactions are anyone-can-spend or unspendable, have been nonstandard since 2018–2019, and have not been used on mainnet since 2016. Invalidating them removes the ambiguity for proofs of every other transaction without requiring light clients to apply a workaround.

			The coinbase's [[NLockTime\|nLockTime]] must equal the block height minus 1, and nSequence must not be 0xffffffff. Combined with existing locktime semantics, that forces each new coinbase to differ from early BIP 34 violations and from previous coinbases. Nodes can then skip BIP 30 duplicate-txid checks after activation, including at the future heights where a BIP 34-era coinbase could otherwise reappear. The rule also lets software recover the height without parsing the coinbase script.

	== See also ==		== See also ==

NotATether: Great Consensus Cleanup: timewarp timestamp bounds and legacy sigop cap

2026-09-26T08:03:36Z

Great Consensus Cleanup: timewarp timestamp bounds and legacy sigop cap

← Older revision		Revision as of 08:03, 26 September 2026
Line 2:		Line 2:

	Matt Corallo posted an earlier cleanup draft in 2019. Antoine Poinsot revived the work on Delving Bitcoin in 2024 after measuring validation-time attacks and restating the timewarp incentive problem. The BIP number was assigned in April 2025. Status was advanced to Complete after test vectors and a reference implementation existed, which in the BIP process means the authors consider the rules ready for an activation discussion, not that miners have activated them. Each item restricts currently valid blocks. The bundle is meant to amortize the coordination cost of a soft fork that adds no new Script features.		Matt Corallo posted an earlier cleanup draft in 2019. Antoine Poinsot revived the work on Delving Bitcoin in 2024 after measuring validation-time attacks and restating the timewarp incentive problem. The BIP number was assigned in April 2025. Status was advanced to Complete after test vectors and a reference implementation existed, which in the BIP process means the authors consider the rules ready for an activation discussion, not that miners have activated them. Each item restricts currently valid blocks. The bundle is meant to amortize the coordination cost of a soft fork that adds no new Script features.

			After an activation height, four rules would apply. If the block height N is divisible by 2016, nTime must be at least the previous block's timestamp minus 7200 seconds. If N modulo 2016 equals 2015, nTime must be at least the timestamp of the block at height N minus 2015, so that a difficulty period cannot have negative duration. The two-hour grace is looser than the 600-second bound used on [[Testnet4]], after broken pool software on testnet produced timestamps that would have violated a ten-minute grace. Median-time-past still applies.

			Non-coinbase transactions may not exceed 2500 signature operations counted as in BIP 16: each CHECKSIG counts as one, and CHECKMULTISIG counts as 1 to 16 or as 20 depending on the preceding opcode, whether or not the opcode executes. The cap is the tightest value the authors found that left non-pathological standard transactions valid. It targets constructions that made some blocks take minutes to hours to validate on ordinary hardware. It does not disable opcodes.

	== See also ==		== See also ==

NotATether: Great Consensus Cleanup: 2019 draft, 2024 revival, BIP assigned April 2025

2026-09-26T07:49:31Z

Great Consensus Cleanup: 2019 draft, 2024 revival, BIP assigned April 2025

← Older revision		Revision as of 07:49, 26 September 2026
Line 1:		Line 1:
	The '''Great Consensus Cleanup''' is a proposed Bitcoin [[Softfork\|soft fork]] specified as BIP 54 ("Consensus Cleanup") by Antoine Poinsot and Matt Corallo. It would tighten four long-standing consensus edge cases: a timewarp attack that manipulates difficulty retarget timestamps, worst-case legacy signature-operation cost, 64-byte transaction ambiguity in the [[Merkle tree]], and future duplicate coinbases that would force a return to BIP 30 validation. The BIP status is Complete. It is not a mainnet consensus rule. No activation parameters have been assigned.		The '''Great Consensus Cleanup''' is a proposed Bitcoin [[Softfork\|soft fork]] specified as BIP 54 ("Consensus Cleanup") by Antoine Poinsot and Matt Corallo. It would tighten four long-standing consensus edge cases: a timewarp attack that manipulates difficulty retarget timestamps, worst-case legacy signature-operation cost, 64-byte transaction ambiguity in the [[Merkle tree]], and future duplicate coinbases that would force a return to BIP 30 validation. The BIP status is Complete. It is not a mainnet consensus rule. No activation parameters have been assigned.

			Matt Corallo posted an earlier cleanup draft in 2019. Antoine Poinsot revived the work on Delving Bitcoin in 2024 after measuring validation-time attacks and restating the timewarp incentive problem. The BIP number was assigned in April 2025. Status was advanced to Complete after test vectors and a reference implementation existed, which in the BIP process means the authors consider the rules ready for an activation discussion, not that miners have activated them. Each item restricts currently valid blocks. The bundle is meant to amortize the coordination cost of a soft fork that adds no new Script features.

	== See also ==		== See also ==

NotATether: Create Great Consensus Cleanup: BIP 54 Consensus Cleanup proposal (Complete, not activated)

2026-09-26T07:38:40Z

Create Great Consensus Cleanup: BIP 54 Consensus Cleanup proposal (Complete, not activated)

New page

The '''Great Consensus Cleanup''' is a proposed Bitcoin [[Softfork|soft fork]] specified as BIP 54 ("Consensus Cleanup") by Antoine Poinsot and Matt Corallo. It would tighten four long-standing consensus edge cases: a timewarp attack that manipulates difficulty retarget timestamps, worst-case legacy signature-operation cost, 64-byte transaction ambiguity in the [[Merkle tree]], and future duplicate coinbases that would force a return to BIP 30 validation. The BIP status is Complete. It is not a mainnet consensus rule. No activation parameters have been assigned.

== See also ==

* [[Softfork]]
* [[Testnet4]]
* [[Taproot]]
* [[NLockTime]]
* [[Merkle tree]]

== External links ==

* [https://github.com/bitcoin/bips/blob/master/bip-0054.md BIP 54: Consensus Cleanup]

[[Category:Technical]]