Great Consensus Cleanup Revival

It targets critical issues such as the timewarp vulnerability in mining difficulty adjustment, which could otherwise be exploited to artificially lower network difficulty, undermining security and stability. The proposal recommends precise changes to retarget periods—mandating that timestamps for the last block of any retarget period cannot precede those of the first block—to eliminate negative timespans and prevent manipulation tactics like the Murch-Zawy attack. This solution is complemented by discussions on whether such timestamp limits should be enforced globally across all blocks or selectively at each 2016-block interval. Proponents argue for minimal, targeted changes to consensus rules to avoid unforeseen complications, while still ensuring robust protection against attacks.

Another focal point is the mitigation of validation slowdowns caused by maliciously crafted non-SegWit transactions. The proposal introduces constraints on legacy script usage and caps the size of legacy transactions, greatly reducing the worst-case validation time (by a factor of forty) without introducing confiscatory risks. These changes are informed by real-world measurements, where certain blocks have been shown to require several minutes—or even over an hour on less powerful hardware—to validate. Community feedback has been instrumental in refining these mitigations, ensuring they balance security with practical deployment and do not inadvertently lead to asset confiscation.

The integrity of the blockchain’s structure is further reinforced by addressing vulnerabilities in merkle root computation. Transactions of exactly 64 bytes present a unique risk; the inability to distinguish them from internal nodes in the merkle tree can enable subtle attacks on SPV (Simplified Payment Verification) proofs and sidechains. Rather than adopting complex workarounds, the consensus coalesces around simply making 64-byte transactions consensus-invalid. This approach provides clarity, reduces implementation complexity for SPV and other lightweight clients, and preempts potential exploits—even though no 64-byte transaction has ever occurred in Bitcoin’s history, as confirmed by exhaustive scans (see GitHub analysis).

A suite of additional consensus improvements is outlined, including enforcing uniqueness in coinbase transactions via new requirements for their nLockTime field, set to match the previous block’s height. This standardization not only streamlines extraction of block height from the coinbase but also closes loopholes that could otherwise allow duplicate coinbases. Discussions have evaluated multiple approaches, weighing the merits of encoding block height in different fields (nLockTime, nVersion) and debating the precise activation schedule for these changes. Ultimately, activating such rules after ample lead time—potentially as much as twenty-one years hence—is favored for smooth transition and broad miner compliance.

The management of signature operation limits (sigops) is another area of focus. Legacy scripts, bare outputs, and P2SH inputs are now subject to a per-transaction cap of 2,500 sigops, with accounting methods harmonized across contexts. For example, in CheckMultisig (CMS) operations, sigops are counted according to the number of keys (up to sixteen), defaulting to twenty in ambiguous cases. Historical analysis demonstrates that this adjustment would not retroactively validate any previously invalid transactions, and the shift aligns with the natural decline in large legacy multisignature use in favor of more efficient SegWit alternatives.

Significant attention is given to the mechanisms underlying SPV security and bandwidth optimization. Arguments against introducing new consensus rules solely for wallet efficiency are tempered by evidence that failing to address obscure but dangerous edge cases—such as malleable block hashes or indistinguishable merkle tree nodes—can expose side-systems to catastrophic vulnerabilities. As demonstrated in smart contract platforms like Keep Network’s tBTC (see source), unawareness of such risks may result in severe losses. Thus, the cleanup’s pragmatic stance favors clear, enforceable consensus rules over reliance on documentation or best practices alone.

The technical evolution of mining protocols is also addressed. Updates in Stratum v2 specify roles for ASICs and pool software in managing version bits (BIP320), extraNonce spaces, and timestamp rolling. Strategies to maximize hash rates and optimize coinbase data alignment are explored, considering both current hardware and anticipated future needs. The flexibility in reserving block space for coinbase transactions is juxtaposed with actual miner behavior, revealing that the modest increase required for additional nonce data has negligible revenue impact under present conditions.

In terms of testability and deployment, the proposal is backed by extensive empirical