summaryrefslogtreecommitdiff
path: root/a2/bff7b1464a0a47eb6069627bb72ae54c706723
blob: 1c13266887de4420dc634e3314c4a3497fc35348 (plain)
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
Delivery-date: Sun, 23 Mar 2025 18:29:17 -0700
Received: from mail-oo1-f59.google.com ([209.85.161.59])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBAABBYXKQK7QMGQEBESXDSA@googlegroups.com>)
	id 1twWct-00032G-44
	for bitcoindev@gnusha.org; Sun, 23 Mar 2025 18:29:17 -0700
Received: by mail-oo1-f59.google.com with SMTP id 006d021491bc7-6021ab9731dsf3312207eaf.1
        for <bitcoindev@gnusha.org>; Sun, 23 Mar 2025 18:29:15 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1742779749; cv=pass;
        d=google.com; s=arc-20240605;
        b=SkD0859RSn6r94bSRl2fjk0SOf14HnYH6kZeSZG8DCSaefNsTtK3yqtp76vMGQu6yh
         /6+BW9ur5zvC+ASUxu994cH09UaNGz62PE+2MTiukqqDwzYmMprVY4PR2O9p1gNmfjVv
         pKcCRpoKUHzQiGDr14CLTxdtYS268eHcN2zkopkVlSSm8xRX8tKYSQBMgbi3RAj+wwHA
         ioRR9XQcWmpQx2h/ySawx4XxJQf0yvPQ1MU1IDZXxFf1YbVcbuJe/5T9j//B4q0aypX/
         MbzFkee3njGyOdGTphEmOoy2huVpzNlOrj+PLKetzEf9GKnq87oms8F32H0HvTomCmvc
         bQXA==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:to:date:message-id:subject
         :mime-version:from:content-transfer-encoding:sender:dkim-signature;
        bh=JKdFhfxW4Ol1hVPDaNKFcXRsmyS2w+O+1IIQvSfOrIY=;
        fh=TkfRp1HWc/HKa9kuoYN9bOm11n9WbDROgRB7h4ZTfww=;
        b=UZ/Y2sookRG7kPjcVEPfROyOvYRtPouW26RK3V7y5kW8mhWeIOqtMtJfcqrIMwMXfM
         oqXA1utE+A9pJYzCzPWl4KB6t6g92+lBymKj1SjhEhV+U58B91jk4vl2pKLN58oN2GG+
         jxZqSYGsr2FKbVsdps9OSRszZlG1u5YQLOm+ljYHlw6x2g+DSJcAJcb9jqt7EZrwSYtt
         ZvDCAMVksE4IyZ4QarcvHs7mKkPCMkwsNTCxC7NBQh4wX+iDlNuizjDPJZ2jxPN6Alr/
         ueYmLHN8dv3O5EBbJMKKpokZprrOlZmBb9hTzIRgO5l+s1UZlle0RfPb5dbo7Y17qHxR
         ISSQ==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       spf=pass (google.com: domain of saulo@astrotown.de designates 54.38.158.53 as permitted sender) smtp.mailfrom=saulo@astrotown.de;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=astrotown.de
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1742779749; x=1743384549; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:to:date:message-id:subject:mime-version:from
         :content-transfer-encoding:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=JKdFhfxW4Ol1hVPDaNKFcXRsmyS2w+O+1IIQvSfOrIY=;
        b=bJ5YCzDBkgpdhF3SWWplWDM8DUs1J82AHneoOMZ8HdW7MchAIiXN2DCMC8ft7UcKmu
         P0RFstqZU7YOmS3/zl29DEFH1Rs3KqTQFDuBTWnckvEJmCSQ/TV0UEIArBGtwydPfjGd
         p/9iDF7duKgmXq6Hr5fHG7ZRuaaZ+9t+izRryVmFQRHA/w3sPV6lJ3xJwmwmhAeo68wW
         11DZThMWESnQ297moQxIkYMQQzRV1sEhN7LV+rlyo2VravJ7eF9sTWw7DzLeFWNSs0Vz
         t+dqhbcYWxGx3jGij/UHWv8lQYnk/2ERo2UrD74i8uhDPdkHLDEbPxlpvO9JgKGIR80J
         BsXg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1742779749; x=1743384549;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:to:date:message-id:subject:mime-version:from
         :content-transfer-encoding:x-beenthere:x-gm-message-state:sender
         :from:to:cc:subject:date:message-id:reply-to;
        bh=JKdFhfxW4Ol1hVPDaNKFcXRsmyS2w+O+1IIQvSfOrIY=;
        b=pSs9X2mlC1iWfgdM4ORwwrsDampTsjElPRcOXjcOI6MWvZ+T0NDbbuNbu1o10STXdF
         qWGfOAWlqXbIiVLxMdwnIXb8MMvb5RzCfIwF2scPh+SnHv3Z42xg851tHQBDPdHBJXz9
         i8GimYfBii79LKCoNrSd7BdcYJudHcwKUhnptwm7V+ZIk6MiF/vLXWx7Ix2qHbs+V0nQ
         9/R+RBuZq/E4FjmzXKogNSFui0KydZVMVYk0SK9zOlxd674etgRRqdNGv03H+WtABqzX
         dnqETwlH7+r3wJGrT2pNaN0lwfpzxhZ2JCv9cJZtt3s1EWj33muIZ9Y8piW4UZMXtW/A
         4/Og==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCW+mcY/uOpWNu4SbeCaYYKZ8hL1Osj8TyqU+OH2bwvtaeAOH03FIXE2T8+pQ9zyhvWL8mENWzOVhz5u@gnusha.org
X-Gm-Message-State: AOJu0YxTu1aCJM6dyHgNoiYaEYnStAvGMJVtTQKe0bHe02BnFNevhFMc
	wjEuESWoZFCuCnHHfRhEmXe4Og7e5dep4EwOzKdhlVmCHlswqbA5
X-Google-Smtp-Source: AGHT+IH653aNxm5TaYgL2qwnYhpnbz16zA3vptDxkZ/OeVvKI2INRnuuvgCwoy31iq8JstdLEttYlQ==
X-Received: by 2002:a05:6820:430a:b0:601:d8be:efcc with SMTP id 006d021491bc7-60228d05da3mr11145547eaf.4.1742779748873;
        Sun, 23 Mar 2025 18:29:08 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=ARLLPALpj4eE10r2GGBSdhCSzDJUcDKeG2mTY/akeb5bOSz2hQ==
Received: by 2002:a4a:e6d6:0:b0:601:15b8:befd with SMTP id 006d021491bc7-60228f2812fls1347023eaf.1.-pod-prod-00-us;
 Sun, 23 Mar 2025 18:29:06 -0700 (PDT)
X-Received: by 2002:a54:4013:0:b0:3f6:ab0d:8d90 with SMTP id 5614622812f47-3febeda6b19mr6065303b6e.3.1742779746248;
        Sun, 23 Mar 2025 18:29:06 -0700 (PDT)
Received: by 2002:a50:cd07:0:b0:5e6:1486:31dd with SMTP id 4fb4d7f45d1cf-5ebccfc5e1bmsa12;
        Sat, 22 Mar 2025 12:02:28 -0700 (PDT)
X-Received: by 2002:a17:907:e841:b0:ac2:32a:ee17 with SMTP id a640c23a62f3a-ac3f2100662mr816155166b.3.1742670145844;
        Sat, 22 Mar 2025 12:02:25 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1742670145; cv=none;
        d=google.com; s=arc-20240605;
        b=QHQ1SJBZXe2xeOnU36/iRRA7zC9RXn5ofllINoml06BCnYCJ4gahPzqqCWGqY41dof
         ino/QH1C559zOu2VzYO5xmqPKeaVBpvFNcCyT36A7SpV3y42FUy78Nb7EWH3j1vz7VDt
         SRHR3cOw4nCGkRJS4C7yYjPMkd4Y+i0QmdL0brBatHJmsIsTjO37h6f9ybuLLMXSgqdz
         ijrdyUA55pPxaGcH415SZWFu6dyGberDia3GdAh9A9nPWPOxH9UsJdVETCznGGdliLug
         tdWIuZ47XMkrbma2qpBfteWEaNb4EEd/mMoEUi8D+J6ZAe7G3CvkQZiM5J5fNU3fGPwC
         VQdQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=to:date:message-id:subject:mime-version:from
         :content-transfer-encoding;
        bh=U30aT8I4hhk21e7Mbt8802EMuCLOkirhcRHw6ElSwME=;
        fh=VcGcg+Zjs9gw1uDcHbxsAILhBAcecnbJzZRdxgKVDIc=;
        b=Rn6HkpyuXA3nMbJJ/tu3CIxGVqIN7zwr+fxkXyqKTpIAHEXsgma79jtBSivRS0NBo7
         1s0Dr2ppYj/M2rZQwi5oAksoWUteCvNEnWWS7se7vWMiNHoJK9a742OnV5OmWC4JZN74
         +gPL5ezCnHdMAl4ne+/OaixFaFGXL6IhyEYqxKl6G1LQHEEJd2LnaAA+Fqabn2U5fQPs
         /0sK2hUqaLDeVo8NrFJVL2/5Kg0KWPUhOpdEhTX32PHyKx5WgkE7M6sLgSYXCW+XuNsn
         4ZOqTnWvEnwyyO58EJ3788hh0dYj7FCreqvr+5tNxwp+amk7HnICIJiwEsZVLFPTCEwO
         ZKSQ==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       spf=pass (google.com: domain of saulo@astrotown.de designates 54.38.158.53 as permitted sender) smtp.mailfrom=saulo@astrotown.de;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=astrotown.de
Received: from astrotown.de (astrotown.de. [54.38.158.53])
        by gmr-mx.google.com with ESMTP id 4fb4d7f45d1cf-5ebcd098fe5si132618a12.4.2025.03.22.12.02.25
        for <bitcoindev@googlegroups.com>;
        Sat, 22 Mar 2025 12:02:25 -0700 (PDT)
Received-SPF: pass (google.com: domain of saulo@astrotown.de designates 54.38.158.53 as permitted sender) client-ip=54.38.158.53;
Received: from smtpclient.apple (unknown [209.198.144.183])
	by astrotown.de (Postfix) with ESMTPSA id 39B464CA8
	for <bitcoindev@googlegroups.com>; Sat, 22 Mar 2025 20:02:25 +0100 (CET)
Content-Type: multipart/alternative; boundary=Apple-Mail-0ACFD50B-3670-406F-BC40-FBA4063F0795
Content-Transfer-Encoding: 7bit
From: AstroTown <saulo@astrotown.de>
Mime-Version: 1.0 (1.0)
Subject: Re: [bitcoindev] Against Allowing Quantum Recovery of Bitcoin
Message-Id: <E8269A1A-1899-46D2-A7CD-4D9D2B732364@astrotown.de>
Date: Sat, 22 Mar 2025 20:02:13 +0100
To: bitcoindev@googlegroups.com
X-Mailer: iPhone Mail (22D82)
X-Original-Sender: saulo@astrotown.de
X-Original-Authentication-Results: gmr-mx.google.com;       spf=pass
 (google.com: domain of saulo@astrotown.de designates 54.38.158.53 as
 permitted sender) smtp.mailfrom=saulo@astrotown.de;       dmarc=pass (p=NONE
 sp=NONE dis=NONE) header.from=astrotown.de
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: 2.1 (++)


--Apple-Mail-0ACFD50B-3670-406F-BC40-FBA4063F0795
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=
=3Dutf-8"></head><body dir=3D"auto"><div dir=3D"ltr"><span style=3D"caret-c=
olor: rgb(0, 0, 0); color: rgb(0, 0, 0); -webkit-text-size-adjust: auto;">I=
 believe that having some entity announce the decision to freeze old UTXOs =
would be more damaging to Bitcoin=E2=80=99s image (and its value) than havi=
ng them gathered by QC. This would create another version of Bitcoin, simil=
ar to Ethereum Classic, causing confusion in the market.</span><div dir=3D"=
ltr"><div style=3D"-webkit-text-size-adjust: auto; caret-color: rgb(0, 0, 0=
); color: rgb(0, 0, 0);"><br></div><div style=3D"-webkit-text-size-adjust: =
auto; caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">It would be better t=
o simply implement the possibility of moving funds to a PQC address without=
 a deadline, allowing those who fail to do so to rely on luck to avoid havi=
ng their coins stolen. Most coins would be migrated to PQC anyway, and in m=
ost cases, only the lost ones would remain vulnerable. This is the free-mar=
ket way to solve problems without imposing rules on everyone.</div><div sty=
le=3D"-webkit-text-size-adjust: auto; caret-color: rgb(0, 0, 0); color: rgb=
(0, 0, 0);"><br></div><div style=3D"-webkit-text-size-adjust: auto; caret-c=
olor: rgb(0, 0, 0); color: rgb(0, 0, 0);">Saulo Fonseca</div><div style=3D"=
-webkit-text-size-adjust: auto; caret-color: rgb(0, 0, 0); color: rgb(0, 0,=
 0);"><br></div><div style=3D"-webkit-text-size-adjust: auto; caret-color: =
rgb(0, 0, 0); color: rgb(0, 0, 0);"><br><blockquote type=3D"cite"><div>On 1=
6. Mar 2025, at 15:15, Jameson Lopp &lt;<span dir=3D"ltr">jameson.lopp@gmai=
l.com</span>&gt; wrote:</div><br class=3D"Apple-interchange-newline"><div><=
div dir=3D"ltr">The quantum computing debate is heating up. There are many =
controversial aspects to this debate, including whether or not quantum comp=
uters will ever actually become a practical threat.<div><br>I won't tread i=
nto the unanswerable question of how worried we should be about quantum com=
puters. I think it's far from a crisis, but given the difficulty in changin=
g Bitcoin it's worth starting to seriously discuss. Today I wish to focus o=
n a philosophical quandary related to one of the decisions that would need =
to be made if and when we implement a quantum safe signature scheme.<br><br=
><font size=3D"6">Several Scenarios<br></font>Because this essay will refer=
ence game theory a fair amount, and there are many variables at play that c=
ould change the nature of the game, I think it's important to clarify the p=
ossible scenarios up front.<br><br>1. Quantum computing never materializes,=
 never becomes a threat, and thus everything discussed in this essay is moo=
t.<br>2. A quantum computing threat materializes suddenly and Bitcoin does =
not have quantum safe signatures as part of the protocol. In this scenario =
it would likely make the points below moot because Bitcoin would be fundame=
ntally broken and it would take far too long to upgrade the protocol, walle=
t software, and migrate user funds in order to restore confidence in the ne=
twork.<br>3. Quantum computing advances slowly enough that we come to conse=
nsus about how to upgrade Bitcoin and post quantum security has been minima=
lly adopted by the time an attacker appears.<br>4. Quantum computing advanc=
es slowly enough that we come to consensus about how to upgrade Bitcoin and=
 post quantum security has been highly adopted by the time an attacker appe=
ars.<br><br>For the purposes of this post, I'm envisioning being in situati=
on 3 or 4.<br><br><font size=3D"6">To Freeze or not to Freeze?<br></font>I'=
ve started seeing more people weighing in on what is likely the most conten=
tious aspect of how a quantum resistance upgrade should be handled in terms=
 of migrating user funds. Should quantum vulnerable funds be left open to b=
e swept by anyone with a sufficiently powerful quantum computer OR should t=
hey be permanently locked?<br><br><blockquote class=3D"gmail_quote" style=
=3D"margin: 0px 0px 0px 0.8ex; border-left-color: rgb(204, 204, 204); paddi=
ng-left: 1ex;">"I don't see why old coins should be confiscated. The better=
 option is to let those with quantum computers free up old coins. While thi=
s might have an inflationary impact on bitcoin's price, to use a turn of ph=
rase, the inflation is transitory. Those with low time preference should su=
pport returning lost coins to circulation."&nbsp;</blockquote><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-color:=
 rgb(204, 204, 204); padding-left: 1ex;">- Hunter Beast</blockquote><div><b=
r></div>On the other hand:</div><div><br><blockquote class=3D"gmail_quote" =
style=3D"margin: 0px 0px 0px 0.8ex; border-left-color: rgb(204, 204, 204); =
padding-left: 1ex;">"Of course they have to be confiscated. If and when (an=
d that's a big if) the existence of a cryptography-breaking QC becomes a cr=
edible threat, the Bitcoin ecosystem has no other option than softforking o=
ut the ability to spend from signature schemes (including ECDSA and BIP340)=
 that are vulnerable to QCs. The alternative is that millions of BTC become=
 vulnerable to theft; I cannot see how the currency can maintain any value =
at all in such a setting. And this affects everyone; even those which dilig=
ently moved their coins to PQC-protected schemes."<br>- Pieter Wuille</bloc=
kquote><br>I don't think "confiscation" is the most precise term to use, as=
 the funds are not being seized and reassigned. Rather, what we're really d=
iscussing would be better described as "burning" - placing the funds&nbsp;<=
b>out of reach of everyone</b>.<br><br>Not freezing user funds is one of Bi=
tcoin's inviolable properties. However, if quantum computing becomes a thre=
at to Bitcoin's elliptic curve cryptography,&nbsp;<b>an inviolable property=
 of Bitcoin will be violated one way or another</b>.<br><br><font size=3D"6=
">Fundamental Properties at Risk<br></font>5 years ago I attempted to compr=
ehensively categorize all of Bitcoin's fundamental properties that give it =
value.&nbsp;<a href=3D"https://nakamoto.com/what-are-the-key-properties-of-=
bitcoin/">https://nakamoto.com/what-are-the-key-properties-of-bitcoin/<br><=
/a><br>The particular properties in play with regard to this issue seem to =
be:<br><br><b>Censorship Resistance</b>&nbsp;- No one should have the power=
 to prevent others from using their bitcoin or interacting with the network=
.<br><br><b>Forward Compatibility</b>&nbsp;- changing the rules such that c=
ertain valid transactions become invalid could undermine confidence in the =
protocol.<br><br><b>Conservatism</b>&nbsp;- Users should not be expected to=
 be highly responsive to system issues.<br><br>As a result of the above pri=
nciples, we have developed a strong meme (kudos to Andreas Antonopoulos) th=
at goes as follows:<br><br><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0px 0px 0px 0.8ex; border-left-color: rgb(204, 204, 204); padding-left: =
1ex;">Not your keys, not your coins.</blockquote><br>I posit that the corol=
lary to this principle is:<br><br><blockquote class=3D"gmail_quote" style=
=3D"margin: 0px 0px 0px 0.8ex; border-left-color: rgb(204, 204, 204); paddi=
ng-left: 1ex;">Your keys, only your coins.</blockquote><br>A quantum capabl=
e entity breaks the corollary of this foundational principle. We secure our=
 bitcoin with the mathematical probabilities related to extremely large ran=
dom numbers. Your funds are only secure because truly random large numbers =
should not be guessable or discoverable by anyone else in the world.<br><br=
>This is the principle behind the motto&nbsp;<i>vires in numeris</i>&nbsp;-=
 strength in numbers. In a world with quantum enabled adversaries, this pri=
nciple is null and void for many types of cryptography, including the ellip=
tic curve digital signatures used in Bitcoin.<br><br><font size=3D"6">Who i=
s at Risk?<br></font>There has long been a narrative that Satoshi's coins a=
nd others from the Satoshi era of P2PK locking scripts that exposed the pub=
lic key directly on the blockchain will be those that get scooped up by a q=
uantum "miner." But unfortunately it's not that simple. If I had a powerful=
 quantum computer, which coins would I target? I'd go to the Bitcoin rich l=
ist and find the wallets that have exposed their public keys due to re-usin=
g addresses that have previously been spent from. You can easily find them =
at&nbsp;<a href=3D"https://bitinfocharts.com/top-100-richest-bitcoin-addres=
ses.html">https://bitinfocharts.com/top-100-richest-bitcoin-addresses.html<=
/a><br><br>Note that a few of these wallets, like Bitfinex / Kraken / Tethe=
r, would be slightly harder to crack because they are multisig wallets. So =
a quantum attacker would need to reverse engineer 2 keys for Kraken or 3 fo=
r Bitfinex / Tether in order to spend funds. But many are single signature.=
<br><br>Point being, it's not only the really old lost BTC that are at risk=
 to a quantum enabled adversary, at least at time of writing. If we add a q=
uantum safe signature scheme, we should expect those wallets to be some of =
the first to upgrade given their incentives.<br><br><font size=3D"6">The Et=
hical Dilemma: Quantifying Harm<br></font>Which decision results in the mos=
t harm?<br><br>By making quantum vulnerable funds unspendable we potentiall=
y harm some Bitcoin users who were not paying attention and neglected to mi=
grate their funds to a quantum safe locking script. This violates the "cons=
ervativism" principle stated earlier. On the flip side, we prevent those fu=
nds plus far more lost funds from falling into the hands of the few privile=
ged folks who gain early access to quantum computers.<br><br>By leaving qua=
ntum vulnerable funds available to spend, the same set of users who would o=
therwise have funds frozen are likely to see them stolen. And many early ad=
opters who lost their keys will eventually see their unreachable funds scoo=
ped up by a quantum enabled adversary.<br><br>Imagine, for example, being J=
ames Howells, who accidentally threw away a hard drive with 8,000 BTC on it=
, currently worth over $600M USD. He has spent a decade trying to retrieve =
it from the landfill where he knows it's buried, but can't get permission t=
o excavate. I suspect that, given the choice, he'd prefer those funds be pe=
rmanently frozen rather than fall into someone else's possession - I know I=
 would.<br><br>Allowing a quantum computer to access lost funds doesn't mak=
e those users any worse off than they were before, however it&nbsp;<i>would=
</i>have a negative impact upon everyone who is currently holding bitcoin.<=
br><br>It's prudent to expect significant economic disruption if large amou=
nts of coins fall into new hands. Since a quantum computer is going to have=
 a massive up front cost, expect those behind it to desire to recoup their =
investment. We also know from experience that when someone suddenly finds t=
hemselves in possession of 9+ figures worth of highly liquid assets, they t=
end to diversify into other things by selling.<br><br>Allowing quantum reco=
very of bitcoin is&nbsp;<i>tantamount to wealth redistribution</i>. What we=
'd be allowing is for bitcoin to be redistributed from those who are ignora=
nt of quantum computers to those who have won the technological race to acq=
uire quantum computers. It's hard to see a bright side to that scenario.<br=
><br><font size=3D"6">Is Quantum Recovery Good for Anyone?</font><br><br>Do=
es quantum recovery HELP anyone? I've yet to come across an argument that i=
t's a net positive in any way. It certainly doesn't add any security to the=
 network. If anything, it greatly decreases the security of the network by =
allowing funds to be claimed by those who did not earn them.<br><br>But wai=
t, you may be thinking, wouldn't quantum "miners" have earned their coins b=
y all the work and resources invested in building a quantum computer? I sup=
pose, in the same sense that a burglar earns their spoils by the resources =
they invest into surveilling targets and learning the skills needed to brea=
k into buildings. What I say "earned" I mean through productive mutual trad=
e.<br><br>For example:<br><br>* Investors earn BTC by trading for other cur=
rencies.<br>* Merchants earn BTC by trading for goods and services.<br>* Mi=
ners earn BTC by trading thermodynamic security.<br>* Quantum miners don't =
trade anything, they are vampires feeding upon the system.<br><br>There's n=
o reason to believe that allowing quantum adversaries to recover vulnerable=
 bitcoin will be of benefit to anyone other than the select few organizatio=
ns that win the technological arms race to build the first such computers. =
Probably nation states and/or the top few largest tech companies.<br><br>On=
e could certainly hope that an organization with quantum supremacy is benev=
olent and acts in a "white hat" manner to return lost coins to their owners=
, but that's incredibly optimistic and foolish to rely upon. Such a situati=
on creates an insurmountable ethical dilemma of only recovering lost bitcoi=
n rather than currently owned bitcoin. There's no way to precisely differen=
tiate between the two; anyone can claim to have lost their bitcoin but if t=
hey have lost their keys then proving they ever had the keys becomes rather=
 difficult. I imagine that any such white hat recovery efforts would have t=
o rely upon attestations from trusted third parties like exchanges.<br><br>=
Even if the first actor with quantum supremacy is benevolent, we must assum=
e the technology could fall into adversarial hands and thus think adversari=
ally about the potential worst case outcomes. Imagine, for example, that No=
rth Korea continues scooping up billions of dollars from hacking crypto exc=
hanges and decides to invest some of those proceeds into building a quantum=
 computer for the biggest payday ever...<br><br><font size=3D"6">Downsides =
to Allowing Quantum Recovery</font><br>Let's think through an exhaustive li=
st of pros and cons for allowing or preventing the seizure of funds by a qu=
antum adversary.<br><br><font size=3D"4">Historical Precedent</font><br>Pre=
vious protocol vulnerabilities weren=E2=80=99t celebrated as "fair game" bu=
t rather were treated as failures to be remediated. Treating quantum theft =
differently risks rewriting Bitcoin=E2=80=99s history as a free-for-all rat=
her than a system that seeks to protect its users.<br><br><font size=3D"4">=
Violation of Property Rights</font><br>Allowing a quantum adversary to take=
 control of funds undermines the fundamental principle of cryptocurrency - =
if you keep your keys in your possession, only you should be able to access=
 your money. Bitcoin is built on the idea that private keys secure an indiv=
idual=E2=80=99s assets, and unauthorized access (even via advanced tech) is=
 theft, not a legitimate transfer.<br><br><font size=3D"4">Erosion of Trust=
 in Bitcoin</font><br>If quantum attackers can exploit vulnerable addresses=
, confidence in Bitcoin as a secure store of value would collapse. Users an=
d investors rely on cryptographic integrity, and widespread theft could dri=
ve adoption away from Bitcoin, destabilizing its ecosystem.<br><br>This is =
essentially the counterpoint to claiming the burning of vulnerable funds is=
 a violation of property rights. While some will certainly see it as such, =
others will find the apathy toward stopping quantum theft to be similarly c=
oncerning.<br><br><font size=3D"4">Unfair Advantage</font><br>Quantum attac=
kers, likely equipped with rare and expensive technology, would have an unj=
ust edge over regular users who lack access to such tools. This creates an =
inequitable system where only the technologically elite can exploit others,=
 contradicting Bitcoin=E2=80=99s ethos of decentralized power.<br><br>Bitco=
in is designed to create an asymmetric advantage for DEFENDING one's wealth=
. It's supposed to be impractically expensive for attackers to crack the en=
tropy and cryptography protecting one's coins. But now we find ourselves di=
scussing a situation where this asymmetric advantage is compromised in favo=
r of a specific class of attackers.<br><br><font size=3D"4">Economic Disrup=
tion</font><br>Large-scale theft from vulnerable addresses could crash Bitc=
oin=E2=80=99s price as quantum recovered funds are dumped on exchanges. Thi=
s would harm all holders, not just those directly targeted, leading to broa=
der financial chaos in the markets.<br><br><font size=3D"4">Moral Responsib=
ility</font><br>Permitting theft via quantum computing sets a precedent tha=
t technological superiority justifies unethical behavior. This is essential=
ly taking a "code is law" stance in which we refuse to admit that both code=
 and laws can be modified to adapt to previously unforeseen situations.<br>=
<br>Burning of coins can certainly be considered a form of theft, thus I th=
ink it's worth differentiating the two different thefts being discussed:<br=
><br>1. self-enriching &amp; likely malicious<br>2. harm prevention &amp; n=
ot necessarily malicious<br><br>Both options lack the consent of the party =
whose coins are being burnt or transferred, thus I think the simple argumen=
t that theft is immoral becomes a wash and it's important to drill down int=
o the details of each.<br><br><font size=3D"4">Incentives Drive Security</f=
ont><br>I can tell you from a decade of working in Bitcoin security - the a=
verage user is lazy and is a procrastinator. If Bitcoiners are given a "dro=
p dead date" after which they know vulnerable funds will be burned, this pr=
essure accelerates the adoption of post-quantum cryptography and strengthen=
s Bitcoin long-term. Allowing vulnerable users to delay upgrading indefinit=
ely will result in more laggards, leaving the network more exposed when qua=
ntum tech becomes available.<br><br><font size=3D"6">Steel Manning<br></fon=
t>Clearly this is a complex and controversial topic, thus it's worth thinki=
ng through the opposing arguments.<br><br><font size=3D"4">Protecting Prope=
rty Rights</font><br>Allowing quantum computers to take vulnerable bitcoin =
could potentially be spun as a hard money narrative - we care so greatly ab=
out not violating someone's access to their coins that we allow them to be =
stolen!<br><br>But I think the flip side to the property rights narrative i=
s that burning vulnerable coins prevents said property from falling into un=
deserving hands. If the entire Bitcoin ecosystem just stands around and all=
ows quantum adversaries to claim funds that rightfully belong to other user=
s, is that really a "win" in the "protecting property rights" category? It =
feels more like apathy to me.<br><br>As such, I think the "protecting prope=
rty rights" argument is a wash.<br><br><font size=3D"4">Quantum Computers W=
on't Attack Bitcoin</font><br>There is a great deal of skepticism that suff=
iciently powerful quantum computers will ever exist, so we shouldn't bother=
 preparing for a non-existent threat. Others have argued that even if such =
a computer was built, a quantum attacker would not go after bitcoin because=
 they wouldn't want to reveal their hand by doing so, and would instead att=
ack other infrastructure.<br><br>It's quite difficult to quantify exactly h=
ow valuable attacking other infrastructure would be. It also really depends=
 upon when an entity gains quantum supremacy and thus if by that time most =
of the world's systems have already been upgraded. While I think you could =
argue that certain entities gaining quantum capability might not attack Bit=
coin, it would only delay the inevitable - eventually somebody will achieve=
 the capability who decides to use it for such an attack.<br><br><font size=
=3D"4">Quantum Attackers Would Only Steal Small Amounts</font><br>Some have=
 argued that even if a quantum attacker targeted bitcoin, they'd only go af=
ter old, likely lost P2PK outputs so as to not arouse suspicion and cause a=
 market panic.<br><br>I'm not so sure about that; why go after 50 BTC at a =
time when you could take 250,000 BTC with the same effort as 50 BTC? This i=
s a classic "zero day exploit" game theory in which an attacker knows they =
have a limited amount of time before someone else discovers the exploit and=
 either benefits from it or patches it. Take, for example, the recent ByBit=
 attack - the highest value crypto hack of all time. Lazarus Group had comp=
romised the Safe wallet front end JavaScript app and they could have simply=
 had it reassign ownership of everyone's Safe wallets as they were interact=
ing with their wallet. But instead they chose to only specifically target B=
yBit's wallet with $1.5 billion in it because they wanted to maximize their=
 extractable value. If Lazarus had started stealing from every wallet, they=
 would have been discovered quickly and the Safe web app would likely have =
been patched well before any billion dollar wallets executed the malicious =
code.<br><br>I think the "only stealing small amounts" argument is stronges=
t for Situation #2 described earlier, where a quantum attacker arrives befo=
re quantum safe cryptography has been deployed across the Bitcoin ecosystem=
. Because if it became clear that Bitcoin's cryptography was broken AND the=
re was nowhere safe for vulnerable users to migrate, the only logical optio=
n would be for everyone to liquidate their bitcoin as quickly as possible. =
As such, I don't think it applies as strongly for situations in which we ha=
ve a migration path available.<br><br><font size=3D"4">The 21 Million Coin =
Supply Should be in Circulation</font><br>Some folks are arguing that it's =
important for the "circulating / spendable" supply to be as close to 21M as=
 possible and that having a significant portion of the supply out of circul=
ation is somehow undesirable.<br><br>While the "21M BTC" attribute is a str=
ong memetic narrative, I don't think anyone has ever expected that it would=
 all be in circulation. It has always been understood that many coins will =
be lost, and that's actually part of the game theory of owning bitcoin!<br>=
<br>And remember, the 21M number in and of itself is not a particularly imp=
ortant detail - it's not even mentioned in the whitepaper. What's important=
 is that the supply is well known and not subject to change.<br><br><font s=
ize=3D"4">Self-Sovereignty and Personal Responsibility</font><br>Bitcoin=E2=
=80=99s design empowers individuals to control their own wealth, free from =
centralized intervention. This freedom comes with the burden of securing on=
e's private keys. If quantum computing can break obsolete cryptography, the=
 fault lies with users who didn't move their funds to quantum safe locking =
scripts. Expecting the network to shield users from their own negligence un=
dermines the principle that you, and not a third party, are accountable for=
 your assets.<br><br>I think this is generally a fair point that "the commu=
nity" doesn't owe you anything in terms of helping you. I think that we do,=
 however, need to consider the incentives and game theory in play with rega=
rd to quantum safe Bitcoiners vs quantum vulnerable Bitcoiners. More on tha=
t later.<br><br><font size=3D"4">Code is Law</font><br>Bitcoin operates on =
transparent, immutable rules embedded in its protocol. If a quantum attacke=
r uses superior technology to derive private keys from public keys, they=E2=
=80=99re not "hacking" the system - they're simply following what's mathema=
tically permissible within the current code. Altering the protocol to stop =
this introduces subjective human intervention, which clashes with the objec=
tive, deterministic nature of blockchain.<br><br>While I tend to agree that=
 code is law, one of the entire points of laws is that they can be amended =
to improve their efficacy in reducing harm. Leaning on this point seems mor=
e like a pro-ossification stance that it's better to do nothing and allow h=
arm to occur rather than take action to stop an attack that was foreseen fa=
r in advance.<br><br><font size=3D"4">Technological Evolution as a Feature,=
 Not a Bug</font><br>It's well known that cryptography tends to weaken over=
 time and eventually break. Quantum computing is just the next step in this=
 progression. Users who fail to adapt (e.g., by adopting quantum-resistant =
wallets when available) are akin to those who ignored technological advance=
ments like multisig or hardware wallets. Allowing quantum theft incentivize=
s innovation and keeps Bitcoin=E2=80=99s ecosystem dynamic, punishing compl=
acency while rewarding vigilance.<br><br><font size=3D"4">Market Signals Dr=
ive Security</font><br>If quantum attackers start stealing funds, it sends =
a clear signal to the market: upgrade your security or lose everything. Thi=
s pressure accelerates the adoption of post-quantum cryptography and streng=
thens Bitcoin long-term. Coddling vulnerable users delays this necessary ev=
olution, potentially leaving the network more exposed when quantum tech bec=
omes widely accessible. Theft is a brutal but effective teacher.<br><br><fo=
nt size=3D"4">Centralized Blacklisting Power</font><br>Burning vulnerable f=
unds requires centralized decision-making - a soft fork to invalidate certa=
in transactions. This sets a dangerous precedent for future interventions, =
eroding Bitcoin=E2=80=99s decentralization. If quantum theft is blocked, wh=
at=E2=80=99s next - reversing exchange hacks? The system must remain neutra=
l, even if it means some lose out.<br><br>I think this could be a potential=
 slippery slope if the proposal was to only burn specific addresses. Rather=
, I'd expect a neutral proposal to burn all funds in locking script types t=
hat are known to be quantum vulnerable. Thus, we could eliminate any subjec=
tivity from the code.<br><br><font size=3D"4">Fairness in Competition</font=
><br>Quantum attackers aren't cheating; they're using publicly available ph=
ysics and math. Anyone with the resources and foresight can build or access=
 quantum tech, just as anyone could mine Bitcoin in 2009 with a CPU. Early =
adopters took risks and reaped rewards; quantum innovators are doing the sa=
me. Calling it =E2=80=9Cunfair=E2=80=9D ignores that Bitcoin has never prom=
ised equality of outcome - only equality of opportunity within its rules.<b=
r><br>I find this argument to be a mischaracterization because we're not ta=
lking about CPUs. This is more akin to talking about ASICs, except each ASI=
C costs millions if not billions of dollars. This is out of reach from all =
but the wealthiest organizations.<br><br><font size=3D"4">Economic Resilien=
ce</font><br>Bitcoin has weathered thefts before (MTGOX, Bitfinex, FTX, etc=
) and emerged stronger. The market can absorb quantum losses, with unaffect=
ed users continuing to hold and new entrants buying in at lower prices. Fea=
r of economic collapse overestimates the impact - the network=E2=80=99s ant=
ifragility thrives on such challenges.<br><br>This is a big grey area becau=
se we don't know when a quantum computer will come online and we don't know=
 how quickly said computers would be able to steal bitcoin. If, for example=
, the first generation of sufficiently powerful quantum computers were stea=
ling less volume than the current block reward then of course it will have =
minimal economic impact. But if they're taking thousands of BTC per day and=
 bringing them back into circulation, there will likely be a noticeable mar=
ket impact as it absorbs the new supply.<br><br>This is where the circumsta=
nces will really matter. If a quantum attacker appears AFTER the Bitcoin pr=
otocol has been upgraded to support quantum resistant cryptography then we =
should expect the most valuable active wallets will have upgraded and the j=
uiciest target would be the 31,000 BTC in the address 12ib7dApVFvg82TXKycWB=
NpN8kFyiAN1dr which has been dormant since 2010. In general I'd expect that=
 the amount of BTC re-entering the circulating supply would look somewhat s=
imilar to the mining emission curve: volume would start off very high as th=
e most valuable addresses are drained and then it would fall off as quantum=
 computers went down the list targeting addresses with less and less BTC.<b=
r><br>Why is economic impact a factor worth considering? Miners and busines=
ses in general. More coins being liquidated will push down the price, which=
 will negatively impact miner revenue. Similarly, I can attest from working=
 in the industry for a decade, that lower prices result in less demand from=
 businesses across the entire industry. As such, burning quantum vulnerable=
 bitcoin is good for the entire industry.<br><br><font size=3D"4">Practical=
ity &amp; Neutrality of Non-Intervention</font><br>There=E2=80=99s no relia=
ble way to distinguish =E2=80=9Ctheft=E2=80=9D from legitimate "white hat" =
key recovery. If someone loses their private key and a quantum computer rec=
overs it, is that stealing or reclaiming? Policing quantum actions requires=
 invasive assumptions about intent, which Bitcoin=E2=80=99s trustless desig=
n can=E2=80=99t accommodate. Letting the chips fall where they may avoids t=
his mess.<br><br><font size=3D"4">Philosophical Purity</font><br>Bitcoin re=
jects bailouts. It=E2=80=99s a cold, hard system where outcomes reflect pre=
paration and skill, not sentimentality. If quantum computing upends the gam=
e, that=E2=80=99s the point - Bitcoin isn=E2=80=99t meant to be safe or fai=
r in a nanny-state sense; it=E2=80=99s meant to be free. Users who lose fun=
ds to quantum attacks are casualties of liberty and their own ignorance, no=
t victims of injustice.<br><br><font size=3D"6">Bitcoin's DAO Moment</font>=
<br>This situation has some similarities to The DAO hack of an Ethereum sma=
rt contract in 2016, which resulted in a fork to stop the attacker and retu=
rn funds to their original owners. The game theory is similar because it's =
a situation where a threat is known but there's some period of time before =
the attacker can actually execute the theft. As such, there's time to mitig=
ate the attack by changing the protocol.<br><br>It also created a schism in=
 the community around the true meaning of "code is law," resulting in Ether=
eum Classic, which decided to allow the attacker to retain control of the s=
tolen funds.<br><br>A soft fork to burn vulnerable bitcoin could certainly =
result in a hard fork if there are enough miners who reject the soft fork a=
nd continue including transactions.<br><br><font size=3D"6">Incentives Matt=
er</font><br>We can wax philosophical until the cows come home, but what ar=
e the actual incentives for existing Bitcoin holders regarding this decisio=
n?<br><br><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.=
8ex; border-left-color: rgb(204, 204, 204); padding-left: 1ex;">"Lost coins=
 only make everyone else's coins worth slightly more. Think of it as a dona=
tion to everyone." - Satoshi Nakamoto</blockquote><br>If true, the corollar=
y is:<br><br><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px=
 0.8ex; border-left-color: rgb(204, 204, 204); padding-left: 1ex;">"Quantum=
 recovered coins only make everyone else's coins worth less. Think of it as=
 a theft from everyone." - Jameson Lopp</blockquote><br>Thus, assuming we g=
et to a point where quantum resistant signatures are supported within the B=
itcoin protocol, what's the incentive to let vulnerable coins remain spenda=
ble?<br><br>* It's not good for the actual owners of those coins. It disinc=
entivizes owners from upgrading until perhaps it's too late.<br>* It's not =
good for the more attentive / responsible owners of coins who have quantum =
secured their stash. Allowing the circulating supply to balloon will assure=
dly reduce the purchasing power of all bitcoin holders.<br><br><font size=
=3D"6">Forking Game Theory</font><br>From a game theory point of view, I se=
e this as incentivizing users to upgrade their wallets. If you disagree wit=
h the burning of vulnerable coins, all you have to do is move your funds to=
 a quantum safe signature scheme. Point being, I don't see there being an e=
conomic majority (or even more than a tiny minority) of users who would fig=
ht such a soft fork. Why expend significant resources fighting a fork when =
you can just move your coins to a new address?<br><br>Remember that blockin=
g spending of certain classes of locking scripts is a tightening of the rul=
es - a soft fork. As such, it can be meaningfully enacted and enforced by a=
 mere majority of hashpower. If miners generally agree that it's in their b=
est interest to burn vulnerable coins, are other users going to care enough=
 to put in the effort to run new node software that resists the soft fork? =
Seems unlikely to me.<br><br><font size=3D"6">How to Execute Burning</font>=
<br>In order to be as objective as possible, the goal would be to announce =
to the world that after a specific block height / timestamp, Bitcoin nodes =
will no longer accept transactions (or blocks containing such transactions)=
 that spend funds from any scripts other than the newly instituted quantum =
safe schemes.<br><br>It could take a staggered approach to first freeze fun=
ds that are susceptible to long-range attacks such as those in P2PK scripts=
 or those that exposed their public keys due to previously re-using address=
es, but I expect the additional complexity would drive further controversy.=
<br><br>How long should the grace period be in order to give the ecosystem =
time to upgrade? I'd say a minimum of 1 year for software wallets to upgrad=
e. We can only hope that hardware wallet manufacturers are able to implemen=
t post quantum cryptography on their existing hardware with only a firmware=
 update.<br><br>Beyond that, it will take at least 6 months worth of block =
space for all users to migrate their funds, even in a best case scenario. T=
hough if you exclude dust UTXOs you could probably get 95% of BTC value mig=
rated in 1 month. Of course this is a highly optimistic situation where eve=
ryone is completely focused on migrations - in reality it will take far lon=
ger.<br><br>Regardless, I'd think that in order to reasonably uphold Bitcoi=
n's conservatism it would be preferable to allow a 4 year migration window.=
 In the meantime, mining pools could coordinate emergency soft forking logi=
c such that if quantum attackers materialized, they could accelerate the co=
untdown to the quantum vulnerable funds burn.<br><br><font size=3D"6">Rando=
m Tangential Benefits</font><br>On the plus side, burning all quantum vulne=
rable bitcoin would allow us to prune all of those UTXOs out of the UTXO se=
t, which would also clean up a lot of dust. Dust UTXOs are a bit of an anno=
yance and there has even been a recent proposal for how to incentivize clea=
ning them up.<br><br>We should also expect that incentivizing migration of =
the entire UTXO set will create substantial demand for block space that wil=
l sustain a fee market for a fairly lengthy amount of time.<br><br><font si=
ze=3D"6">In Summary</font><br>While the moral quandary of violating any of =
Bitcoin's inviolable properties can make this a very complex issue to discu=
ss, the game theory and incentives between burning vulnerable coins versus =
allowing them to be claimed by entities with quantum supremacy appears to b=
e a much simpler issue.<br><br>I, for one, am not interested in rewarding q=
uantum capable entities by inflating the circulating money supply just beca=
use some people lost their keys long ago and some laggards are not upgradin=
g their bitcoin wallet's security.<br><br>We can hope that this scenario ne=
ver comes to pass, but hope is not a strategy.<br><br>I welcome your feedba=
ck upon any of the above points, and contribution of any arguments I failed=
 to consider.</div></div><div><br class=3D"webkit-block-placeholder"></div>=
--&nbsp;<br>You received this message because you are subscribed to the Goo=
gle Groups "Bitcoin Development Mailing List" group.<br>To unsubscribe from=
 this group and stop receiving emails from it, send an email to&nbsp;<a hre=
f=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoindev+unsubscribe=
@googlegroups.com</a>.<br>To view this discussion visit&nbsp;<a href=3D"htt=
ps://groups.google.com/d/msgid/bitcoindev/CADL_X_cF%3DUKVa7CitXReMq8nA_4Rad=
CF%3D%3DkU4YG%2B0GYN97P6hQ%40mail.gmail.com?utm_medium=3Demail&amp;utm_sour=
ce=3Dfooter">https://groups.google.com/d/msgid/bitcoindev/CADL_X_cF%3DUKVa7=
CitXReMq8nA_4RadCF%3D%3DkU4YG%2B0GYN97P6hQ%40mail.gmail.com</a>.</div></blo=
ckquote></div><div dir=3D"ltr"></div></div></div></body></html>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/E8269A1A-1899-46D2-A7CD-4D9D2B732364%40astrotown.de?utm_medium=
=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoindev/=
E8269A1A-1899-46D2-A7CD-4D9D2B732364%40astrotown.de</a>.<br />

--Apple-Mail-0ACFD50B-3670-406F-BC40-FBA4063F0795--