-
Notifications
You must be signed in to change notification settings - Fork 0
/
upgrade-history.html
813 lines (745 loc) · 59.6 KB
/
upgrade-history.html
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
<!DOCTYPE html>
<html lang="en" data-bs-theme="dark">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover">
<meta name="format-detection" content="telephone=no">
<!--Prevents browsers from trying to make a number a clickable phone number (can still use "tel:" if we want this functionality)-->
<!--<meta http-equiv="cache-control" content="no-cache, no-store, must-revalidate"> telling browswer to NOT cache-->
<!--Web-App Capable-->
<meta name="mobile-web-app-capable" content="yes">
<meta name="apple-mobile-web-app-title" content="BCH Upgrades">
<meta name="apple-mobile-web-app-status-bar-style" content="black">
<link rel="apple-touch-icon" sizes="192x192" href="images/UpgradeGraphics/BCHUpgrades_Icons/24.png">
<!-- Canonical link for SEO -->
<link href="https://minisatoshi.cash/upgrade-history" rel="canonical" data-rh="true">
<link href="https://minisatoshi.cash/upgrade-history" hreflang="x-default" rel="alternate" data-rh="true">
<!-- Primary Meta Tags -->
<title>Bitcoin Cash Upgrade History</title>
<meta name="title" content="Bitcoin Cash Upgrade History">
<meta name="description" content="View the full history of Bitcoin Cash upgrades since 2009. Find additional resources as well including future upgrades planned, upgrades in discussion, and a link to the general research forum!">
<!-- Use Google Search Console and Bing Webmaster Tools for SEO data -->
<!-- Open Graph / Facebook -->
<meta property="og:type" content="website">
<meta property="og:url" content="https://minisatoshi.cash/upgrade-history">
<meta property="og:title" content="Bitcoin Cash Upgrade History">
<meta property="og:description" content="History of Bitcoin Cash upgrades since 2009">
<meta property="og:image" content="https://minisatoshi.cash/images/UpgradeGraphics/BCHUpgrades_Icons/24.svg">
<meta property="og:image:alt" content="minisatoshi.cash homepage image.">
<meta property="og:article:section" content="Information">
<meta property="og:article:tag" content="Bitcoin">
<meta property="og:article:tag" content="Bitcoin Cash">
<meta property="og:article:tag" content="BCH">
<meta property="og:article:tag" content="Cryptocurrencies">
<meta property="og:article:tag" content="Upgrades">
<meta property="og:article:tag" content="History">
<!-- Twitter -->
<meta property="twitter:card" content="summary_large_image">
<meta property="twitter:url" content="https://minisatoshi.cash/upgrade-history">
<meta name="twitter:site" content="@_minisatoshi">
<meta name="twitter:creator" content="@_minisatoshi">
<meta property="twitter:title" content="Bitcoin Cash Upgrade History">
<meta property="twitter:description" content="History of Bitcoin Cash upgrades since 2009">
<meta property="twitter:image" content="https://minisatoshi.cash/images/minisatoshicash.jpg">
<!-- Meta Tags Generated with https://metatags.io -->
<meta name="keywords" content="Bitcoin, Bitcoin Cash, BTC, BCH, cryptocurrency upgrades, blockchain upgrade history, crypto software updates, bitcoin upgrade timeline, crypto protocol updates, blockchain version history, crypto network improvements, digital currency upgrades, crypto upgrade announcements, blockchain technology updates">
<meta name="robots" content="index, follow">
<meta name="language" content="English">
<meta name="revisit-after" content="7 days">
<meta name="author" content="_minisatoshi">
<!-- Favicon -->
<link rel="icon" type="image/x-icon" href="favicon.ico">
<link rel="icon" type="images/png" href="favicon.png">
<!-- Fonts -->
<link href="https://fonts.googleapis.com/css2?family=Ubuntu:ital,wght@0,300;0,400;0,500;0,700;1,300;1,400;1,500;1,700&display=swap" rel="stylesheet" type="text/css" media="all">
<!-- CSS -->
<link rel="stylesheet" href="css/main.css?v=0.55">
<!-- Bootstrap -->
<link href="https://cdn.jsdelivr.net/npm/[email protected]/dist/css/bootstrap.min.css" rel="stylesheet" integrity="sha384-QWTKZyjpPEjISv5WaRU9OFeRpok6YctnYmDr5pNlyT2bRjXh0JMhjY6hW+ALEwIH" crossorigin="anonymous">
<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/[email protected]/font/bootstrap-icons.min.css">
<!-- Schema -->
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "minisatoshi",
"alternateName": "minisatoshi",
"url": "https://minisatoshi.cash/upgrade-history",
"logo": "https://minisatoshi.cash/images/UpgradeGraphics/BCHUpgrades_Icons/24.svg",
"sameAs": [
"https://x.com/_minisatoshi",
"https://github.com/minisat0shi"
]
}
</script>
</head>
<body class="upgrade-history" data-bs-smooth-scroll="true">
<nav class="navbar bg-dark-subtle border-bottom navbar-bch-glow navbar-expand-xl fixed-top">
<div class="container-fluid">
<button class="navbar-toggler" type="button" data-bs-toggle="collapse" data-bs-target="#navbarText" aria-controls="navbarText" aria-expanded="false" aria-label="Toggle navigation">
<span class="navbar-toggler-icon"></span>
</button>
<div class="collapse navbar-collapse" id="navbarText">
<ul class="navbar-nav fs-5 me-auto mb-1 mb-lg-0">
<li class="nav-item">
<a class="nav-link" href="index.html#">Home</a>
</li>
<li class="nav-item">
<a class="nav-link" href="index.html#_about">The Mission</a>
</li>
<li class="nav-item">
<a class="nav-link" href="index.html#_bch">What is BCH?</a>
</li>
<li class="nav-item">
<a class="nav-link" href="index.html#_socials">Social System</a>
</li>
<li class="nav-item">
<a class="nav-link" href="index.html#_more">Learn More</a>
</li>
<li class="nav-item">
<a class="nav-link" href="forkmap">Fork Map</a>
</li>
<li class="nav-item">
<a class="nav-link active" aria-current="page" href="#">Upgrade History</a>
</li>
<li class="nav-item">
<a class="nav-link" href="ecosystem">Ecosystem</a>
</li>
</ul>
</div>
<div class="dropdown theme-switcher">
<button class="btn btn-secondary dropdown-toggle fs-6" type="button" id="themeDropdown" data-bs-toggle="dropdown" aria-expanded="false">
<i id="themeIcon" class="bi bi-moon-stars-fill"></i>
</button>
<ul class="dropdown-menu dropdown-menu-end" aria-labelledby="themeDropdown">
<li><a class="dropdown-item fs-6" href="#" data-theme="light"><i class="bi bi-brightness-high-fill"></i> Light</a></li>
<li><a class="dropdown-item fs-6" href="#" data-theme="dark"><i class="bi bi-moon-fill"></i> Dark</a></li>
</ul>
</div>
</div>
</nav>
<!-- Back to top button -->
<button type="button" data-mdb-button-init data-mdb-ripple-init class="btn btn-info btn-floating" id="btn-back-to-top">
<i class="bi bi-arrow-bar-up fs-3"></i>
</button>
<style>
#btn-back-to-top {
position: fixed;
bottom: 20px;
right: 20px;
display: none;
z-index: 2;
}
</style>
<script>
//Get the button
let mybutton = document.getElementById("btn-back-to-top");
// When the user scrolls down 20px from the top of the document, show the button
window.onscroll = function () {
scrollFunction();
};
function scrollFunction() {
if (
document.body.scrollTop > 20 ||
document.documentElement.scrollTop > 20
) {
mybutton.style.display = "block";
} else {
mybutton.style.display = "none";
}
}
// When the user clicks on the button, scroll to the top of the document
mybutton.addEventListener("click", backToTop);
function backToTop() {
document.body.scrollTop = 0;
document.documentElement.scrollTop = 0;
}
</script>
<div class="fixed-nav-adjustment"></div>
<!-- Section: Timeline -->
<h1 class="fw-bold text-break text-center pt-5 px-3">Bitcoin Cash Upgrade History</h1>
<section class="py-5">
<div class="container timeline-main">
<ul id="sharedHistory" class="timeline">
<li id="hardFork" class="timeline-item mb-5 pb-5">
<img class="upgrade-icon-large" alt="Original Bitcoin Logo" src="images/UpgradeGraphics/bitcoinOgLogo.png" />
<h3 id="upgrade0-Creation" class="fw-bold text-break share-item">Bitcoin Released<span class="ms-2 share-button" data-bs-toggle="tooltip" data-bs-placement="top" title="Share"><i class="bi bi-share"></i></span></h3>
<p class="fs-4 mb-1">2009-01-03</p>
</li>
<li id="softFork" class="timeline-item mb-5">
<img class="upgrade-icon-small" alt="nLockTime Enforcement graphic" src="images/UpgradeGraphics/BCHUpgrades_Icons/1.svg?v=0.04" />
<h3 id="upgrade1-nLockTime" class="fw-bold text-break share-item">Addition of nLockTime Enforcement<span class="ms-2 share-button" data-bs-toggle="tooltip" data-bs-placement="top" title="Share"><i class="bi bi-share"></i></span></h3>
<p class="fs-4 mb-1">2009-10-28</p>
</li>
<li id="hardFork" class="timeline-item mb-5">
<img class="upgrade-icon-small" alt="OP_NOP Functions graphic" src="images/UpgradeGraphics/BCHUpgrades_Icons/2.svg?v=0.04" />
<h3 id="upgrade2-OP_NOP" class="fw-bold text-break share-item">Addition of OP_NOP Functions<span class="ms-2 share-button" data-bs-toggle="tooltip" data-bs-placement="top" title="Share"><i class="bi bi-share"></i></span></h3>
<p class="fs-4 mb-1">2010-07-31</p>
</li>
<li id="hardFork" class="timeline-item mb-5">
<img class="upgrade-icon-small" alt="Separation of Evaluation of scriptSig and scriptPubKey graphic" src="images/UpgradeGraphics/BCHUpgrades_Icons/3.svg?v=0.04" />
<h3 id="upgrade3-scriptSig_scriptPubKey" class="fw-bold text-break share-item">Separation of Evaluation of scriptSig and scriptPubKey<span class="ms-2 share-button" data-bs-toggle="tooltip" data-bs-placement="top" title="Share"><i class="bi bi-share"></i></span></h3>
<p class="fs-4 mb-1">2010-08-01</p>
</li>
<li id="softFork" class="timeline-item mb-5">
<img class="upgrade-icon-small" alt="Value Overflow Incident graphic" src="images/UpgradeGraphics/BCHUpgrades_Icons/4.svg?v=0.04" />
<h3 id="upgrade4-ValOverflowIncident" class="fw-bold text-break share-item">Value Overflow Incident<span class="ms-2 share-button" data-bs-toggle="tooltip" data-bs-placement="top" title="Share"><i class="bi bi-share"></i></span></h3>
<p class="fs-4 mb-1">2010-08-15</p>
</li>
<li id="softFork" class="timeline-item mb-5">
<img class="upgrade-icon-large" alt="1MB Block Size Limit graphic" src="images/UpgradeGraphics/BCHUpgrades_Icons/5.svg?v=0.04" />
<h3 id="upgrade5-1MB_limit" class="fw-bold text-break share-item">1MB Block Size Limit<span class="ms-2 share-button" data-bs-toggle="tooltip" data-bs-placement="top" title="Share"><i class="bi bi-share"></i></span></h3>
<p class="fs-4 mb-1">2010-10-12</p>
<p class="small">
<figure>
<blockquote class="blockquote">
<p>The limit was originally Hal Finney’s idea. Both Satoshi and I objected that it wouldn’t scale at 1MB. Hal was concerned about a potential DoS attack though, and after discussion, Satoshi agreed... But all 3 of us agreed that 1MB had to be temporary because it would never scale.</p>
</blockquote>
<figcaption class="blockquote-footer">
Ray Dillinger
</figcaption>
</figure>
<figure>
<blockquote class="blockquote">
<p>The plan from the begining was to support huge blocks. The 1MB hard limit was always a temporary denial-of-service prevention measure.</p>
</blockquote>
<figcaption class="blockquote-footer">
Gavin Andresen
</figcaption>
</figure>
<figure>
<blockquote class="blockquote">
<p>
It can be phased in, like:<br>
if (blocknumber > 115000)<br>
maxblocksize = largerlimit
</p>
</blockquote>
<figcaption class="blockquote-footer">
Satoshi Nakamoto
</figcaption>
</figure>
</p>
</li>
<li id="softFork" class="timeline-item mb-5">
<img class="upgrade-icon-small" alt="Disallow Transactions with Same TXID graphic" src="images/UpgradeGraphics/BCHUpgrades_Icons/6.svg?v=0.04" />
<h3 id="upgrade6-DisallowSameTxID" class="fw-bold text-break share-item">Disallow Transactions with Same TXID<span class="ms-2 share-button" data-bs-toggle="tooltip" data-bs-placement="top" title="Share"><i class="bi bi-share"></i></span></h3>
<p class="fs-4 mb-1">2012-03-15</p>
</li>
<li id="softFork" class="timeline-item mb-5">
<img class="upgrade-icon-small" alt="Pay-to-Script-Hash graphic" src="images/UpgradeGraphics/BCHUpgrades_Icons/7.svg?v=0.04" />
<h3 id="upgrade7-PaytoScriptHash" class="fw-bold text-break share-item">Pay-to-Script-Hash<span class="ms-2 share-button" data-bs-toggle="tooltip" data-bs-placement="top" title="Share"><i class="bi bi-share"></i></span></h3>
<p class="fs-4 mb-1">2012-04-01</p>
</li>
<li id="softFork" class="timeline-item mb-5">
<img class="upgrade-icon-small" alt="Block Height in Coinbase" src="images/UpgradeGraphics/BCHUpgrades_Icons/8.svg?v=0.04" />
<h3 id="upgrade8-BlockHeightinCoinbase" class="fw-bold text-break share-item">Block Height in Coinbase<span class="ms-2 share-button" data-bs-toggle="tooltip" data-bs-placement="top" title="Share"><i class="bi bi-share"></i></span></h3>
<p class="fs-4 mb-1">2013-03-24</p>
</li>
<li id="hardFork" class="timeline-item mb-5">
<img class="upgrade-icon-small" alt="Migration from Berkeley DB to LevelDB graphic" src="images/UpgradeGraphics/BCHUpgrades_Icons/9.svg?v=0.04" />
<h3 id="upgrade9-DatabaseMigration" class="fw-bold text-break share-item">Migration from Berkeley DB to LevelDB<span class="ms-2 share-button" data-bs-toggle="tooltip" data-bs-placement="top" title="Share"><i class="bi bi-share"></i></span></h3>
<p class="fs-4 mb-1">2013-05-15</p>
</li>
<li id="softFork" class="timeline-item mb-5">
<img class="upgrade-icon-small" alt="Strict DER Encoding for Signatures graphic" src="images/UpgradeGraphics/BCHUpgrades_Icons/10.svg?v=0.04" />
<h3 id="upgrade10-DER_Encoding" class="fw-bold text-break share-item">Strict DER Encoding for Signatures<span class="ms-2 share-button" data-bs-toggle="tooltip" data-bs-placement="top" title="Share"><i class="bi bi-share"></i></span></h3>
<p class="fs-4 mb-1">2015-07-04</p>
</li>
<li id="softFork" class="timeline-item mb-5">
<img class="upgrade-icon-small" alt="OP_CHECKLOCKTIMEVERIFY graphic" src="images/UpgradeGraphics/BCHUpgrades_Icons/11.svg?v=0.04" />
<h3 id="upgrade11-OP_CHECKLOCKTIMEVERIFY" class="fw-bold text-break share-item">OP_CHECKLOCKTIMEVERIFY<span class="ms-2 share-button" data-bs-toggle="tooltip" data-bs-placement="top" title="Share"><i class="bi bi-share"></i></span></h3>
<p class="fs-4 mb-1">2015-12-14</p>
</li>
<li id="softFork" class="timeline-item mb-5">
<img class="upgrade-icon-small" alt="Addition of Opt-In Replace-By-Fee (”RBF”) graphic" src="images/UpgradeGraphics/BCHUpgrades_Icons/12.svg?v=0.04" />
<h3 id="upgrade12-RBF" class="fw-bold text-break share-item">Addition of Opt-In Replace-By-Fee (”RBF”)<span class="ms-2 share-button" data-bs-toggle="tooltip" data-bs-placement="top" title="Share"><i class="bi bi-share"></i></span></h3>
<p class="fs-4 mb-1">2016-02-23</p>
</li>
<li id="softFork" class="timeline-item mb-5">
<img class="upgrade-icon-small" alt="OP_CHECKSEQUENCEVERIFY graphic" src="images/UpgradeGraphics/BCHUpgrades_Icons/13.svg?v=0.04" />
<h3 id="upgrade13-OP_CHECKSEQUENCEVERIFY" class="fw-bold text-break share-item">OP_CHECKSEQUENCEVERIFY<span class="ms-2 share-button" data-bs-toggle="tooltip" data-bs-placement="top" title="Share"><i class="bi bi-share"></i></span></h3>
<p class="fs-4 mb-1">2016-07-04</p>
</li>
</ul>
<ul id="splitHistory" class="timeline">
<li id="hardFork" class="timeline-item mb-5">
<img class="upgrade-icon-large" alt="Bitcoin Cash fork graphic" src="images/UpgradeGraphics/BCHUpgrades_Icons/14.svg?v=0.04" />
<img id="bchSplitLogo" class="bch-split-logo" alt="Bitcoin Cash logo" src="images/UpgradeGraphics/bchLogoFullWhite.svg?v=0.04" />
<p class="fs-4 mb-1 share-item" id="upgrade14-BCH" style="scroll-margin-top:70px;">2017-08-01<span class="ms-2 fs-3 share-button" data-bs-toggle="tooltip" data-bs-placement="top" title="Share"><i class="bi bi-share"></i></span></p>
<p class="fw-bold text-break">User Activated Hard Fork</p>
<p class="fs-5r text-secondary text-break">Block Size Limit to 8MB | Removal of RBF</p>
</li>
<li id="hardFork" class="timeline-item mb-5">
<img class="upgrade-icon-large" alt="Difficulty Adjustment Algorithm Change graphic" src="images/UpgradeGraphics/BCHUpgrades_Icons/15.svg?v=0.04" />
<h3 id="upgrade15-DAA" class="fw-bold text-break share-item">Difficulty Adjustment Algorithm Change<span class="ms-2 share-button" data-bs-toggle="tooltip" data-bs-placement="top" title="Share"><i class="bi bi-share"></i></span></h3>
<p class="fs-4 mb-1">2017-11-13</p>
<p class="fs-4 mb-1 text-break">cw-144 algorithm</p>
<p class="fs-5r text-secondary text-break">With rapid price, and thereby hash, fluctuations, particularly in relation to BTC, an algorithm change was necessary to ensure more reliable blocktimes.</p>
</li>
<li id="hardFork" class="timeline-item mb-5">
<img class="upgrade-icon-large" alt="Monolith graphic" src="images/UpgradeGraphics/BCHUpgrades_Icons/16.svg?v=0.04" />
<h3 id="upgrade16-Monolith" class="fw-bold text-break share-item">Monolith<span class="ms-2 share-button" data-bs-toggle="tooltip" data-bs-placement="top" title="Share"><i class="bi bi-share"></i></span></h3>
<p class="fs-4 mb-1">2018-05-15</p>
<p class="fs-4 mb-1 text-break">Block Size Limit to 32MB | Extra Opcodes (including OP_CAT)</p>
<div class="row">
<div class="col-lg-3">
<p class="fs-5r text-secondary text-break">OP_CAT, OP_SPLIT, OP_AND, OP_OR, OP_XOR, OP_DIV, OP_MOD, OP_NUM2BIN, OP_BIN2NUM</p>
</div>
<div class="col">
<p class="fs-5r text-secondary text-break">In 2010 and 2011 the discovery of serious bugs prompted the deactivation of many opcodes in the Bitcoin script language. Rather than simply re-enable the opcodes, the functionality that they provide has been re-examined and in some cases the opcodes have been re-designed or new opcodes have been added to address specific issues.</p>
</div>
</div>
</li>
<li id="hardFork" class="timeline-item mb-5">
<img class="upgrade-icon-large" alt="Magnetic Anomaly graphic" src="images/UpgradeGraphics/BCHUpgrades_Icons/17.svg?v=0.04" />
<h3 id="upgrade17-MagneticAnomaly" class="fw-bold text-break share-item">Magnetic Anomaly<span class="ms-2 share-button" data-bs-toggle="tooltip" data-bs-placement="top" title="Share"><i class="bi bi-share"></i></span></h3>
<p class="fs-4 mb-1">2018-11-15</p>
<p class="fs-4 mb-1 text-break">OP_CHECKDATASIG & OP_CHECKDATASIGVERIFY | Canonical Transaction Ordering (“CTOR”)</p>
<div class="row">
<div class="col-lg-4">
<p class="fs-5r text-secondary text-break">OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY check whether a signature is valid with respect to a message and a public key.<br><br>
OP_CHECKDATASIG permits data to be imported into a script, and have its validity checked against some signing authority such as an "Oracle."</p>
</div>
<div class="col">
<p class="fs-5r text-secondary text-break">
With the exception of the coinbase transaction, transactions within a block MUST be sorted in numerically ascending order of the transaction id, interpreted as 256-bit little endian integers. The coinbase transaction MUST be the first transaction in a block.<br><br>
Context:<br>
All nodes already have all the transactions in the mempool. When a block is found, it is sending all transactions to all nodes a second time. This delays block propagation and block validation. In order to improve this, Compact/Xthin(er) utilize shorter transaction IDs to minimize the data needing to be sent a second time when a block is found. Graphene takes this a step further by utilizing bloom filters to check which transactions are in which block. However, the bloom filters only allow knowledge of what transactions go into the block, not in what order. The ordering data makes up 80% of the data in a graphene block. By utilizing canonical ordering, 85% of the block data no longer needs to be sent, allowing for 7x faster block propagation and validation.<br><br>
CTOR also enables better parallelization which enables far better scaling with technology. An additional benefit of faster block propagation and validation is the mitigation of selfish mining (where miners that find the first block have an advantage over others for the time it takes their nodes to receive and validate the recently found block).
</p>
</div>
</div>
</li>
<li id="hardFork" class="timeline-item mb-5">
<img class="upgrade-icon-large" alt="Great Wall graphic" src="images/UpgradeGraphics/BCHUpgrades_Icons/18.svg?v=0.04" />
<h3 id="upgrade18-GreatWall" class="fw-bold text-break share-item">Great Wall<span class="ms-2 share-button" data-bs-toggle="tooltip" data-bs-placement="top" title="Share"><i class="bi bi-share"></i></span></h3>
<p class="fs-4 mb-1">2019-05-15</p>
<p class="fs-4 mb-1 text-break">Schnorr Signatures</p>
<p class="fs-5r text-secondary text-break">
Schnorr signatures have some slightly improved properties over the ECDSA signatures currently used in bitcoin:
</p>
<ul class="text-secondary text-break upgrade-bullets">
<li>Known cryptographic proof of security</li>
<li>Proven that there are no unknown third-party malleability mechanisms</li>
<li>Linearity allows some simple multi-party signature aggregation protocols. (compactness / privacy / malleability benefits)</li>
<li>Possibility to do batch validation, resulting a slight speedup during validation of large transactions or initial block downloads</li>
</ul>
</li>
<li id="hardFork" class="timeline-item mb-5">
<img class="upgrade-icon-large" alt="Graviton graphic" src="images/UpgradeGraphics/BCHUpgrades_Icons/19.svg?v=0.04" />
<h3 id="upgrade19-Graviton" class="fw-bold text-break share-item">Graviton<span class="ms-2 share-button" data-bs-toggle="tooltip" data-bs-placement="top" title="Share"><i class="bi bi-share"></i></span></h3>
<p class="fs-4 mb-1">2019-11-15</p>
<p class="fs-4 mb-1 text-break">Schnorr for Multisig | MINIMALDATAINSCRIPT</p>
<div class="row">
<div class="col-lg-4">
<p class="fs-5r text-secondary text-break">OP_CHECKMULTISIG(VERIFY) upgraded to accept Schnorr signatures in a way that increases verification efficiency and is compatible with batch verification.</p>
</div>
<div class="col">
<p class="fs-5r text-secondary text-break">MINIMALDATA flag, which restricts malleability vectors, has been active at the mempool layer of most nodes but not at the consensus layer. The upgrade converts the existing MINIMALDATA rules to consensus.</p>
</div>
</div>
</li>
<li id="hardFork" class="timeline-item mb-5">
<img class="upgrade-icon-large" alt="Phonon graphic" src="images/UpgradeGraphics/BCHUpgrades_Icons/20.svg?v=0.04" />
<h3 id="upgrade20-Phonon" class="fw-bold text-break share-item">Phonon<span class="ms-2 share-button" data-bs-toggle="tooltip" data-bs-placement="top" title="Share"><i class="bi bi-share"></i></span></h3>
<p class="fs-4 mb-1">2020-05-15</p>
<p class="fs-4 mb-1 text-break">OP_REVERSEBYTES | SigChecks</p>
<div class="row">
<div class="col-lg-4">
<p class="fs-5r text-secondary text-break">OP_REVERSEBYTES reverses the bytes of the stackitem.</p>
</div>
<div class="col">
<p class="fs-5r text-secondary text-break">Although partly effective, there are well known issues with SigOps, which mainly stem from the fact that SigOps are judged by parsing scripts, rather than executing them. Bitcoin splits scripts into two transactions (the scriptPubKey of the transaction that creates a coin, and the scriptSig of the transaction that spends it), yet the actual CPU work of verifying a transaction solely happens in the spending transaction, and this leads to some paradoxical situations: a transaction/block that contains high SigOps might involve very little CPU work, and conversely a transaction with low SigOps may require very high CPU work.<br><br>
The essential idea of SigChecks is to count actual executed signature check operations solely in the spending transaction.</p>
</div>
</div>
</li>
<li id="hardFork" class="timeline-item mb-5">
<img class="upgrade-icon-large" alt="Axion graphic" src="images/UpgradeGraphics/BCHUpgrades_Icons/21.svg?v=0.04" />
<h3 id="upgrade21-Axion" class="fw-bold text-break share-item">Axion<span class="ms-2 share-button" data-bs-toggle="tooltip" data-bs-placement="top" title="Share"><i class="bi bi-share"></i></span></h3>
<p class="fs-4 mb-1">2020-11-15</p>
<p class="fs-4 mb-1 text-break">Difficulty Adjustment Algorithm Change: ASERT (aserti3-2d DAA)</p>
<p class="fs-5r text-secondary text-break">
The DAA introduced in November 2017 exhibited susceptibility to a daily periodic difficulty oscillation stemming directly from the simple moving average design of the algorithm. The periodic difficulty oscillations incentivized switch mining and disincentivized steady hashrate mining.<br><br>
The oscillations in difficulty and hashrate have resulted in a daily pattern of long confirmation times followed by bursts of rapid blocks. Average confirmation time of transactions are significantly increased as few transactions are included in the rapidly mined blocks.<br><br>
ASERT does not exhibit the above-mentioned oscillations and has a range of other attractive qualities such as robustness against singularities without a need for additional rules, and absence of accumulation of rounding/approximation error.
</p>
</li>
<li id="hardFork" class="timeline-item mb-5">
<img class="upgrade-icon-large" alt="BigBlockIfTrue graphic" src="images/UpgradeGraphics/BCHUpgrades_Icons/22.svg?v=0.04" />
<h3 id="upgrade22-BigBlockIfTrue" class="fw-bold text-break share-item">BigBlockIfTrue<span class="ms-2 share-button" data-bs-toggle="tooltip" data-bs-placement="top" title="Share"><i class="bi bi-share"></i></span></h3>
<p class="fs-4 mb-1">2021-05-15</p>
<p class="fs-4 mb-1 text-break">Enabling Transactions with Multiple OP_RETURNs | Removal of Unconfirmed Transaction Chain Limit</p>
<div class="row">
<div class="col-lg-4">
<p class="fs-5r text-secondary text-break">Multiple OP_RETURNs enable developers to use OP_RETURN in a manner that justifies its core benefit - experimentation of new features/protocol updates without breaking existing systems or stressing the block chain with extraneous UTXOs. This is still subject to the existing 223 byte limit.</p>
</div>
<div class="col">
<p class="fs-5r text-secondary text-break">When a transaction is first transmitted on the Bitcoin Cash network, it is considered “unconfirmed” until it is “mined” into a block. These transactions that are not yet mined are also referred to as “zero-conf” transactions. Transactions are dependent upon other transactions, such that they are chained together; the value allocated by one transaction is then spent by a subsequent transaction.<br><br>
Until this upgrade, the Bitcoin Cash network only permitted transactions to be chained together 50 times before a block must include them. Transactions exceeding the 50th were often ignored by the network, despite being valid. Once a transaction is submitted to the network, it cannot be revoked. This situation, when encountered, can be extremely difficult to remedy with today’s available tools and simultaneously creates an unnecessary amount of complexity when being accounted for by network and applications developers.<br><br>
The limit is now removed.
</p>
</div>
</div>
</li>
<li id="hardFork" class="timeline-item mb-5">
<img class="upgrade-icon-large" alt="U8 graphic" src="images/UpgradeGraphics/BCHUpgrades_Icons/23.svg?v=0.04" />
<h3 id="upgrade23-U8" class="fw-bold text-break share-item">U8<span class="ms-2 share-button" data-bs-toggle="tooltip" data-bs-placement="top" title="Share"><i class="bi bi-share"></i></span></h3>
<p class="fs-4 mb-1">2022-05-15</p>
<p class="fs-4 mb-1 text-break">Addition of Introspection Op-codes | Bigger Integers & OP_MUL Re-enabling</p>
<div class="row">
<div class="col-lg-6">
<p class="fs-5r text-secondary text-break">Since the introduction of OP_CHECKDATASIG, it has been possible to implement practical Bitcoin Cash covenants – contracts which validate properties of the transaction in which the contract funds are spent.<br><br>
Covenants enable a wide range of new innovation, but the strategy by which they were implemented was extremely inefficient: most of a transaction’s content must be duplicated for each input which utilizes a covenant. In practice, this doubles or triples the size of even the simplest covenant transactions, and advanced covenant applications quickly exceed VM limits. This severely limited the extent of BCH covenant development and usage.<br><br>
This upgrade adds a set of new virtual machine (VM) operations which enable BCH contracts to efficiently access details about the current transaction like output values, recipients, and more – without increasing transaction validation costs.
</p>
</div>
<div class="col">
<p class="fs-5r text-secondary text-break">BCH virtual machine (VM) math operations were limited to signed 32-bit integers, preventing contracts from operating on values larger than 2147483647. Workarounds which allow contracts to emulate higher-precision math are often impractical, difficult to secure, and significantly increase transaction fees.<br><br>
This unusually-low limit on arithmetic operations has been present since the earliest Bitcoin release to avoid standardizing a strategy for overflow handling (though 64-bit math was always used internally). Since the development of covenants, this unusual overflow-handling strategy has become a source of contract vulnerabilities and a barrier to real-world applications. Few remaining computing environments operate using 32-bit integers, and this limit has never been relevant to worst-case transaction validation performance.<br><br>
This upgrade expands the integer range allowed in BCH contracts (from 32-bit to 64-bit numbers) and re-enables the multiplication opcode.
</p>
</div>
</div>
</li>
<li id="hardFork" class="timeline-item mb-5">
<img class="upgrade-icon-large" alt="CashTokens graphic" src="images/UpgradeGraphics/BCHUpgrades_Icons/24.svg?v=0.04" />
<h3 id="upgrade24-CashTokens" class="fw-bold text-break share-item">CashTokens<span class="ms-2 share-button" data-bs-toggle="tooltip" data-bs-placement="top" title="Share"><i class="bi bi-share"></i></span></h3>
<p class="fs-4 mb-1">2023-05-15</p>
<p class="fs-4 mb-1 text-break">P2SH32 | Restrict Transaction Version | Minimum Transaction Size | Native Layer 1, UTXO, Miner-validated Tokens</p>
<div class="row">
<div class="col-lg-3">
<strong class="fs-5r text-secondary lh-sm">P2SH32</strong><br>
<p class="fs-5r text-secondary text-break">Increases cryptographic security of existing P2SH feature by enabling a 32-byte variant of it.
</p>
<strong class="fs-5r text-secondary lh-sm">Restrict Transaction Version:</strong><br>
<p class="fs-5r text-secondary text-break">Tightens enforcement of allowed transaction version field values by making it a consensus rule instead of the network relay rule that is currently in force.<br><br>
Making allowed values part of consensus specification enables its use in tracking future consensus specification upgrades. This would make it easier to roll-out future hard-fork upgrades in a non-breaking and backwards-compatible way for non-node software.
</p>
<strong class="text-secondary lh-sm">Minimum Transaction Size:</strong><br>
<p class="fs-5r text-secondary text-break">Reduces the current consensus minimum transaction size of 100 bytes down to a minimum size of 65 bytes. This more relaxed 65-byte minimum size, like the previous 100-byte minimum size, applies to both coinbase and non-coinbase transactions uniformly.
</p>
</div>
<div class="col">
<strong class="fs-5r text-secondary lh-sm">Native Layer 1, UTXO, Miner-validated Tokens:</strong><br>
<p class="fs-5r text-secondary text-break">Bitcoin Cash contracts lacked primitives for issuing messages that can be verified by other contracts, preventing the development of decentralized application ecosystems on Bitcoin Cash. This upgrade introduced Byte-String Commitments and Numeric Commitments.<br><br>
<strong>(Existing) Contract-Issued Commitments</strong><br>
In the context of the Bitcoin Cash virtual machine (VM), a commitment can be defined as an irrevocable message that was provably issued by a particular entity. Two forms of commitments were already available to Bitcoin Cash contracts:
</p>
<ul class="text-secondary text-break upgrade-bullets">
<li>Transaction signatures: a commitment made by a private key attesting to the signing serialization of a transaction</li>
<li>Data signatures: a commitment made by a private key attesting to the hash of an arbitrary message (introduced in 2018 by OP_CHECKDATASIG)</li>
</ul>
<br>
<p class="fs-5r text-secondary text-break">
Each of these commitment types require the presence of a trusted private key. Because contracts cannot themselves hold a private key, any use case that requires a contract to issue a verifiable message must necessarily rely on trusted entities to provide signatures. This limitation prevented Bitcoin Cash contracts from offering or using decentralized oracles – multiparty consensus systems that produce verifiable messages upon which other contracts can act.<br><br>
By providing a commitment primitive that can be used directly by contracts, the Bitcoin Cash contract system can support advanced, decentralized applications without increasing transaction or block validation costs.<br><br>
<strong>Byte-String Commitments (“Non-Fungible Tokens” or “NFTs”)</strong><br>
The most general type of contract-issued commitment is a simple string of bytes. This type can be used to commit to any type of contract state: certifications of ownership, authorizations, credit, debt, contract-internal time or epoch, vote counts, receipts (e.g. to support refunds or future redemption), etc. Identities may commit to state within a hash structure (e.g. a merkle tree), or – to reduce transaction sizes – as a raw byte string (e.g. public keys, static numbers, boolean values).<br><br>
<strong>Numeric Commitments (“Fungible Tokens” or “FTs”)</strong><br>
The BitcoinCash virtual machine (VM) supports two primary data types in VM bytecode evaluation: byte strings and numbers. Given the existence of a primitive allowing contracts to commit to byte strings, another commitment primitive can be inferred: numeric commitments.<br><br>
Numeric commitments are a specialization of byte-string commitments – they are commitments with numeric values which can be divided and merged in the same way as the Bitcoin Cash currency. With numeric commitments, contracts can efficiently represent fractional parts of abstract concepts – shares, pegged assets, bonds, loans, options, tickets, loyalty points, voting outcomes, etc.<br><br>
While many use cases for numeric commitments can be emulated with only byte-string commitments, a numeric primitive enables many contracts to reduce or offload state management altogether (e.g. shareholder voting), simplifying contract audits and reducing transaction sizes.
</p>
</div>
</div>
</li>
</ul>
<ul id="lockedIn" class="timeline">
<li id="hardFork" class="timeline-item mb-5">
<img class="upgrade-icon-large" alt="ABLA graphic" src="images/UpgradeGraphics/BCHUpgrades_Icons/25.svg?v=0.04" />
<h3 id="upgrade25-ABLA" class="fw-bold text-break share-item">ABLA<span class="ms-2 share-button" data-bs-toggle="tooltip" data-bs-placement="top" title="Share"><i class="bi bi-share"></i></span></h3>
<p class="fs-4 mb-1">2024-05-15</p>
<p class="fs-4 mb-1 text-break">Adaptive Blocksize Limit Algorithm</p>
<p class="fs-5r text-secondary text-break">
Needing to coordinate manual increases to BitcoinCash's blocksize limit incurs a meta cost on all network participants. The need to regularly come to agreement makes the network vulnerable to social attacks, as had occured on Bitcoin Core from its early history.<br><br>
To reduce Bitcoin Cash's social attack surface and save on meta costs for all network participants, ABLA automatically adjusts the blocksize limit after each block, based on the exponentially weighted moving average size of previous blocks.<br><br>
The algorithm preserves the existing 32 MB limit as the floor "stand-by" value, and any increase by the algorithm can be thought of as a bonus on top of that, sustained by actual transaction load.
</p>
</li>
</ul>
<ul id="future" class="timeline">
<li id="hardFork" class="timeline-item mb-5">
<img class="upgrade-icon-large" alt="VM Limits + BigInts graphic" src="images/UpgradeGraphics/BCHUpgrades_Icons/VMLimits+BigInt.svg?v=0.04" />
<h3 id="upgrade26-VMLA" class="fw-bold text-break share-item">VMLA<span class="ms-2 share-button" data-bs-toggle="tooltip" data-bs-placement="top" title="Share"><i class="bi bi-share"></i></span></h3>
<p class="timelineTitle">[Locked-In]</p>
<p class="fs-4 mb-1">2025-05-15</p>
<p class="fs-4 mb-1 text-break">Targeted Virtual Machine Limits + BigInts</p>
<p class="fs-5r text-secondary text-break">
Bitcoin Cash's virtual machine (VM) limits have been re-targeted to enable more advanced contracts, reduce transaction sizes, and reduce full node compute requirements.<br><br>
<strong>More advanced contracts:</strong><br>
The 201 opcode limit and 520-byte, Pay-to-Script-Hash (P2SH) contract length limit each raise the cost of developing Bitcoin Cash products by requiring contract authors to remove important features or otherwise complicate products with harder-to-audit, multi-input systems. Replacing these limits reduces the cost of contract development and security audits.<br><br>
<strong>Larger stack items:</strong><br>
Re-targeted limits enable new post-quantum cryptographic applications, stronger escrow and settlement strategies, larger hash preimages, more practical zero-knowledge proofs, homomorphic encryption, and other important developments for the future security and competitiveness of Bitcoin Cash.<br><br>
<strong>Simpler, easier-to-audit, high-precision math:</strong><br>
Lowers the cost of developing, maintaining, and auditing contract systems relying on high-precision math: automated market makers, decentralized exchanges, decentralized stablecoins, collateralized loan protocols, cross-chain and sidechain bridges, and other decentralized financial applications. By allowing Bitcoin Cash to offer contracts maximum-efficiency, native math operations, this proposal would significantly reduce transaction sizes, block space usage, and node CPU utilization vs. existing emulated-math solutions.
</p>
</li>
<li id="final" class="timeline-item mb-5">
</li>
</ul>
</div>
</section>
<div class="container px-4 py-5">
<h2 class="pb-2 border-bottom border-3 text-center">Future Upgrades in Early Development</h2>
<div class="row g-4 py-5 row-cols-1 row-cols-lg-3">
<div class="col d-flex align-items-start">
<div class="d-inline-flex align-items-center justify-content-center fs-4 flex-shrink-0 me-3">
<i class="bi bi-safe text-info" style="font-size:2em;"></i>
</div>
<div>
<h3 class="fs-2 text-info">Zero-Confirmation Escrows</h3>
<p class="text-light-emphasis fs-5r">Zero-Confirmation Escrows (ZCEs) are contracts which enable instant, incentive-secure payments on Bitcoin Cash. They’re particularly useful in point-of-sale, ATM, and vending applications where payers have no prior or ongoing relationship with the payee.</p>
<a href="https://bitcoincashresearch.org/t/chip-2021-08-zces-zero-confirmation-escrows/537/132" class="btn btn-info">
More Info
</a>
</div>
</div>
<div class="col d-flex align-items-start">
<div class="d-inline-flex align-items-center justify-content-center fs-4 flex-shrink-0 me-3">
<i class="bi bi-braces text-info" style="font-size:2em;"></i>
</div>
<div>
<h3 class="fs-2 text-info">Bounded Looping Operations</h3>
<p class="text-light-emphasis fs-5r">This proposal includes two new BCH virtual machine (VM) operations, OP_BEGIN and OP_UNTIL , which enable a variety of loop constructions in BCH contracts without increasing the processing or memory requirements of the VM.</p>
<a href="https://bitcoincashresearch.org/t/chip-2021-05-bounded-looping-operations/463" class="btn btn-info">
More Info
</a>
</div>
</div>
<div class="col d-flex align-items-start">
<div class="d-inline-flex align-items-center justify-content-center fs-4 flex-shrink-0 me-3">
<i class="bi bi-device-ssd text-info" style="font-size:2em;"></i>
</div>
<div>
<h3 class="fs-2 text-info">UTXO FastSync + UTXO Committments</h3>
<p class="text-light-emphasis fs-5r">This proposal defines a method for nodes to generate, distribute, validate, and consume UTXO snapshots via the BCH P2P network. These snapshots allow for new peers to synchronize to the current state of the network without processing the entire blockchain block-by-block.</p>
<a href="https://bitcoincashresearch.org/t/chip-2021-07-utxo-fastsync/502" class="btn btn-info">
More Info
</a>
</div>
</div>
</div>
</div>
<div class="container px-4 py-3">
<h2 class="pb-2 border-bottom border-3 text-center">Other Upgrades in Discussion</h2>
<div class="row g-4 py-5 row-cols-1 row-cols-lg-3">
<div class="col d-flex align-items-start">
<div class="d-inline-flex align-items-center justify-content-center fs-4 flex-shrink-0 me-3">
<i class="bi bi-123 text-warning" style="font-size:2em;"></i>
</div>
<div>
<h3 class="fs-2 text-warning">SubSatoshis</h3>
<p class="text-light-emphasis fs-5r">This proposal is a change to transactions in order to allow us to move from 8 digits dividing a whole Bitcoin Cash to add several more.</p>
<a href="https://bitcoincashresearch.org/t/pre-release-of-a-new-chip-subsatoshi/1213" class="btn btn-warning">
More Info
</a>
</div>
</div>
<div class="col d-flex align-items-start">
<div class="d-inline-flex align-items-center justify-content-center fs-4 flex-shrink-0 me-3">
<i class="bi bi-cpu text-warning" style="font-size:2em;"></i>
</div>
<div>
<h3 class="fs-2 text-warning">TailStorm</h3>
<p class="text-light-emphasis fs-5r">This proposal could offer fast sub-block confirmations (10 seconds for a sub-block) without negative impact to orphan rates that plain block time reduction would incur.</p>
<a href="https://bitcoincashresearch.org/t/tailstorm-a-secure-and-fair-blockchain-for-cash-transactions/1357/63" class="btn btn-warning">
More Info
</a>
</div>
</div>
<div class="col d-flex align-items-start">
<div class="d-inline-flex align-items-center justify-content-center fs-4 flex-shrink-0 me-3">
<i class="bi bi-database-up text-warning" style="font-size:2em;"></i>
</div>
<div>
<h3 class="fs-2 text-warning">2026 Protocol Update Ideas</h3>
<p class="text-light-emphasis fs-5r">A discussion thread of what should be prioritized next on the Bitcoin Cash network!</p>
<a href="https://bitcoincashresearch.org/t/2026-protocol-upgrade-ideas/1402/27" class="btn btn-warning">
More Info
</a>
</div>
</div>
</div>
</div>
<div class="container px-4 py-3">
<h2 class="pb-2 border-bottom border-3 text-center mb-3">Bitcoin Cash Research Forum</h2>
<div class="d-grid gap-2 col-5 mx-auto">
<a href="https://bitcoincashresearch.org" class="btn btn-secondary btn-outline-secondary" type="button">
<img src="images/bchResearch.png" alt="Bitcoin Cash Research Logo" class="img-fluid p-1" style="max-height:4em;" />
</a>
</div>
</div>
<p class="text-secondary fs-5r ps-3">
Graphics by <strong><a href="https://x.com/CM_Workzs" class="text-decoration-none text-secondary">CM_Works</a></strong>
</p>
<footer class="py-3">
<div class="row pb-3">
<h3 class="fs-3">Buy me a coffee!</h3>
<div class="custom-tooltip">
<h5 class="user-select-all fs-5r" style="display:inline; word-wrap: break-word;">bitcoincash:qrvns4u27ngn6vf774rlep6873kzadqnavw0szkqx3</h5>
<button id="copyButton" class="remove-button-stylings" data-bs-toggle="tooltip" data-bs-placement="top" data-bs-title="Copy to Clipboard">
<i class="bi bi-copy copyButton"></i>
</button>
</div>
</div>
<div class="row pb-3">
<h5 class="fs-5r fw-normal"><a class="link-offset-1" href="https://discover.cash">Learn about Bitcoin Cash</a> | <a class="link-offset-1" href="http://reddit.com/r/btc">Uncensored Bitcoin Forum</a> | <a class="link-offset-1" href="https://t.me/bchchannel">Telegram Chatroom</a> | <a class="link-offset-1" href="https://cashaddress.org">Paper Wallet</a> | <a class="link-offset-1" href="https://blockchair.com">Blockchair Block Explorer</a></h5>
</div>
<div class="row">
<h5 class="fs-5r fw-normal">Connect to my SPV Node! node.minisatoshi.cash</h5>
</div>
</footer>
<!-- Jquery needed -->
<script src="https://ajax.googleapis.com/ajax/libs/jquery/3.1.1/jquery.min.js"></script>
<!-- Include all compiled plugins (below), or include individual files as needed -->
<script src="https://cdn.jsdelivr.net/npm/[email protected]/dist/js/bootstrap.bundle.min.js" integrity="sha384-YvpcrYf0tY3lHB60NNkmXc5s9fDVZLESaAA55NDzOxhy9GkcIdslK1eN7N6jIeHz" crossorigin="anonymous"></script>
<!--Copy to Clipboard Script for donation address-->
<script>
document.addEventListener('DOMContentLoaded', function() {
const button = document.getElementById('copyButton');
const tooltip = new bootstrap.Tooltip(button);
const copyToClipboard = async () => {
try {
const element = document.querySelector(".user-select-all");
await navigator.clipboard.writeText(element.textContent);
// Optional: Provide feedback or perform additional actions upon successful copy
// Update tooltip text
tooltip.setContent({ '.tooltip-inner': 'Copied!' });
// Show tooltip
tooltip.show();
// Hide tooltip after a short delay
setTimeout(() => {
tooltip.hide();
// Reset tooltip text for next use
tooltip.setContent({ '.tooltip-inner': 'Copy to Clipboard' });
}, 1500); // Adjust delay as needed
} catch (error) {
console.error("Failed to copy to clipboard:", error);
// Optional: Handle and display the error to the user
tooltip.setContent({ '.tooltip-inner': 'Copy Failed!' });
tooltip.show();
setTimeout(() => {
tooltip.hide();
tooltip.setContent({ '.tooltip-inner': 'Copy to Clipboard' });
}, 2000); // Adjust delay for error message
}
};
// Attach the function to the button's onclick event again or maintain your existing setup
button.addEventListener('click', copyToClipboard);
});
</script>
<!-- Initializing tooltips -->
<script>
var tooltipTriggerList = [].slice.call(document.querySelectorAll('[data-bs-toggle="tooltip"]'))
var tooltipList = tooltipTriggerList.map(function(tooltipTriggerEl) {
return new bootstrap.Tooltip(tooltipTriggerEl)
})
</script>
<!--Copy to Clipboard Script for timeline share buttons-->
<script>
document.addEventListener('DOMContentLoaded', function() {
// Select all share buttons instead of one specific button
const shareButtons = document.querySelectorAll('.share-button');
shareButtons.forEach(button => {
// Initialize tooltip for each share button
const tooltip = new bootstrap.Tooltip(button);
button.addEventListener('click', async function(e) {
try {
const item = this.closest('.share-item');
if (item && item.id) {
const url = window.location.href.split('#')[0] + '#' + item.id;
await navigator.clipboard.writeText(url);
// Update tooltip to show success
tooltip.setContent({ '.tooltip-inner': 'Copied!' });
tooltip.show();
// Hide tooltip after a short delay
setTimeout(() => {
tooltip.hide();
// Reset tooltip text for next use
tooltip.setContent({ '.tooltip-inner': 'Share' });
}, 1500); // Adjust delay as needed
}
} catch (error) {
console.error("Failed to copy to clipboard:", error);
// Show error message in tooltip
tooltip.setContent({ '.tooltip-inner': 'Copy Failed!' });
tooltip.show();
setTimeout(() => {
tooltip.hide();
tooltip.setContent({ '.tooltip-inner': 'Share' });
}, 2000); // Adjust delay for error message
}
});
});
});
</script>
<script>
document.addEventListener('DOMContentLoaded', function() {
function setTheme(theme) {
document.documentElement.setAttribute('data-bs-theme', theme);
localStorage.setItem('bs-theme', theme);
updateThemeIcon(theme);
updateActiveDropdownItem(theme);
updateButtonStyles(); // Call this function to update button styles on theme change
}
function getCurrentTheme() {
return localStorage.getItem('bs-theme') || 'dark';
}
function updateThemeIcon(theme) {
const icon = document.getElementById('themeIcon');
icon.className = `bi ${theme === 'light' ? 'bi-brightness-high-fill' : 'bi-moon-stars-fill'}`;
}
function updateActiveDropdownItem(theme) {
document.querySelectorAll('.theme-switcher .dropdown-item').forEach(item => {
item.classList.toggle('active', item.getAttribute('data-theme') === theme);
});
}
function updateButtonStyles() {
document.querySelectorAll('.btn-outline-secondary, .btn-secondary').forEach(button => {
const currentTheme = document.documentElement.getAttribute('data-bs-theme');
if (currentTheme === 'light') {
button.classList.remove('btn-outline-secondary');
button.classList.add('btn-secondary');
} else {
button.classList.remove('btn-secondary');
button.classList.add('btn-outline-secondary');
}
});
}
setTheme(getCurrentTheme());
updateButtonStyles(); // Initial call to ensure buttons are styled correctly on load
document.querySelectorAll('.theme-switcher .dropdown-item').forEach(item => {
item.addEventListener('click', function(e) {
e.preventDefault();
const theme = this.getAttribute('data-theme');
setTheme(theme);
});
});
});
</script>
<script>
document.addEventListener('DOMContentLoaded', function() {
// Function to swap images
function swapImage() {
const img = document.getElementById('bchSplitLogo');
const theme = document.documentElement.getAttribute('data-bs-theme');
if (theme === 'dark') {
img.src = 'images/UpgradeGraphics/bchLogoFullWhite.svg?v=0.04';
} else {
img.src = 'images/UpgradeGraphics/bchLogoFullDark.svg?v=0.04';
}
}
// Initial check
swapImage();
// Listen for theme changes
const observer = new MutationObserver(swapImage);
observer.observe(document.documentElement, {
attributes: true,
attributeFilter: ['data-bs-theme']
});
});
</script>
</body>
</html>