-
Notifications
You must be signed in to change notification settings - Fork 1
Expand file tree
/
Copy pathindex.html
More file actions
1081 lines (1036 loc) · 50.5 KB
/
index.html
File metadata and controls
1081 lines (1036 loc) · 50.5 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>BIP54.org - The Consensus Cleanup - A Bitcoin soft fork proposal to
address four vulnerabilities and weaknesses in the Bitcoin protocol.</title>
<link rel="icon" type="image/x-icon" href="favicon.ico">
<!-- Open Graph / Facebook -->
<meta property="og:type" content="website">
<meta property="og:url" content="https://bip54.org/">
<meta property="og:title" content="BIP54.org - The Consensus Cleanup">
<meta property="og:description" content="BIP54 proposes four narrowly-scoped
changes to address vulnerabilities in Bitcoin's consensus rules: timewarp
attack, slow block validation, merkle tree exploits, and duplicate
transactions.">
<meta property="og:image" content="https://bip54.org/og-image.png">
<!-- Twitter -->
<meta name="twitter:card" content="summary_large_image">
<meta name="twitter:url" content="https://bip54.org/">
<meta name="twitter:title" content="BIP54.org - The Consensus Cleanup">
<meta name="twitter:description" content="BIP54 proposes four
narrowly-scoped changes to address vulnerabilities in Bitcoin's consensus
rules: timewarp attack, slow block validation, merkle tree exploits, and
duplicate transactions.">
<meta name="twitter:image" content="https://bip54.org/og-image.png">
<link rel="stylesheet" href="simple.min.css">
<link rel="stylesheet" href="custom.css">
</head>
<body>
<header>
<nav>
<ul>
<li><a href="#vulnerabilities">Vulnerabilities</a></li>
<li><a href="#faq">FAQ</a></li>
<li><a href="#timeline">Timeline</a></li>
<li><a href="#resources">Resources</a></li>
</ul>
</nav>
<h1>BIP54.org</h1>
<p>
Bitcoin has four known vulnerabilities that have gone unfixed for
15 years. <a
href="https://github.com/bitcoin/bips/blob/master/bip-0054.md">BIP54</a>,
"Consensus Cleanup", proposes four narrowly-scoped changes to
address these issues in Bitcoin's consensus rules that date back to the
original version of Bitcoin in 2009.
</p>
</header>
<main>
<h2><a href="#summary" id="summary">Executive Summary</a></h2>
<p class="notice">
These four flaws could allow for <a href="#timewarp">effectively
breaking the network with 6 blocks per second</a>, <a
href="#block-validation">poison blocks that take over an hour to
validate</a>, <a href="#merkle-vulnerability">forging
transactions</a> for SPV verifiers, and require computationally
expensive handling of <a href="#duplicate-transactions">duplicate
transactions</a>. These issues have been discussed for 7 years and
the fixes are now well-understood and narrowly scoped. These
represent systemic risks to Bitcoin's security and decentralization
that become more dangerous as Bitcoin's value and adoption grow.
</p>
<section>
<header>
<h2><a href="#vulnerabilities" id="vulnerabilities">The four
vulnerabilities</a></h2>
</header>
<article>
<header>
<h3><a href="#timewarp" id="timewarp">Timewarp
attack</a></h3>
</header>
<p>
Timewarp is an exploit of Bitcoin's difficulty adjustment
algorithm that allows miners controlling a large amount of
hashrate to increase how fast blocks are mined. <mark>The
attack could render the network non-viable with 6 blocks per
second</mark>, mine the remaining subsidy, and impact the
ability of users to run a full node.
<details>
<summary>Technical details and fix</summary>
<div id="timewarp-details">
<h4>How the attack works</h4>
<p>Bitcoin adjusts mining difficulty every 2,016
blocks to maintain an average 10-minute block time.
However, the current difficulty adjustment compares
the timestamps of the first and last block of a period,
a span that covers only 2,015 block intervals.</p>
<p>This creates an <a
href="https://bitcoin.stackexchange.com/questions/1511/gaming-the-off-by-one-bug-difficulty-re-target-based-on-2015-instead-of-2016">"off-by-one"
bug</a>: the first block of a difficulty adjustment
period is different from the last block of the previous
period. Miners exploiting the timewarp attack manipulate
this gap by:</p>
<ol>
<li>Setting the timestamp of the <strong>last
block</strong> in each difficulty period to the
maximum allowed value (up to 2 hours in the
future)</li>
<li>Setting the timestamp of the <strong>first
block</strong> of the next period to the minimum
allowed value (up to several hours in the past,
constrained only by <a
href="https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki">Median
Time Past</a>)</li>
</ol>
<p>This timestamp manipulation makes each period
appear to have taken longer than it actually did,
causing difficulty to decrease. The attack can be
repeated indefinitely with a compounding effect,
progressively reducing difficulty to its minimum value.</p>
<h4>Impact</h4>
<p>Once difficulty reaches the minimum, a majority
of hashrate could mine blocks as fast as the Median
Time Past rule allows which is approximately <a
href="https://bitcoin.stackexchange.com/questions/123698/how-many-blocks-per-second-can-sustainably-be-created-using-a-time-warp-attack">six
blocks per second</a>. At this rate:</p>
<ul>
<li>All remaining block subsidy could be mined
in roughly <strong>40 days</strong></li>
<li>Bitcoin's controlled supply schedule would
be destroyed</li>
<li>UTXO set growth, network bandwidth, and
validation requirements would spike dramatically
with faster blocks, forcing out nodes on
consumer hardware and accelerating
centralization</li>
<li>Timelock-based contracts would break,
including Lightning Network channels, HTLCs
(Hash Time Locked Contracts), and other
protocols that rely on <code>nLockTime</code>,
<code>OP_CHECKLOCKTIMEVERIFY</code> or
<code>OP_CHECKSEQUENCEVERIFY</code> providing a
stable measure of time. Accelerated block
production would cause timelocks to expire much
faster than intended, potentially allowing theft
of funds</li>
<li>Transaction confirmation assumptions like "N
confirmations = X minutes of security" would be
broken, as confirmations would arrive orders of
magnitude faster than expected</li>
</ul>
<h4>BIP54's fix</h4>
<p>BIP54 prevents timewarp attacks by requiring a
minimum timestamp for the first block in a
difficulty period based on the timestamp of its
predecessor, the last block of the prior difficulty
period. This restriction on shifting the start of a
difficulty period precludes the timestamp
manipulation across period boundaries necessary for
the timewarp attack.</p>
<p>The fix also includes a two-hour grace period
after each difficulty adjustment to accommodate
natural timestamp variation.</p>
<h4>Variants</h4>
<p>The <a
href="https://delvingbitcoin.org/t/zawy-s-alternating-timestamp-attack/1062#variant-on-zawys-attack-2"><strong>Murch-Zawy
timewarp variant</strong></a> circumvents the above
rule by setting the end timestamps of 2 difficulty
periods several weeks into the future to achieve a
greater decrease in difficulty by the time the chain
is accepted. To ensure the chain is eventually
accepted by the wider network and doesn't always
have timestamps too far in the future, this attack
has to alternate with 1 difficulty period which is
closer to the real time, thereby increasing the
difficulty momentarily. It therefore takes longer to
drain the subsidy.</p>
<p>BIP54 also addresses this variant through
requiring that the timestamp of the last block in a
difficulty period must be greater than (or equal to)
the timestamp of the first block in the same
period.</p>
<p>Since in any case, nodes will follow the chain
with most cumulative PoW, the attacks above both
require 51% control of hashrate. Even if blocks were
produced at a higher rate in one fork, the
preference for highest cumulative PoW still imposes
this constraint on an attacker. These new rules
limit the damage that can be inflicted, should an
attacker control 51% of the hashrate during a few
weeks/months.</p>
<p>Read more: <a
href="https://www.bitmex.com/blog/the-timewarp-attack">"The
timewarp attack"</a> from BitMEX Research</p>
</div>
</details>
</p>
</article>
<article>
<header>
<h3><a href="#block-validation" id="block-validation">Hard
to validate blocks</a></h3>
</header>
<p>
A well-prepared attacker can create <mark>specially-crafted
"poison blocks" that take more than an hour to verify</mark>
on certain computers, allowing for various denial-of-service
attacks.
<details>
<summary>Technical details and fix</summary>
<div id="block-validation-details">
<h4>The problem</h4>
<p>Legacy Bitcoin transactions (pre-segwit) can be
specially crafted to artificially increase their
validation times. Various techniques may be used to
exploit improper resource usage limits and quadratic
behaviour in validation of pre-segwit Bitcoin Script.</p>
<p>An attacker can exploit this to create blocks that
can take <strong>several hours to validate</strong> on
lower-end hardware, even though it is valid according
to current consensus rules. A variation of this attack
is for a miner to delay its competition with blocks that
take under a minute to validate but are significantly
cheaper to create, to systematically delay its competition.</p>
<p>While most experts would be able to figure out how
to create hard-to-validate blocks, details have been
discussed in a private Delving Bitcoin thread out of
an abundance of caution. A <a href="https://groups.google.com/g/bitcoindev/c/wOVjJoLDWfA/m/xV0afQDRAAAJ">
demo was performed on the Signet test network</a> in
March 2026.</p>
<h4>Attack scenarios</h4>
<ul>
<li>Denial of service due to nodes spending
excessive time validating malicious blocks fall
behind the chain tip, making them vulnerable to
eclipse attacks or causing them to be
partitioned from the network</li>
<li>Longer block validation and propagation times
increase stale rate, disproportionately advantaging
larger miners at the expense of smaller ones</li>
<li>Prohibitive block validation times may:
<ul>
<li>incentivize miners to skip it in favour of non-technical enforcement
mechanisms (typically, through legal contracts)</li>
<li>Push out node operators using less performant hardware</li>
</ul>
</ul>
<h4>BIP54's fix</h4>
<p>BIP54 introduces a <strong>per-transaction limit
of 2,500 legacy sigops</strong>. This is a
conservative limit since normal transactions use far
fewer sigops. Even then, reaching this limit
requires a transaction that deliberately inflates
validation costs, which is the behavior this fix
aims to prevent. The limit does not apply to segwit
transactions, which represent 90% of today's traffic,
since they are by definition not affected by this issue.</p>
<p>The fix reduces worst-case block validation time
by approximately <strong>40x</strong> while
minimizing the risk of confiscating coins locked in
unusual legacy scripts. Bitcoin Core has already
made transactions exceeding this limit <a
href="https://bitcoinops.org/en/newsletters/2025/07/25/#bitcoin-core-32521">non-standard</a>
as a forward-compatibility measure, meaning miners
running Bitcoin Core will not include these transactions
in their blocks by default.</p>
<p>Read more: <a href="https://www.bitmex.com/blog/attack-blocks">"Attack Blocks"</a> from BitMEX Research</p>
</div>
</details>
</p>
</article>
<article>
<header>
<h3><a href="#merkle-vulnerability"
id="merkle-vulnerability">Forging confirmed
transactions</a></h3>
</header>
<p>
A carefully-constructed Bitcoin transaction makes it
possible to <mark>trick SPV verifiers (including SPV wallet
users) into accepting what looks like a transaction that's
part of the most proof-of-work chain</mark> but which is not
actually part of the chain and which has never been verified
by a full node.
<details>
<summary>Technical details and fix</summary>
<div id="merkle-vulnerability-details">
<h4>The vulnerability</h4>
<p>Bitcoin's merkle tree implementation has a flaw
in that a 64-byte transaction has exactly the same
size as an internal merkle tree node (two 32-byte
hashes concatenated). An attacker can construct a
transaction whose serialized form is identical to a
merkle tree node, allowing them to forge merkle
proofs.</p>
<h4>How the attack works</h4>
<p>Simplified Payment Verification (SPV) verifiers
don't download or validate full blocks. Instead,
they verify that a transaction is included in a
block by checking a merkle proof, a path of hashes
from the transaction up to the merkle root in the
block header.</p>
<p>By crafting a 64-byte transaction that matches an
internal merkle node hash, an attacker can:</p>
<ol>
<li>Create an arbitrarily-sized fake transaction that appears to
have valid proof-of-work behind it</li>
<li>Present a merkle proof to an SPV verifier
showing this "transaction" is confirmed</li>
<li>Trick the wallet or verifier into accepting
payment that was never actually validated by any
full node</li>
</ol>
<p>The attacker doesn't need to mine blocks or
perform expensive proof-of-work. They do need
however to perform about 70 bits of work to
construct a malicious merkle tree structure and
present it to the victim's SPV wallet/verifier.</p>
<h4>Impact on SPV wallets and verifiers</h4>
<p>This vulnerability undermines the security model
of SPV verification and lightweight wallets. While
<a
href="https://bitcoin.stackexchange.com/questions/37696/have-any-spv-users-lost-money-because-they-accepted-forged-bitcoins">no
known real-world losses</a> have occurred, the
attack is theoretically sound and exploitable. SPV
verifiers are used in various contexts including
mobile wallets and other resource-constrained
environments as well as by side-systems to validate
deposits, making this a concern for Bitcoin's
usability and security.</p>
<h4>BIP54's fix</h4>
<p>BIP54 takes a straightforward approach:
<strong>make all 64-byte transactions
invalid</strong> at the consensus level. This
prevents anyone from creating transactions that
could be confused with internal merkle tree
nodes.</p>
<p>This fix is safe because any 64-byte transaction
is necessarily insecure: it must contain at most one
output, which must either burn the coins or be
spendable by anyone. The practical impact is minimal
as such transactions are inherently unsafe to
use.</p>
<p>The related <a
href="https://bitcoinops.org/en/newsletters/2025/05/30/#bips-1760">BIP53</a>
formally specifies the 64-byte transaction ban,
which is incorporated into BIP54's broader consensus
cleanup.</p>
<p>Read more: <a
href="https://www.bitmex.com/blog/64-Byte-Transactions">"64
Byte Transactions"</a> from BitMEX Research</p>
</div>
</details>
</p>
</article>
<article>
<header>
<h3><a href="#duplicate-transactions"
id="duplicate-transactions">Duplicate transactions</a></h3>
</header>
<p>
Bitcoin's consensus rules use transaction IDs to uniquely
identify transactions, so duplicate transactions
can cause unwanted behavior including loss of funds and
other <mark>attack vectors</mark>.
<details>
<summary>Technical details and fix</summary>
<div id="duplicate-transaction-details">
<h4>Historical incidents</h4>
<p>In Bitcoin's early history, <a
href="https://bitcoin.stackexchange.com/questions/80644/identical-coinbase-transactions">identical
coinbase transactions</a> were actually mined in two
separate pairs of blocks:</p>
<ul>
<li>Blocks 91,722 and 91,880 (same coinbase
transaction)</li>
<li>Blocks 91,812 and 91,842 (same coinbase
transaction)</li>
</ul>
<p>When the second block in each pair was mined, the
UTXO from the first block was effectively destroyed.
The coins became unspendable because the UTXO
database only keeps one entry per transaction ID.
This resulted in permanent loss of 100 BTC (50 BTC
from each duplicate).</p>
<h4>Why this was possible</h4>
<p>Early Bitcoin had no mechanism to ensure coinbase
transactions were unique. Miners could create
identical coinbase transactions in different blocks,
producing the same transaction ID. Since Bitcoin's
UTXO set uses transaction IDs as part of the keys,
the second occurrence would overwrite the first,
destroying the earlier coins.</p>
<p>Additionally, Bitcoin's design assumption that
transaction IDs uniquely identify transactions
breaks down when duplicates exist, creating
potential consensus failures and attack vectors.</p>
<h4>BIP30 fixes the vulnerability</h4>
<p><a
href="https://bitcoin.stackexchange.com/questions/5903/where-can-i-learn-more-about-bip30-namely-the-exploit-and-the-background-discus">BIP30</a>
(activated in 2012) fixed this vulnerability by
requiring that new transactions cannot have the same
ID as an existing transaction whose outputs haven’t
all been spent. This is a stopgap to prevent
duplicate coinbase transactions from overwriting
existing UTXOs. However, BIP30 requires
computationally unnecessary overhead for enforcement
for every block. Additionally, alternative
full-validation models being explored, like Utreexo,
may not be able to perform BIP30 validation at
all.</p>
<p><a
href="https://bitcoin.stackexchange.com/questions/75987/why-was-bip34-block-v2-height-in-coinbase-not-implemented-via-the-coinbase-tx">BIP34</a>
(activated in 2013) required coinbase transactions
to include the block height in their coinbase field
(similar to scriptSig, with different rules), which
made coinbase transactions effectively unique. This
allowed nodes to skip the expensive BIP30 checks in
most cases.</p>
<p>However, BIP34 has a known gap: some early
coinbase transactions happened to contain data that
matches valid future block heights, meaning BIP30
checks would need to be re-enabled around
<strong>block 2,000,000</strong> (approximately year
2047).</p>
<h4>Why BIP30 needs improvement</h4>
<p>While BIP30 successfully prevents duplicate
transactions, it has two inefficiencies. First, the
checks are computationally expensive. Second,
BIP34's gap means that around block 2,000,000, nodes
would need to re-enable full BIP30 validation for
every block.</p>
<h4>BIP54's improvement</h4>
<p>BIP54 improves the BIP34 fix to BIP30 by
<strong>requiring coinbase transactions to set their
nLockTime field to the block height minus
1</strong>. Since nLockTime is currently unused in
coinbase transactions, this adds transaction
uniqueness without disrupting existing uses.</p>
<p>This requirement ensures that every coinbase
transaction will be unique by construction, closing
the BIP34 gap and allowing nodes to permanently skip
expensive BIP30 checks. Bitcoin Core's <a
href="https://bitcoinops.org/en/newsletters/2025/05/16/#bitcoin-core-32155">internal
miner</a> has already been updated to implement this
requirement.</p>
<p>Read more: <a
href="https://www.bitmex.com/blog/bitcoins-duplicate-transactions">"Bitcoin's
Duplicate Transactions"</a> from BitMEX Research</p>
</div>
</details>
</p>
</article>
</section>
<section>
<h2><a href="#faq" id="faq">FAQ</a></h2>
<details id="faq-whynow">
<summary>Why do BIP54 now?</summary>
<div>
<p>These vulnerabilities have existed since Bitcoin's launch in
2009. While none are known to have been exploited on mainnet yet,
they represent systemic risks to Bitcoin's security and
decentralization. The <a href="#timewarp">timewarp attack</a> could
allow a majority of hashrate to mine all remaining block subsidy in
just 40 days. <a href="#block-validation">Slow-to-validate
blocks</a> create denial-of-service attack vectors and
centralization pressure. The <a href="#merkle-vulnerability">merkle
tree vulnerability</a> enables attacks on SPV verifiers, and <a
href="#duplicate-transactions">duplicate transactions</a> risk is
mitigated by BIP30 but BIP54 significantly improves that fix.</p>
<p>These issues have been discussed for 7 years and BIP54 has been
refined over two years of research and community discussion since <a
href="https://groups.google.com/g/bitcoindev/c/CAfm7D5ppjo">Antoine
Poinsot revived</a> <a
href="https://gnusha.org/pi/bitcoindev/bf96c2fb-2e2e-a47f-e59f-87e56d83eca3@mattcorallo.com/">Matt
Corallo's 2019 proposal</a>. The fixes are now well-understood,
narrowly scoped, and have <a
href="https://bitcoinops.org/en/newsletters/2025/11/07/#bip54-implementation-and-test-vectors">test
vectors and implementation code</a> ready. Waiting longer only
increases the window during which these vulnerabilities could be
exploited.</p>
</div>
</details>
<details id="faq-safe">
<summary>Is BIP54 safe? Could it break existing uses of Bitcoin?</summary>
<div>
<p>BIP54 is designed to be a safe <a href="#faq-hardfork">soft
fork</a> that minimizes disruption to existing Bitcoin usage. The
proposal has been carefully refined to avoid confiscating coins or
breaking legitimate use cases:</p>
<ul>
<li><strong>64-byte transaction ban:</strong> Only affects a
very specific edge case. Any 64-byte transaction is necessarily
insecure as it must contain at most one output that either burns
coins or is spendable by anyone.</li>
<li><strong>Legacy sigops limit:</strong> The 2,500 sigops per
transaction limit is set conservatively high. Normal
transactions use far fewer sigops, and Bitcoin Core has already
made transactions exceeding this limit <a
href="https://bitcoinops.org/en/newsletters/2025/07/25/#bitcoin-core-32521">non-standard</a>
as a forward-compatibility measure. Any transaction that would
hit this limit may be split into multiple transactions that don't,
ensuring that no UTXO is directly made unspendable.</li>
<li><strong>Timewarp fix:</strong> Only constrains timestamps at
difficulty period boundaries. Normal mining operations are
unaffected, and the fix includes a grace period as a
belt-and-suspenders safety measure.</li>
<li><strong>Coinbase locktime requirement:</strong> Miners
simply set the coinbase locktime field, whose usage is currently
unspecified. This change is already implemented in <a
href="https://bitcoinops.org/en/newsletters/2025/05/16/#bitcoin-core-32155">Bitcoin
Core's internal miner</a> and is in the process of being
adopted by mining pools.</li>
</ul>
</div>
</details>
<details id="faq-objections">
<summary>What objections to BIP54 remain?</summary>
<div>
<p>The main remaining objections center on the coinbase locktime
requirement and the 64-byte transaction ban:</p>
<ul>
<li><strong>Coinbase locktime:</strong> Some argue that
requiring coinbase transactions to set nLockTime to the block
height reduces miner flexibility, as this field could otherwise
be used as extra nonce space. <a
href="https://gnusha.org/pi/bitcoindev/UsKuvCXXhSAnNVx5a0K2UfP3srAr3slW9mcOjtYk9LnolaOXfWrW9jpqbxsQQPkyQuZogkhz2Hbfwii2VsTm79vRDpgKduxk35hpBu_t7Do=@protonmail.com/">Proponents
counter</a> that miners have other nonce sources available and
that improving the existing fix against <a
href="#duplicate-transactions">duplicate coinbase
transactions</a> is more important.</li>
<li><strong>64-byte transaction invalidation:</strong> Some
<a href="https://gnusha.org/pi/bitcoindev/UsKuvCXXhSAnNVx5a0K2UfP3srAr3slW9mcOjtYk9LnolaOXfWrW9jpqbxsQQPkyQuZogkhz2Hbfwii2VsTm79vRDpgKduxk35hpBu_t7Do=@protonmail.com/">suggest</a>
alternative approaches like introducing a whole new
merkle tree that would allow 64-byte transactions. However,
these alternatives would require more invasive consensus
changes, while the simple ban affects virtually no real-world
usage.</li>
</ul>
<p>Overall, BIP54 is considered relatively uncontroversial compared
to other soft fork proposals, as it addresses clear vulnerabilities
without enabling new functionality that might have uncertain
implications. Discussion continues on <a
href="https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710">Delving
Bitcoin</a>.</p>
</div>
</details>
<details id="faq-user-action">
<summary>What would an average user have to do if BIP54 activates?</summary>
<div>
<p><strong>Nothing.</strong> BIP54 is a soft fork that activates
at the consensus layer and requires no action from average Bitcoin
users:</p>
<ul>
<li><strong>Wallet users:</strong> No action required. Your
wallet will continue to work normally. The changes don't affect
how you send, receive, or store bitcoin.</li>
<li><strong>Node operators:</strong> Upgrading to a version of
Bitcoin Core (or other node software) that includes BIP54 is
recommended but not required. Non-upgraded nodes will still
follow the chain and see all transactions, though they won't
enforce the new rules themselves.</li>
<li><strong>Transactions:</strong> You don't need to do anything
different. Normal transactions are completely unaffected by
BIP54's changes.</li>
</ul>
<p>The fixes happen in the background to make Bitcoin more
secure and robust.</p>
</div>
</details>
<details id="faq-bundling">
<summary>Why bundle these four fixes together instead of doing four separate soft forks?</summary>
<div>
<p>Bundling these fixes together offers several advantages:</p>
<ul>
<li><strong>Reduced coordination burden:</strong> One soft fork
activation is significantly simpler than coordinating four
separate ones. The ecosystem goes through one upgrade cycle
instead of four, minimizing disruption and overhead for
developers, node operators, miners, and the broader Bitcoin
infrastructure.</li>
<li><strong>Categorically related:</strong> All four fixes address
long-standing consensus bugs and vulnerabilities rather than
adding new features. They naturally belong together as a
"consensus cleanup" package.</li>
<li><strong>Review complexity:</strong> Bundling
them doesn't significantly increase review complexity compared
to reviewing them separately.</li>
</ul>
<p>Potential downsides are:</p>
<ul>
<li><strong>All-or-nothing approach:</strong> If one fix becomes
controversial, it could delay the entire package.</li>
<li><strong>Precedent concerns:</strong> Some worry that bundling
could set a precedent for future soft forks to bundle unrelated
or controversial changes together, potentially forcing through
less desirable features by packaging them with necessary
fixes.</li>
</ul>
<p>Proponents argue these risks are mitigated in BIP54's case
because all four fixes are security improvements (not new features)
addressing existing vulnerabilities, and they're categorically
related as "consensus cleanup." If any fix did become unexpectedly
problematic, it could potentially be removed from the bundle before
activation. The precedent would be specifically for bundling related
security fixes, not for mixing unrelated proposals or features with
bug fixes.</p>
<p>The Bitcoin community must weigh these tradeoffs and whether the
efficiency gains and reduced coordination burden of bundling
outweigh the flexibility and governance concerns of separate soft
forks for this particular set of fixes.</p>
</div>
</details>
<details id="faq-whatif">
<summary>What will happen to Bitcoin if we don't do BIP54?</summary>
<div>
<p>Bitcoin would continue to carry known vulnerabilities that could
be exploited:</p>
<ul>
<li><strong>Timewarp attack risk:</strong> A mining majority could
manipulate block timestamps to reduce difficulty and mine blocks
far faster than intended, potentially destabilizing Bitcoin's monetary
policy and crippling the network in the process.</li>
<li><strong>Denial-of-service exposure:</strong> Attackers could
create slow to validate blocks that would skew miner incentive
and raise the bar to join the network and perform full validation.</li>
<li><strong>SPV verifier vulnerability:</strong> The 64-byte
transaction issue allows attackers to forge merkle proofs,
tricking SPV verifiers (wallets, side systems) into accepting
transactions that don't exist on the main chain.</li>
<li><strong>Duplicate transaction burden:</strong> Around block
2 million, preventing duplicate transaction imposes an additional
burden on block validation and precludes alternative full node
designs (like Utreexo).</li>
</ul>
<p>These represent exploitable attack vectors that become more
dangerous as Bitcoin's value and adoption grow.</p>
</div>
</details>
<details id="faq-covenants">
<summary>Why not covenants first?</summary>
<div>
<p>BIP54 and covenant proposals (like OP_CTV, OP_CAT, or other
script upgrades) serve completely different purposes and are not
mutually exclusive:</p>
<ul>
<li><strong>BIP54 fixes vulnerabilities</strong> that already
exist in Bitcoin. These are security issues that need to be
addressed regardless of what new features are added.</li>
<li><strong>Covenants add new functionality</strong> to enable
advanced smart contracts, vaults, payment pools, and other
features that don't currently exist in Bitcoin.</li>
</ul>
<p>The "covenants first" argument essentially suggests leaving known
security holes open while debating the design space for new
features. It is up to the community to determine if security fixes
should be prioritized independently of feature additions.
Additionally, BIP54 is much less controversial than covenant
designs, making it a more straightforward path to consensus.</p>
<p>There's no technical reason these can't proceed in parallel or in
either order. The Bitcoin community can work on both.</p>
</div>
</details>
<details id="faq-testnet4">
<summary>Testnet4 has these consensus cleanup fixes and keeps breaking. Does that mean BIP54 is broken?</summary>
<div>
<p>No. The <a
href="https://github.com/bitcoin/bips/blob/master/bip-0094.mediawiki">testnet4</a>
test network includes <em>some</em> consensus cleanup rules
(portions of the timewarp fix, but not the fix against the
Murch-Zawy attack), but testnet breakage is unrelated to those
rules. Test networks are meant to be disposable environments where
developers can experiment without the constraints of mainnet.</p>
<p>Importantly, testnet4 has special difficulty adjustment rules
that don't exist on mainnet: if no block is found for 20 minutes,
difficulty resets to minimum. This testnet-specific rule creates
instability and disruption that wouldn't occur on Bitcoin mainnet,
where difficulty adjustments follow strict 2,016-block periods.</p>
<p>The timewarp fix on testnet4 has worked as intended. When
testnet4 has reset or experienced issues, these have been due to
other factors like the 20-minute difficulty reset rule, low
hashrate, difficulty gaming, or intentional stress testing, not
failures of the consensus cleanup rules themselves.</p>
<p>BIP54's <a
href="https://github.com/bitcoin-inquisition/bitcoin/pull/99">implementation
on Bitcoin Inquisition</a> (on the signet test network) provides a
more controlled testing environment with <a
href="https://bitcoinops.org/en/newsletters/2025/11/07/#bip54-implementation-and-test-vectors">comprehensive
test vectors</a> covering all the edge cases.</p>
</div>
</details>
<details id="faq-quantum">
<summary>What about quantum?</summary>
<div>
<p>Quantum computing resistance is a separate concern from the
vulnerabilities BIP54 addresses. BIP54 is about fixing specific bugs
and attack vectors in Bitcoin's existing consensus rules: timewarp,
slow validation, merkle tree exploits, and duplicate
transactions.</p>
<p>Quantum-resistant cryptography would require a different set of
changes (possibly a new address format and signature algorithm) and
is still an area of active research. The timeline for quantum
computers threatening Bitcoin's elliptic curve cryptography is
uncertain.</p>
<p>BIP54 should be evaluated on its own merits as a security
upgrade. It neither helps nor hinders future quantum resistance
efforts, and there's no reason to delay fixing known vulnerabilities
while waiting for quantum-resistant proposals to mature.</p>
</div>
</details>
<details id="faq-hardfork">
<summary>Is BIP54 a hard fork or a soft fork?</summary>
<div>
<p>BIP54 is a <strong>soft fork</strong> which is a
backwards-compatible Bitcoin consensus change. After activation,
nodes that haven't upgraded will still follow the chain and
recognize blocks as valid, though they won't enforce the new rules
themselves. Soft forks only tighten the consensus rules; they don't
expand what's considered valid.</p>
</div>
</details>
<details id="faq-abuse">
<summary>Could this soft fork facilitate non-monetary use of Bitcoin?</summary>
<div>
<p>Segwit expanded what could be done by adding on a separate
storage area for witness data. On the contrary, the BIP54 soft fork
only strictly narrows the scope of what is allowed.
It limits pre-segwit transaction outputs, block header timestamps,
coinbase transaction locktimes & sequence, and bans transaction
sizes of 64 bytes.
It is orthogonal to the concerns related to the usage of Bitcoin
transactions to store arbitrary data and does not relax relay
policy.</p>
</div>
</details>
<details id="faq-activation">
<summary>How would BIP54 activate?</summary>
<div>
<p>The activation mechanism for BIP54 has not yet been finalized.
<a href="https://bitcoinops.org/en/topics/soft-fork-activation/">Previous Bitcoin soft forks</a> have used mechanisms like <a
href="https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki">BIP9</a>
(version bits with miner signaling), <a
href="https://github.com/bitcoin/bips/blob/master/bip-0008.mediawiki">BIP8</a>
(user-activated soft fork with optional miner signaling), or
combinations thereof.</p>
<p>The activation debate is separate from the technical merits of
the proposal itself. Once there is rough consensus on the changes
BIP54 proposes, the community will need to agree on an activation
method that balances user activation, miner coordination, and
network safety.</p>
</div>
</details>
<details id="faq-contribute">
<summary>How can I help with BIP54?</summary>
<div>
<p>There are several ways to contribute:</p>
<ul>
<li><strong>Review the proposal:</strong> Read <a
href="https://github.com/bitcoin/bips/blob/master/bip-0054.md">BIP54</a>
and provide technical feedback on the <a
href="https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710">Delving
Bitcoin thread</a>.</li>
<li><strong>Test the implementation:</strong> Run <a
href="https://github.com/bitcoin-inquisition/bitcoin/pull/99">Bitcoin
Inquisition</a> on signet and test BIP54's behavior with the
provided test vectors.</li>
<li><strong>Educate others:</strong> Share information about
BIP54's goals and benefits.</li>
<li><strong>Miner outreach:</strong> If you operate mining
infrastructure or know people who do, ensure they understand the
forward-compatibility requirements (especially the <a
href="https://bnoc.xyz/t/forward-compatible-coinbase-locktimes-for-bip-54/75">coinbase
locktime changes</a>).</li>
<li><strong>Improve this website:</strong> If you have a
suggestion or improvement, see this website's repository on <a
href="https://github.com/bitschmidty/bip54">GitHub</a>.</li>
</ul>
</div>
</details>
</section>
<section>
<h2><a href="#timeline" id="timeline">Timeline</a></h2>
<h3><a href="#progress" id="progress">In progress</a></h3>
<ul>
<li>Community review and feedback</li>
<li>Miners decide to implement <a
href="https://bnoc.xyz/t/forward-compatible-coinbase-locktimes-for-bip-54/75">forward-compatible
coinbase locktimes for BIP54</a>
<ul>
<li><a href="https://mainnet.observer/charts/mining-pools-mining-bip54-coinbase/">First BIP-54 Coinbase Transactions by Pool</a> - mainnet-observer</li>
<li><a href="https://mainnet.observer/charts/transactions-coinbase-locktime-bip54/">BIP-54 Coinbase Locktime set</a> - mainnet-observer</li>
</ul>
</ul>
<h3><a href="#future" id="future">Future</a></h3>
<ul>
<li>Soft fork activation parameters</li>
<li>Bitcoin Core pull request for BIP54 implementation</li>
</ul>
<h3><a href="#history" id="history">History</a></h3>
<h4>2026</h4>
<ul>
<li><a href="https://groups.google.com/g/bitcoindev/c/iCuq6bFKt5Y">64-Byte Transactions and Potential Legitimate Uses</a></li>
<li><a href="https://groups.google.com/g/bitcoindev/c/wOVjJoLDWfA/m/xV0afQDRAAAJ">Demo of hard to validate blocks on Signet test network</a>
<ul>
<li><a href="https://bnoc.xyz/t/slowish-blocks-on-signet/100">Slowish blocks on signet</a> - BNOC</li>
<li><a href="https://delvingbitcoin.org/t/consensus-cleanup-demo-of-slow-blocks-on-signet/2367">Consensus Cleanup: demo of slow blocks on Signet</a> - Delving Bitcoin</li>
</ul></li>
<li><a
href="https://github.com/bitcoin-inquisition/bitcoin/pull/99">Bitcoin
Inquisition #99 merges BIP54 implementation on signet</a></li>
<li><a
href="https://bitcoinops.org/en/newsletters/2026/01/02/#relax-bip54-timestamp-restriction-for-2106-soft-fork">Discussion
of BIP54's timewarp fix and its impact on the 2106 block timestamp
overflow issue</a></li>
</ul>
<h4>2025</h4>
<ul>
<li><a
href="https://bitcoinops.org/en/newsletters/2025/11/07/#bip54-implementation-and-test-vectors">BIP54
implementation and test vectors</a></li>
<li><a
href="https://bitcoinops.org/en/newsletters/2025/07/25/#bitcoin-core-32521">Bitcoin
Core #32521 makes legacy transactions with more than 2500 sigops
non-standard</a></li>
<li><a
href="https://bitcoinops.org/en/newsletters/2025/05/30/#bips-1760">BIPs
#1760 merges BIP53, which specifies a consensus change to forbid 64
byte transactions</a></li>
<li><a
href="https://bitcoinops.org/en/newsletters/2025/05/16/#bitcoin-core-32155">Bitcoin
Core #32155 updates the internal miner to comply with consensus
cleanup requirements</a></li>
<li><a
href="https://bitcoinops.org/en/newsletters/2025/05/09/#bips-1800">BIPs
#1800 merges BIP54, which specifies the consensus cleanup soft fork
proposal</a></li>
<li><a
href="https://bitcoinops.org/en/newsletters/2025/04/04/#draft-bip-published-for-consensus-cleanup">Draft
BIP published for consensus cleanup</a></li>
<li><a
href="https://bitcoinops.org/en/newsletters/2025/02/07/#updates-to-cleanup-soft-fork-proposal">Announcement
of updates to the consensus cleanup soft fork proposal</a></li>
</ul>
<h4>2024</h4>
<ul>
<li><a
href="https://bitcoinops.org/en/newsletters/2024/12/06/#continued-discussion-about-consensus-cleanup-soft-fork-proposal">Discussion
about fixing Murch-Zawy time warp and duplicate transactions in
consensus cleanup</a></li>
<li><a
href="https://bitcoinops.org/en/newsletters/2024/09/06/#mitigating-merkle-tree-vulnerabilities">Discussion
about mitigating merkle tree vulnerabilities in the proposed
consensus cleanup soft fork</a></li>
<li><a
href="https://bitcoinops.org/en/newsletters/2024/05/01/#coredev-tech-berlin-event">Notes
from Bitcoin developer discussion about consensus cleanup</a></li>
<li><a
href="https://bitcoinops.org/en/newsletters/2024/04/24/#where-exactly-is-the-off-by-one-difficulty-bug">Question:
where exactly is the 'off-by-one' difficulty bug and how does it
relate to time warp?</a></li>
<li><a
href="https://bitcoinops.org/en/newsletters/2024/04/03/#revisiting-consensus-cleanup">Renewed
discussion of consensus cleanup soft fork</a></li>
</ul>
<h4>2020</h4>
<ul>
<li><a
href="https://bitcoinops.org/en/newsletters/2020/05/27/#minimum-transaction-size-discussion">Discussion
of minimum safe transaction sizes</a></li>
</ul>
<h4>2019</h4>
<ul>
<li><a
href="https://bitcoinops.org/en/newsletters/2019/12/28/#cleanup">2019
year-in-review: consensus cleanup soft fork proposal</a></li>
<li><a
href="https://bitcoinops.org/en/newsletters/2019/06/12/#cleanup-discussion">CoreDev.tech
discussion: cleanup soft fork</a></li>
<li><a
href="https://bitcoinops.org/en/newsletters/2019/03/12/#cleanup-soft-fork-proposal-discussion">Consensus
cleanup discussion: codeseparator & sighash types</a></li>
<li><a
href="https://bitcoinops.org/en/newsletters/2019/03/05#appendix-consensus-cleanup-background">Consensus
cleanup background</a></li>
<li><a
href="https://bitcoinops.org/en/newsletters/2019/03/05#cleanup-soft-fork-proposal">Cleanup
soft fork proposal</a></li>
</ul>
</section>
<section>
<h2><a href="#resources" id="resources">Resources</a></h2>
<h3><a href="#resources-summaries" id="resources-summaries">Summaries</a></h3>
<ul>
<li><a
href="https://bitcoinmagazine.com/print/the-core-issue-consensus-cleanup">The
Core Issue: Consensus Cleanup</a> - Bitcoin Magazine</li>
<li><a
href="https://www.bitmex.com/blog/the-timewarp-attack">The
timewarp attack</a> - BitMEX Research</li>
<li><a
href="https://www.bitmex.com/blog/bitcoins-duplicate-transactions">Bitcoin's
Duplicate Transactions</a> - BitMEX Research</li>
<li><a
href="https://www.bitmex.com/blog/64-Byte-Transactions">64 Byte
Transactions</a> - BitMEX Research</li>
<li><a
href="https://x.com/Bitcoin_Devs/status/2034308520464834706">The
64-byte Transaction Bug Explained Simply</a> - Bitcoin Dev
Project</li>
<li><a
href="https://www.bitmex.com/blog/attack-blocks">Attack Blocks</a> - BitMEX Research</li>
</ul>
<h3><a href="#resources-specification" id="resources-specification">Specification</a></h3>
<ul>
<li><a
href="https://github.com/bitcoin/bips/blob/master/bip-0054.md">BIP54</a>
- Bitcoin Improvement Proposals repository</li>
<li><a href="https://bips.dev/54/">BIP54 reader-friendly
rendering</a> - bips.dev</li>
<li><a href="https://github.com/bitcoin/bips/pull/1800">BIPs PR
#1800, the PR that merged BIP54 into bitcoin/bips</a> - Bitcoin
Improvement Proposals repository</li>
</ul>
<h3><a href="#resources-mailing-list" id="resources-mailing-list">Mailing list posts</a></h3>
<ul>
<li><a
href="https://groups.google.com/g/bitcoindev/c/wOVjJoLDWfA/m/zWcDG7_7CQAJ">BIP
54 live on Bitcoin Inquisition</a> (February 2026)</li>
<li><a
href="https://groups.google.com/g/bitcoindev/c/znBz5MA7_Bo/m/RVVGlYBNAAAJ">Bip54:
add sequence, timestamp (and version) to GBT</a> (February
2026)</li>
<li><a
href="https://groups.google.com/g/bitcoindev/c/6TTlDwP2OQg">Addressing
remaining points on BIP 54</a> (January 2026)</li>
<li><a
href="https://groups.google.com/g/bitcoindev/c/L4Eu9bA5iBw/m/jo9RzS-HAQAJ">Does
GCC preclude a soft fork to handle timestamp overflow?
</a> and <a
href="https://delvingbitcoin.org/t/modifying-bip54-to-support-future-ntime-soft-fork/2163">related
Delving Bitcoin forum post</a> (December 2025)</li>
<li><a
href="https://groups.google.com/g/bitcoinminingdev/c/jlqlNHHNSNk/m/RBT_LBWQAgAJ">Call
for mining pools to make their coinbase transactions compatible
with BIP 54</a> (November 2025)</li>
<li><a
href="https://groups.google.com/g/bitcoindev/c/rf3QOlzg230">Update
on the Great Consensus Cleanup Revival</a> (February 2025)</li>
<li><a
href="https://groups.google.com/g/bitcoindev/c/CAfm7D5ppjo">Great
Consensus Cleanup Revival</a> (March 2024)</li>
<li><a
href="https://gnusha.org/pi/bitcoindev/bf96c2fb-2e2e-a47f-e59f-87e56d83eca3@mattcorallo.com/">BIP Proposal: The Great Consensus Cleanup</a> (March
2019)</li>
</ul>
<h3><a href="#resources-discussion" id="resources-discussion">Technical discussion</a></h3>
<ul>
<li><a
href="https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710">Great
Consensus Cleanup Revival</a> - Delving Bitcoin</li>
<li><a
href="https://bitcoinops.org/en/topics/consensus-cleanup-soft-fork/">Consensus
Cleanup Soft Fork</a> — Bitcoin Optech topic page</li>
</ul>
<h3><a href="#resources-implementation" id="resources-implementation">Implementation</a></h3>
<ul>