From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 18 May 2026 14:08:03 -0700 Received: from mail-qv1-f60.google.com ([209.85.219.60]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wP5Bx-0001UG-9s for bitcoindev@gnusha.org; Mon, 18 May 2026 14:08:03 -0700 Received: by mail-qv1-f60.google.com with SMTP id 6a1803df08f44-8acb85a973csf35698766d6.3 for ; Mon, 18 May 2026 14:08:01 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1779138475; cv=pass; d=google.com; s=arc-20240605; b=TUtAOztmxNhuzyOx+3kryET2o8ZSa0NHianeeOLmMbeAYm1Y91IOZ+RST1D5eX9Hbw nWz+sYWlDmWZcQ/+vyFiNUP4s8fnybLzGwHCjT/X9lNV7xPJPiJoxaKLNyhlqa51nk25 wQLF20j+WDiWfD8jxoAoocDaEj7HtHFMAOGRdftWc0ktrn2ASfKnu+OVuH10Nhquf4Mn B09/fmq6l9ooh0HU1VFIAU3h1ErCR+rbsqC0tgqIr5h2GMXTXBw9hoizB1pWmfhoMBlR g1azpp8Bc5caBWbIE61NQXcdONNhwc7nzQawS+oYPpj/ivfOvo9yFdEmkVrKFIqqK39e DgUQ== 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:in-reply-to:cc:references :message-id:date:subject:mime-version:from:content-transfer-encoding :sender:dkim-signature:dkim-signature; bh=WeCWGI5WJrPjfVBaTOZlV5tSKt4GbLgACp0Oi6CLuOM=; fh=ilapKmYOVkiRlL7tC2gCNgNVmbq84dgBlms8mowgGqM=; b=FEVDX/R2QwzVE9NVdTPypVOtuaz9AyN7BKVBv8Z4lXmedSHh3WE6/eqcts81ahy+bo 7tGB7UVv4MPbvxAUEpNmFnGOg8QicjSxob2/84BnXuJVnQMqNERmEeN7BEfFRbTfH4by iBY8GCfihJIiJLoHV6vIYDTOE8WQEjMhI1ZkNzM2r0VJHVH1x3djn3WlTmwfIFnWkkHO oLWh8iCiMzmoqF+BG/fnqghZT4En/I0gt1qkgxn8YzhtOJ3oFPZCuX3Ancq8qAxPUwOn TF3/yoWVmG/lpd3u1v4BzS/b0PxlliKcVFi9z2KARteUipsW8dPTZbFnD8Sqj6jL3F4Y 0lFw==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=VkymZgzX; spf=pass (google.com: domain of tomeclair@gmail.com designates 2a00:1450:4864:20::32c as permitted sender) smtp.mailfrom=tomeclair@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1779138475; x=1779743275; 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:in-reply-to:cc:references:message-id:date :subject:mime-version:from:content-transfer-encoding:sender:from:to :cc:subject:date:message-id:reply-to; bh=WeCWGI5WJrPjfVBaTOZlV5tSKt4GbLgACp0Oi6CLuOM=; b=VE5QWuIuPJfLmj4BcVLMA8jCn/3DZWP5ijt97EFI8coDvmSLyX5k06NU5qovayRl1n N11P/fRy5DxRx04qTcQth4VfeudKRc18ZvYqyat92+IbWbaQGGZyBIaJjIMwIpOXlAts aKzeoFB+Rkv/jnpJ+kcOuWvCVIrooIvuDX5HZ21wsN3d+nqp5HQOsE8gH+cSJN1ZizMh ShkNJeDNHVXXVuCQkk+Or5nqYQkxWqxFiMRBc8iAo93ZWoUKL8yPnC0NjSoietu+oqDI c45+7O2DivA3pY9qciBUrN5nJjtCdcQepT/sBXSEk8o/9KAbwB9djVbtOZRTb/4JGVSC KTag== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779138475; x=1779743275; 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:in-reply-to:cc:references:message-id:date :subject:mime-version:from:content-transfer-encoding:from:to:cc :subject:date:message-id:reply-to; bh=WeCWGI5WJrPjfVBaTOZlV5tSKt4GbLgACp0Oi6CLuOM=; b=LTWw8ttSqBUiAvoWb5pHsl6dqB/0STj3IdyTHRRoxnDGaM0nQMJ9V7XQdKeWzgXb+u 5SdoDJ8f1cLodjKv7mFJuT4asWe1Ftvqo1+koLK9y1mHvmE4yfG5OfPKutljmwy1WJkx nxYLwlbfvuy1SwL2ojHxuGEqFXVxAO+7RLFrsZsBCIpsWCHtIaLZljIX2R7Ap30EpOaJ ipdvBRuiZGnQYLP/UROB7Mai+blAjNN6YnHIpxWmYkAStAYzznWhP1HEoktq/HHLjA72 wQezNlgTq5bbdw001RZp3ACAt5l5FSZtrw7Aa1gaUigsa+3zY0NeHKQbzuWX/e8Hu5BP geUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779138475; x=1779743275; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:to:in-reply-to:cc:references:message-id:date :subject:mime-version:from:content-transfer-encoding:x-gm-gg :x-beenthere:x-gm-message-state:sender:from:to:cc:subject:date :message-id:reply-to; bh=WeCWGI5WJrPjfVBaTOZlV5tSKt4GbLgACp0Oi6CLuOM=; b=RER/ACTLqO/7zJQdgAOfZ/HcVK9+rR4qvzjAowuRp/P0d09HAcwnFI+j8j1H9sD6ly fN0hdbYI1Q5/aYYLzdfrcZXZnKn1WEK2YWumli9KV8SElMqB0D6a/GDvgkKHZpZ8kUUK PyJAsk3PmGsXGRhWcyszjUA6kVdwNm+VhA0Bv4iGT5rITiMCAl9kMvLk5aDx4X0IYMQg Qbr621t9T4X89hk8eXjtPiAvCvQwJ8hI6IayFDy5Tscir8rknHFkEXDDwHuO1iXZAWeI fWR8Oq4Cnpu/Y6s3PrfzwoDlehkwyzWwXe0o67knBtJ+Nb/nRp5E5zAZ48oMENKGvIZ7 qOtQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AFNElJ9TTUNfa3B/6EEv9DfyZPcldlVe5JVdR3DgwtQPOi+BImMT+ULa0pUMIHYwQqgdCitSzmwI68DliOds@gnusha.org X-Gm-Message-State: AOJu0YyPzX1pJmnt8/PfZ4Ydi/OdW9F96B9RydxoJF3jwRxXdUdDrPUo A897llxvJWzs3DSFl7h+dTm67fLfw2w9V0n9s6fu4+hnsL/6ZvcBpsou X-Received: by 2002:a05:6214:4288:b0:8ae:655f:28a4 with SMTP id 6a1803df08f44-8ca0f68409amr270929826d6.40.1779138474608; Mon, 18 May 2026 14:07:54 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMM2zni+5NcamLY7IKbgyL+38tYyIqMDIqU6s4FHFNAD8A==" Received: by 2002:a05:622a:4ca:b0:50d:9c5a:dfd2 with SMTP id d75a77b69052e-516455aad4els96627811cf.1.-pod-prod-08-us; Mon, 18 May 2026 14:07:48 -0700 (PDT) X-Received: by 2002:a05:620a:44c4:b0:90e:6dd4:5d7b with SMTP id af79cd13be357-911d01b2661mr2450752685a.55.1779138468236; Mon, 18 May 2026 14:07:48 -0700 (PDT) Received: by 2002:a05:600c:6a86:b0:488:963a:630a with SMTP id 5b1f17b1804b1-48e64f4d523ms5e9; Tue, 12 May 2026 08:04:40 -0700 (PDT) X-Received: by 2002:a05:600c:3055:b0:488:f453:b976 with SMTP id 5b1f17b1804b1-48e51f4e492mr286954505e9.27.1778598278680; Tue, 12 May 2026 08:04:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1778598278; cv=none; d=google.com; s=arc-20240605; b=RM32kYq13AsBdKoj0H1ug9yyG5+n7kaMjlX/diKlFDbl2uAaraozVjhptiIZBOETjw u9hWqyWz0OVTDFLWlMKMOprQ5KNNp3+9rRy4Gug/PailgTs84h/UrxOCCqhSshakUyQh p15YGq7xJeHdksZ2lLo72k173KAUIqCkGt4rZqb99c2aI6n6OeO8yLOgpfILpKyWPZl4 9gMV3y5kjdsZHGPDb+W+0w0tw4mE/tOMqjc2LFJ7MX0yzczOnQlc3lpqWYwE7FvMvNK4 xPEF2jW6a4kQ/cQgMc1Pgrs603bvvCQBc3qW9S9D+5V3Rgig140NVjVbO47C4grhucO5 sUtw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:dkim-signature; bh=6Oj3nhBNZbLHAmupphfR/rJBGj/MNx3r3cHN9LDvrLE=; fh=nRb3XFsSqSjxQRp6EHlq1jnwTB3Q3sXfsi/3sdiql+E=; b=RwCKa1hiDN+s29DpUR/FvrIcCrd9aakClGcUGnwu1ojlqr2ry/R1cBUyDNKi68BJNu zF7FY3LuOg8aPn8BtH72KW+n9hOz+t+O1a7xE5rFSF6CxziLmHJlDZrYgOqE6zfBXwAP njSUhQv+vaHZvE4qZATStrdcXHh3Lz2mh+7lAfZujqUDZxGAW9RYUF5mKFWkRDtwGbFn Kme0uYR6pTfWMdSf7OYK6uxXe2g3MqiLJGFKTr90gtYCK7C4K84ar6XMRhzxkyzSl/8r rk4Susynpd/olwgsf6t1/tOnC4EE82uH53rgtcaclnIJEnQWIbHwSBlM76RBUXxpMIbU Vz4A==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=VkymZgzX; spf=pass (google.com: domain of tomeclair@gmail.com designates 2a00:1450:4864:20::32c as permitted sender) smtp.mailfrom=tomeclair@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com. [2a00:1450:4864:20::32c]) by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-48fc8d1b264si32465e9.1.2026.05.12.08.04.38 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 May 2026 08:04:38 -0700 (PDT) Received-SPF: pass (google.com: domain of tomeclair@gmail.com designates 2a00:1450:4864:20::32c as permitted sender) client-ip=2a00:1450:4864:20::32c; Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-48909558b3aso58156095e9.0 for ; Tue, 12 May 2026 08:04:38 -0700 (PDT) X-Gm-Gg: Acq92OF/Nhfqkio5zT+3aqSbB7Rl8JuO09Xa/cHs7xnxgn9jtgrmHmSF1tNJWhnTXJh AChRb856DBtsy863xas+45hN4P4yPux/PPyWQLIaZss7nruJmZFAPHHg+/xLdykKs6amZZllrVs lIlOVHOcN4axUPuPb+O6+/xkyJ4za18CbqCMdz8rJMjy6QmdI+2QOHXagy68ZHiThpi7Bhhs/6f hBLQYYkNuoOLurFjHNOZYDEH9KKIReFl6pBEFFJiaplmJuYSTGCBY/0jG/LEjM9//jiUjTQIspB dTOu/QnsFzUjW15eDG/F/d/5OTagdU9aprPIkwsIHMTm/jqW03utLTDHiRUPf13sZJMj92MBnTL dVrOB+Hg4LAJxUx45c/O4hW0U2D4G46EVNfAGZ5dmHppUdmTCZLrSLJ0jyGYC1bfchCtRgArB3e kY6eiRPkU7IzbUyRxMFF+pOgqbQHu/5XDaxt25dvNDuxAP0xDQIo3ds1MO82vQ5afOHw== X-Received: by 2002:a05:600c:a30d:b0:48e:6db3:ff3a with SMTP id 5b1f17b1804b1-48e6db3ffdfmr171079605e9.16.1778598277079; Tue, 12 May 2026 08:04:37 -0700 (PDT) Received: from smtpclient.apple ([2a0d:e487:31ce:ed8c:2838:24e8:c5e0:4415]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48fc8d1f6dbsm3359875e9.6.2026.05.12.08.04.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 May 2026 08:04:35 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-37F15B76-2010-41E5-A69E-9A4882AC6933 Content-Transfer-Encoding: 7bit From: thomas suau Mime-Version: 1.0 (1.0) Subject: Re: [bitcoindev] Against Allowing Quantum Recovery of Bitcoin Date: Tue, 12 May 2026 17:04:24 +0200 Message-Id: <9564EAA8-807A-4448-8A92-FEEAC92D4709@gmail.com> References: Cc: bitcoindev@googlegroups.com In-Reply-To: To: Wenhao Saint X-Mailer: iPhone Mail (23E261) X-Original-Sender: tomeclair@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=VkymZgzX; spf=pass (google.com: domain of tomeclair@gmail.com designates 2a00:1450:4864:20::32c as permitted sender) smtp.mailfrom=tomeclair@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: 2.3 (++) --Apple-Mail-37F15B76-2010-41E5-A69E-9A4882AC6933 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Thanks for= the pushback. A few points worth challenging though:

The chainwork argument doesn't hold =E2=80= =94 miners hash block headers with SHA-256d. That accumulated work is not t= ransferable to a RIPEMD-160 collision attack. These are orthogonal problems= .

The known practical = vector =E2=80=94 a chosen-prefix collision forcing a victim into a maliciou= s multisig script =E2=80=94 requires interaction and social engineering, no= t just raw hash collision. No algorithm achieves this non-interactively.

Finally, if 160-bit outp= ut were inherently insufficient, the argument would apply equally to P2PKH = =E2=80=94 making it a general Bitcoin problem, not a P2SH-specific one. Tha= t's a much bigger claim than what BIP-141 is making.

Regards,=  
Thomas


On 29 Apr 2026, at 08:21, Saint= Wenhao <saintwenhao@gmail.com> wrote:

=EF=BB=BF
> P2SH,= P2WSH outputs which have never spent are not at risk

P2SH has a ris= k of collision, when it is used by more than one user. Which is why P2WSH u= ses SHA-256 alone, without pushing the result of that through RIPEMD-160. I= t is even described in BIP-141, as a justification for P2WSH: https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#= user-content-P2WSH

> The scriptPubKey occupies 34 bytes, as o= pposed to 23 bytes of BIP16 P2SH. The increased size improves security agai= nst possible collision attacks, as 2^80 work is not infeasible anymore (By = the end of 2015, 2^84 hashes have been calculated in Bitcoin mining since t= he creation of Bitcoin). The spending script is same as the one for an equi= valent BIP16 P2SH output but is moved to witness.

And now, in 2026, = we have around 2^96 chainwork. Which could make these attacks more practica= l than theoretical. While quantum computers are still in theory, so if I wo= uld have to guess, then I would put more money on a scenario, where RIPEMD-= 160 collision is found faster than anyone will break secp256k1. There are e= ven some canaries, which could give some incentive to reveal RIPEMD-160 col= lision, for example 3KyiQEGqqdb4nqfhUzGKN6KPhXmQsLNpay or 39VXyuoc6SXYKp9Tc= AhoiN1mb4ns6z3Yu6.

But yes, for a single user, 160-bit addresses are= safe to use, at least for now. However, publishing the first collision may= create a lot of FUD, and then, moving these coins to a different address t= ype will be highly recommended, because then you will never know, if new 16= 0-bit addresses can be spent in more ways, which were not yet disclosed on-= chain.

wt., 28 kwi 2026 o 22:47 Thomas Suau <= ;tomeclair@gmail.com> napisa= =C5=82(a):
<= p>Hi, 

Against freezing.

A vulnerable user post-CRQC is so= meone who made two active choices: reusing addresses, and not migrating onc= e a standard is available. That's the user breaking the social contract, no= t the protocol. P2PKH, P2WPKH, P2SH, P2WSH outputs which have never spent a= re not at risk =E2=80=94 pubkey is hashed, not exposed. P2PK, reused addres= ses, and P2TR key path are. Bitcoin isn't globally broken =E2=80=94 specifi= c address types are, and users holding them after a migration path exists a= re accepting the risk.

A script-type freeze applies uniformly to weak= output types, not to specific transactions =E2=80=94 categorically differe= nt from reversing exchange hacks. But once the protocol starts deciding whi= ch coins are safe enough to spend, that logic is hard to contain.

Eit= her way, the freeze debate is a signal, not the goal. It tells us we need a= standard urgently. That's where the energy should go =E2=80=94 Matt's thre= ad is asking the right question What's our goal?.

Re= gards,


Thomas

<= /div>
Le jeudi 9 avril 2026 =C3=A0 10:36:50 UTC+2, Jameson Lopp a =C3=A9cr= it :
Scratch that; nodes should already be storing the block for whic= h a UTXO was confirmed in order to calculate relative timelock validity. So= it should be implementable.

Still, there are several vague statemen= ts that could use more explanation.

"predictable cliffs invite adver= sarial behavior." - such as?

"This avoids retroactively invalidating= old transactions while still phasing out insecure constructions." - how so= ? If you chose a relative max age that's less than the total age of Bitcoin= itself, it will by default invalidate extremely old UTXOs.

"If the = protocol begins to distinguish between =E2=80=9Clegitimate=E2=80=9D and =E2= =80=9Cquantum=E2=80=91recovered=E2=80=9D spends" - not sure what this means= . It's not possible to know if a transaction was made by a quantum attacker= .

On Thu, Apr 9, 2026 at 9:04=E2=80=AFAM Jameson Lopp <jameso...@gmail.com> wrote:
While an implied age timelock is inte= resting in theory, I don't think it's practical in reality.

The reas= on that current styles of timelocks work well is because they are explicit:= the actual block height / timestamp of the lock is contained somewhere ins= ide of the transaction itself.

In order to implement an "implied" sc= heme as you propose, it would require all nodes to start indexing UTXOs by = block height in order to avoid a massive performance drop when evaluating w= hether or not the UTXO is spendable.

On Thu, Apr 9, 2026 at 3:01=E2=80=AFAM = Bitcoin <lovelo...@gmail.com> wrote:
The pr= otocol should not assume that future participants will be able to coordinat= e around a single deadline without distortion. A fixed height at which old = outputs become invalid would create a predictable cliff, and predictable cl= iffs invite adversarial behavior. Markets tend to rush toward the edge.
Bitcoin works best when incentive= s are continuous rather than abrupt.

A staggered expiration of vulnerable script types is more cons= istent with the system=E2=80=99s long=E2=80=91term stability. If a class of= outputs is known to be weak against new computation, then the network can = define a rule that such outputs must be spent within a certain number of bl= ocks after creation. This avoids retroactively invalidating old transaction= s while still phasing out insecure constructions.
The network already treats some script forms as d= iscouraged. Extending this to prohibit creation of new vulnerable forms is = a natural evolution. Nodes can continue to validate the old chain history w= hile refusing to relay or mine new transactions that expose public keys dir= ectly.

The idea of forci= ng quantum=E2=80=91recovered coins into long timelocks is interesting, but = it introduces a new class of special=E2=80=91case behavior. Bitcoin=E2=80= =99s rules should be simple, general, and predictable. If the protocol begi= ns to distinguish between =E2=80=9Clegitimate=E2=80=9D and =E2=80=9Cquantum= =E2=80=91recovered=E2=80=9D spends, it implies an authority deciding which = coins are morally valid. That is a precedent the system should avoid.
=

The safest rule is the one th= at does not require judging intent.

A relative or absolute timelock applied uniformly to all vulner= able outputs, triggered only by their age, is neutral. It does not ask who = is spending the coins or why. It only enforces that insecure forms must be = migrated in time.

The ne= twork cannot prevent advances in mathematics or computation. It can only en= sure that the incentives remain aligned so that users upgrade their securit= y before adversaries can exploit weaknesses. The protocol should encourage = timely movement without confiscation.

The principle remains:

Your keys, your coins =E2=80=94 but only as long as the key is= strong.

If a key type b= ecomes weak, the system must give ample time to move funds to stronger cons= tructions, and then retire the weak form gradually so the chain does not be= come a liability.

=E2=80= =94 S.

On Mon, Apr 7, 2025, 6:34=E2=80=AFAM Nadav Ivgi <na...@shesek.info> wrote:
One possib= le alternative to freezing/burning the coins entirely is letting quantum at= tackers keep some small percent as a reward, but force them to stage the re= st to future miners as an additional security budget subsidy.
This can be implemented as a soft fork, by requiring = transactions=20 spending QC-vulnerable coins to allocate some funds to an OP_CLTV[0]-only e= ncumbered output timelocked far into the future. Miners would then monitor = these outputs and claim them as they become available.

For example, allow a 1% reward to be spent freely to any a= ddress but require 99% to be sent to an OP_CLTV output timelocked to a dete= rministically random height between 10-100 years from now.

Th= e 1% reward could also be required to be sent to a script that enforces a t= imelock (in addition to other conditions), to avoid flooding the markets wi= th the rewarded coins all at once. Probably a shorter timelock duration tho= ugh, say picked randomly between 10-30 months.

To = further smooth out variance in the release schedule, coins could be split i= nto up-to-N-BTC outputs, each staggered with a different deterministic time= lock. So for example, a single tx spending 10,000 BTC won't release 9,900 B= TC to the miners in a single far-future block (which may cause chain instab= ility if the miners get into a reorg war over it), but rather as 9,900 sepa= rate outputs of 1 BTC each released gradually time.[1]

<= /div>
I'm still not sure what I think about this. This is not necessari= ly an endorsement, just a thought. :)

- shesek

[0] OP_CSV only supports relative timelocks of up to = 65535 blocks (~15 months), which is too short for that purpose. OP_CLTV sup= ports longer (absolute) timelocks.

[1] This can be= made more efficient with CTV, by having a single UTXO carrying the full am= ount that slowly unrolls rather than 9,900 separate UTXO entries.


On Sun, Mar 16, 2025 at 5:22=E2=80=AFPM Jameson Lopp <jameso...@gmail.com> wrote:
The quantum computin= g debate is heating up. There are many controversial aspects to this debate= , including whether or not quantum computers will ever actually become a pr= actical threat.

I won't tread into the unanswerable question of how= worried we should be about quantum computers. I think it's far from a cris= is, but given the difficulty in changing Bitcoin it's worth starting to ser= iously discuss. Today I wish to focus on a philosophical quandary related t= o one of the decisions that would need to be made if and when we implement = a quantum safe signature scheme.

Several Scenarios<= br>Because this essay will reference game theory a fair amount, and = there are many variables at play that could change the nature of the game, = I think it's important to clarify the possible scenarios up front.

1= . Quantum computing never materializes, never becomes a threat, and thus ev= erything discussed in this essay is moot.
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 belo= w moot because Bitcoin would be fundamentally broken and it would take far = too long to upgrade the protocol, wallet software, and migrate user funds i= n order to restore confidence in the network.
3. Quantum computing advan= ces slowly enough that we come to consensus about how to upgrade Bitcoin an= d post quantum security has been minimally adopted by the time an attacker = appears.
4. Quantum computing advances slowly enough that we come to con= sensus about how to upgrade Bitcoin and post quantum security has been high= ly adopted by the time an attacker appears.

For the purposes of this= post, I'm envisioning being in situation 3 or 4.

T= o Freeze or not to Freeze?
I've started seeing more people weighi= ng in on what is likely the most contentious aspect of how a quantum resist= ance upgrade should be handled in terms of migrating user funds. Should qua= ntum vulnerable funds be left open to be swept by anyone with a sufficientl= y powerful quantum computer OR should they be permanently locked?

"I don't see why old coins = should be confiscated. The better option is to let those with quantum compu= ters free up old coins. While this might have an inflationary impact on bit= coin's price, to use a turn of phrase, the inflation is transitory. Those w= ith low time preference should support returning lost coins to circulation.= " 
- Hun= ter Beast

On the other hand:

"Of course they have to be con= fiscated. If and when (and that's a big if) the existence of a cryptography= -breaking QC becomes a credible threat, the Bitcoin ecosystem has no other = option than softforking out the ability to spend from signature schemes (in= cluding ECDSA and BIP340) that are vulnerable to QCs. The alternative is th= at millions of BTC become vulnerable to theft; I cannot see how the currenc= y can maintain any value at all in such a setting. And this affects everyon= e; even those which diligently moved their coins to PQC-protected schemes."=
- Pieter Wuille

I don't think "confiscation" is the mos= t precise term to use, as the funds are not being seized and reassigned. Ra= ther, what we're really discussing would be better described as "burning" -= placing the funds out of reach of everyone.

Not freezing use= r funds is one of Bitcoin's inviolable properties. However, if quantum comp= uting becomes a threat to Bitcoin's elliptic curve cryptography, an invi= olable property of Bitcoin will be violated one way or another.

= Fundamental Properties at Risk
5 years ago I att= empted to comprehensively categorize all of Bitcoin's fundamental propertie= s that give it value. https://n= akamoto.com/what-are-the-key-properties-of-bitcoin/

The particul= ar properties in play with regard to this issue seem to be:

Censo= rship Resistance - No one should have the power to prevent others from = using their bitcoin or interacting with the network.

Forward Comp= atibility - changing the rules such that certain valid transactions bec= ome invalid could undermine confidence in the protocol.

Conservat= ism - Users should not be expected to be highly responsive to system is= sues.

As a result of the above principles, we have developed a stron= g meme (kudos to Andreas Antonopoulos) that goes as follows:

Not your keys, not your coins.
I posit that the corollary to this principle is:

Your keys, only your coins.
A quantum capable entity breaks the corollary of this founda= tional principle. We secure our bitcoin with the mathematical probabilities= related to extremely large random numbers. Your funds are only secure beca= use truly random large numbers should not be guessable or discoverable by a= nyone else in the world.

This is the principle behind the motto v= ires in numeris - strength in numbers. In a world with quantum enabled = adversaries, this principle is null and void for many types of cryptography= , including the elliptic curve digital signatures used in Bitcoin.

<= font size=3D"6">Who is at Risk?
There has long been a narrative t= hat Satoshi's coins and others from the Satoshi era of P2PK locking scripts= that exposed the public key directly on the blockchain will be those that = get scooped up by a quantum "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 list and find the wallets that have exposed their publi= c keys due to re-using addresses that have previously been spent from. You = can easily find them at htt= ps://bitinfocharts.com/top-100-richest-bitcoin-addresses.html

No= te that a few of these wallets, like Bitfinex / Kraken / Tether, would be s= lightly harder to crack because they are multisig wallets. So a quantum att= acker would need to reverse engineer 2 keys for Kraken or 3 for Bitfinex / = Tether in order to spend funds. But many are single signature.

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 quantum safe s= ignature scheme, we should expect those wallets to be some of the first to = upgrade given their incentives.

The Ethical Dilemma= : Quantifying Harm
Which decision results in the most harm?
By making quantum vulnerable funds unspendable we potentially harm some B= itcoin users who were not paying attention and neglected to migrate their f= unds to a quantum safe locking script. This violates the "conservativism" p= rinciple stated earlier. On the flip side, we prevent those funds plus far = more lost funds from falling into the hands of the few privileged folks who= gain early access to quantum computers.

By leaving quantum vulnerab= le funds available to spend, the same set of users who would otherwise have= funds frozen are likely to see them stolen. And many early adopters who lo= st their keys will eventually see their unreachable funds scooped up by a q= uantum enabled adversary.

Imagine, for example, being James Howells,= who accidentally threw away a hard drive with 8,000 BTC on it, currently w= orth over $600M USD. He has spent a decade trying to retrieve it from the l= andfill where he knows it's buried, but can't get permission to excavate. I= suspect that, given the choice, he'd prefer those funds be permanently fro= zen rather than fall into someone else's possession - I know I would.
Allowing a quantum computer to access lost funds doesn't make those users= any worse off than they were before, however it would have a negati= ve impact upon everyone who is currently holding bitcoin.

It's prude= nt to expect significant economic disruption if large amounts of coins fall= into new hands. Since a quantum computer is going to have a massive up fro= nt cost, expect those behind it to desire to recoup their investment. We al= so know from experience that when someone suddenly finds themselves in poss= ession of 9+ figures worth of highly liquid assets, they tend to diversify = into other things by selling.

Allowing quantum recovery of bitcoin i= s tantamount to wealth redistribution. What we'd be allowing is for = bitcoin to be redistributed from those who are ignorant of quantum computer= s to those who have won the technological race to acquire quantum computers= . It's hard to see a bright side to that scenario.

= Is Quantum Recovery Good for Anyone?

Does quantum recovery HE= LP anyone? I've yet to come across an argument that it'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 c= laimed by those who did not earn them.

But wait, you may be thinking= , wouldn't quantum "miners" have earned their coins by all the work and res= ources invested in building a quantum computer? I suppose, in the same sens= e that a burglar earns their spoils by the resources they invest into surve= illing targets and learning the skills needed to break into buildings. What= I say "earned" I mean through productive mutual trade.

For example:=

* Investors earn BTC by trading for other currencies.
* Merchant= s earn BTC by trading for goods and services.
* Miners earn BTC by tradi= ng thermodynamic security.
* Quantum miners don't trade anything, they a= re vampires feeding upon the system.

There's no reason to believe th= at allowing quantum adversaries to recover vulnerable bitcoin will be of be= nefit to anyone other than the select few organizations that win the techno= logical arms race to build the first such computers. Probably nation states= and/or the top few largest tech companies.

One could certainly hope= that an organization with quantum supremacy is benevolent and acts in a "w= hite hat" manner to return lost coins to their owners, but that's incredibl= y optimistic and foolish to rely upon. Such a situation creates an insurmou= ntable ethical dilemma of only recovering lost bitcoin rather than currentl= y owned bitcoin. There's no way to precisely differentiate between the two;= anyone can claim to have lost their bitcoin but if they have lost their ke= ys then proving they ever had the keys becomes rather difficult. I imagine = that any such white hat recovery efforts would have to rely upon attestatio= ns from trusted third parties like exchanges.

Even if the first acto= r with quantum supremacy is benevolent, we must assume the technology could= fall into adversarial hands and thus think adversarially about the potenti= al worst case outcomes. Imagine, for example, that North Korea continues sc= ooping up billions of dollars from hacking crypto exchanges and decides to = invest some of those proceeds into building a quantum computer for the bigg= est payday ever...

Downsides to Allowing Quantum Re= covery
Let's think through an exhaustive list of pros and cons fo= r allowing or preventing the seizure of funds by a quantum adversary.
Historical Precedent
Previous protocol vulnera= bilities weren=E2=80=99t celebrated as "fair game" but rather were treated = as failures to be remediated. Treating quantum theft differently risks rewr= iting Bitcoin=E2=80=99s history as a free-for-all rather than a system that= seeks to protect its users.

Violation of Property = Rights
Allowing a quantum adversary to take control of funds unde= rmines the fundamental principle of cryptocurrency - if you keep your keys = in your possession, only you should be able to access your money. Bitcoin i= s built on the idea that private keys secure an individual=E2=80=99s assets= , and unauthorized access (even via advanced tech) is theft, not a legitima= te transfer.

Erosion of Trust in Bitcoin
= If quantum attackers can exploit vulnerable addresses, confidence in Bitcoi= n as a secure store of value would collapse. Users and investors rely on cr= yptographic integrity, and widespread theft could drive adoption away from = Bitcoin, destabilizing its ecosystem.

This is essentially the counte= rpoint to claiming the burning of vulnerable funds is a violation of proper= ty rights. While some will certainly see it as such, others will find the a= pathy toward stopping quantum theft to be similarly concerning.

Unfair Advantage
Quantum attackers, likely equipped = with rare and expensive technology, would have an unjust edge over regular = users who lack access to such tools. This creates an inequitable system whe= re only the technologically elite can exploit others, contradicting Bitcoin= =E2=80=99s ethos of decentralized power.

Bitcoin is designed to crea= te an asymmetric advantage for DEFENDING one's wealth. It's supposed to be = impractically expensive for attackers to crack the entropy and cryptography= protecting one's coins. But now we find ourselves discussing a situation w= here this asymmetric advantage is compromised in favor of a specific class = of attackers.

Economic Disruption
Large-s= cale theft from vulnerable addresses could crash Bitcoin=E2=80=99s price as= quantum recovered funds are dumped on exchanges. This would harm all holde= rs, not just those directly targeted, leading to broader financial chaos in= the markets.

Moral Responsibility
Permit= ting theft via quantum computing sets a precedent that technological superi= ority justifies unethical behavior. This is essentially taking a "code is l= aw" stance in which we refuse to admit that both code and laws can be modif= ied to adapt to previously unforeseen situations.

Burning of coins c= an certainly be considered a form of theft, thus I think it's worth differe= ntiating the two different thefts being discussed:

1. self-enriching= & likely malicious
2. harm prevention & not necessarily malicio= us

Both options lack the consent of the party whose coins are being = burnt or transferred, thus I think the simple argument that theft is immora= l becomes a wash and it's important to drill down into the details of each.=

Incentives Drive Security
I can tell you= from a decade of working in Bitcoin security - the average user is lazy an= d is a procrastinator. If Bitcoiners are given a "drop dead date" after whi= ch they know vulnerable funds will be burned, this pressure accelerates the= adoption of post-quantum cryptography and strengthens Bitcoin long-term. A= llowing vulnerable users to delay upgrading indefinitely will result in mor= e laggards, leaving the network more exposed when quantum tech becomes avai= lable.

Steel Manning
Clearly this is a co= mplex and controversial topic, thus it's worth thinking through the opposin= g arguments.

Protecting Property Rights
A= llowing quantum computers to take vulnerable bitcoin could potentially be s= pun as a hard money narrative - we care so greatly about not violating some= one's access to their coins that we allow them to be stolen!

But I t= hink the flip side to the property rights narrative is that burning vulnera= ble coins prevents said property from falling into undeserving hands. If th= e entire Bitcoin ecosystem just stands around and allows quantum adversarie= s to claim funds that rightfully belong to other users, is that really a "w= in" in the "protecting property rights" category? It feels more like apathy= to me.

As such, I think the "protecting property rights" argument i= s a wash.

Quantum Computers Won't Attack Bitcoin
There is a great deal of skepticism that sufficiently powerful quan= tum computers will ever exist, so we shouldn't bother preparing for a non-e= xistent 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 attack other infrastructu= re.

It's quite difficult to quantify exactly how valuable attacking = other infrastructure would be. It also really depends upon when an entity g= ains 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 ent= ities gaining quantum capability might not attack Bitcoin, it would only de= lay the inevitable - eventually somebody will achieve the capability who de= cides to use it for such an attack.

Quantum Attacke= rs Would Only Steal Small Amounts
Some have argued that even if a= quantum attacker targeted bitcoin, they'd only go after old, likely lost P= 2PK outputs so as to not arouse suspicion and cause a market panic.

= I'm not so sure about that; why go after 50 BTC at a time when you could ta= ke 250,000 BTC with the same effort as 50 BTC? This is 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 compromised the Safe walle= t front end JavaScript app and they could have simply had it reassign owner= ship of everyone's Safe wallets as they were interacting with their wallet.= But instead they chose to only specifically target ByBit'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 disco= vered quickly and the Safe web app would likely have been patched well befo= re any billion dollar wallets executed the malicious code.

I think t= he "only stealing small amounts" argument is strongest for Situation #2 des= cribed earlier, where a quantum attacker arrives before quantum safe crypto= graphy has been deployed across the Bitcoin ecosystem. Because if it became= clear that Bitcoin's cryptography was broken AND there was nowhere safe fo= r vulnerable users to migrate, the only logical option would be for everyon= e to liquidate their bitcoin as quickly as possible. As such, I don't think= it applies as strongly for situations in which we have a migration path av= ailable.

The 21 Million Coin Supply Should be in Ci= rculation
Some folks are arguing that it's important for the "cir= culating / spendable" supply to be as close to 21M as possible and that hav= ing a significant portion of the supply out of circulation is somehow undes= irable.

While the "21M BTC" attribute is a strong 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 ac= tually part of the game theory of owning bitcoin!

And remember, the = 21M number in and of itself is not a particularly important detail - it's n= ot even mentioned in the whitepaper. What's important is that the supply is= well known and not subject to change.

Self-Soverei= gnty and Personal Responsibility
Bitcoin=E2=80=99s design empower= s individuals to control their own wealth, free from centralized interventi= on. This freedom comes with the burden of securing one's private keys. If q= uantum 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 undermines the principle= that you, and not a third party, are accountable for your assets.

I= think this is generally a fair point that "the community" doesn't owe you = anything in terms of helping you. I think that we do, however, need to cons= ider the incentives and game theory in play with regard to quantum safe Bit= coiners vs quantum vulnerable Bitcoiners. More on that later.

Code is Law
Bitcoin operates on transparent, immutable= rules embedded in its protocol. If a quantum attacker uses superior techno= logy to derive private keys from public keys, they=E2=80=99re not "hacking"= the system - they're simply following what's mathematically permissible wi= thin the current code. Altering the protocol to stop this introduces subjec= tive human intervention, which clashes with the objective, deterministic na= ture of blockchain.

While I tend to agree that code is law, one of t= he entire points of laws is that they can be amended to improve their effic= acy in reducing harm. Leaning on this point seems more like a pro-ossificat= ion stance that it's better to do nothing and allow harm to occur rather th= an take action to stop an attack that was foreseen far in advance.

<= font size=3D"4">Technological Evolution as a Feature, Not a Bug
I= t's well known that cryptography tends to weaken over time and eventually b= reak. Quantum computing is just the next step in this progression. Users wh= o fail to adapt (e.g., by adopting quantum-resistant wallets when available= ) are akin to those who ignored technological advancements like multisig or= hardware wallets. Allowing quantum theft incentivizes innovation and keeps= Bitcoin=E2=80=99s ecosystem dynamic, punishing complacency while rewarding= vigilance.

Market Signals Drive SecurityIf quantum attackers start stealing funds, it sends a clear signal to the = market: upgrade your security or lose everything. This pressure accelerates= the adoption of post-quantum cryptography and strengthens Bitcoin long-ter= m. Coddling vulnerable users delays this necessary evolution, potentially l= eaving the network more exposed when quantum tech becomes widely accessible= . Theft is a brutal but effective teacher.

Centrali= zed Blacklisting Power
Burning vulnerable funds requires centrali= zed decision-making - a soft fork to invalidate certain transactions. This = sets a dangerous precedent for future interventions, eroding Bitcoin=E2=80= =99s decentralization. If quantum theft is blocked, what=E2=80=99s next - r= eversing exchange hacks? The system must remain neutral, even if it means s= ome lose out.

I think this could be a potential slippery slope if th= e proposal was to only burn specific addresses. Rather, I'd expect a neutra= l proposal to burn all funds in locking script types that are known to be q= uantum vulnerable. Thus, we could eliminate any subjectivity from the code.=

Fairness in Competition
Quantum attacker= s aren't cheating; they're using publicly available physics and math. Anyon= e with the resources and foresight can build or access quantum tech, just a= s anyone could mine Bitcoin in 2009 with a CPU. Early adopters took risks a= nd reaped rewards; quantum innovators are doing the same. Calling it =E2=80= =9Cunfair=E2=80=9D ignores that Bitcoin has never promised equality of outc= ome - only equality of opportunity within its rules.

I find this arg= ument to be a mischaracterization because we're not talking about CPUs. Thi= s is more akin to talking about ASICs, except each ASIC costs millions if n= ot billions of dollars. This is out of reach from all but the wealthiest or= ganizations.

Economic Resilience
Bitcoin = has weathered thefts before (MTGOX, Bitfinex, FTX, etc) and emerged stronge= r. The market can absorb quantum losses, with unaffected users continuing t= o hold and new entrants buying in at lower prices. Fear of economic collaps= e overestimates the impact - the network=E2=80=99s antifragility thrives on= such challenges.

This is a big grey area because we don't know when= a quantum computer will come online and we don't know how quickly said com= puters would be able to steal bitcoin. If, for example, the first generatio= n of sufficiently powerful quantum computers were stealing less volume than= the current block reward then of course it will have minimal economic impa= ct. But if they're taking thousands of BTC per day and bringing them back i= nto circulation, there will likely be a noticeable market impact as it abso= rbs the new supply.

This is where the circumstances will really matt= er. If a quantum attacker appears AFTER the Bitcoin protocol has been upgra= ded to support quantum resistant cryptography then we should expect the mos= t valuable active wallets will have upgraded and the juiciest target would = be the 31,000 BTC in the address 12ib7dApVFvg82TXKycWBNpN8kFyiAN1dr which h= as been dormant since 2010. In general I'd expect that the amount of BTC re= -entering the circulating supply would look somewhat similar to the mining = emission curve: volume would start off very high as the most valuable addre= sses are drained and then it would fall off as quantum computers went down = the list targeting addresses with less and less BTC.

Why is economic= impact a factor worth considering? Miners and businesses in general. More = coins being liquidated will push down the price, which will negatively impa= ct miner revenue. Similarly, I can attest from working in the industry for = a decade, that lower prices result in less demand from businesses across th= e entire industry. As such, burning quantum vulnerable bitcoin is good for = the entire industry.

Practicality & Neutrality = of Non-Intervention
There=E2=80=99s no reliable way to distinguis= h =E2=80=9Ctheft=E2=80=9D from legitimate "white hat" key recovery. If some= one loses their private key and a quantum computer recovers it, is that ste= aling or reclaiming? Policing quantum actions requires invasive assumptions= about intent, which Bitcoin=E2=80=99s trustless design can=E2=80=99t accom= modate. Letting the chips fall where they may avoids this mess.

Philosophical Purity
Bitcoin rejects bailouts. It=E2= =80=99s a cold, hard system where outcomes reflect preparation and skill, n= ot sentimentality. If quantum computing upends the game, that=E2=80=99s the= point - Bitcoin isn=E2=80=99t meant to be safe or fair in a nanny-state se= nse; it=E2=80=99s meant to be free. Users who lose funds to quantum attacks= are casualties of liberty and their own ignorance, not victims of injustic= e.

Bitcoin's DAO Moment
This situation ha= s some similarities to The DAO hack of an Ethereum smart contract in 2016, = which resulted in a fork to stop the attacker and return funds to their ori= ginal owners. The game theory is similar because it's a situation where a t= hreat is known but there's some period of time before the attacker can actu= ally execute the theft. As such, there's time to mitigate the attack by cha= nging the protocol.

It also created a schism in the community around= the true meaning of "code is law," resulting in Ethereum Classic, which de= cided to allow the attacker to retain control of the stolen funds.

A= soft fork to burn vulnerable bitcoin could certainly result in a hard fork= if there are enough miners who reject the soft fork and continue including= transactions.

Incentives Matter
We can w= ax philosophical until the cows come home, but what are the actual incentiv= es for existing Bitcoin holders regarding this decision?

"Lost coins only make everyone else'= s coins worth slightly more. Think of it as a donation to everyone." - Sato= shi Nakamoto

If true, the corollary is:

"Quantum recovered coins only make ev= eryone else's coins worth less. Think of it as a theft from everyone." - Ja= meson Lopp

Thus, assuming we get to a point where quantum r= esistant signatures are supported within the Bitcoin protocol, what's the i= ncentive to let vulnerable coins remain spendable?

* It's not good f= or the actual owners of those coins. It disincentivizes owners from upgradi= ng until perhaps it's too late.
* 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 assuredly reduce the purchasing pow= er of all bitcoin holders.

Forking Game Theory
From a game theory point of view, I see this as incentivizing users t= o upgrade their wallets. If you disagree with the burning of vulnerable coi= ns, all you have to do is move your funds to a quantum safe signature schem= e. Point being, I don't see there being an economic majority (or even more = than a tiny minority) of users who would fight such a soft fork. Why expend= significant resources fighting a fork when you can just move your coins to= a new address?

Remember that blocking spending of certain classes o= f locking scripts is a tightening of the rules - a soft fork. As such, it c= an be meaningfully enacted and enforced by a mere majority of hashpower. If= miners generally agree that it's in their best interest to burn vulnerable= coins, are other users going to care enough to put in the effort to run ne= w node software that resists the soft fork? Seems unlikely to me.

How to Execute Burning
In order to be as objective= as possible, the goal would be to announce to the world that after a speci= fic block height / timestamp, Bitcoin nodes will no longer accept transacti= ons (or blocks containing such transactions) that spend funds from any scri= pts other than the newly instituted quantum safe schemes.

It could t= ake a staggered approach to first freeze funds that are susceptible to long= -range attacks such as those in P2PK scripts or those that exposed their pu= blic keys due to previously re-using addresses, but I expect the additional= complexity would drive further controversy.

How long should the gra= ce period be in order to give the ecosystem time to upgrade? I'd say a mini= mum of 1 year for software wallets to upgrade. We can only hope that hardwa= re wallet manufacturers are able to implement post quantum cryptography on = their existing hardware with only a firmware update.

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. Though if you exclude dust UTXOs= you could probably get 95% of BTC value migrated in 1 month. Of course thi= s is a highly optimistic situation where everyone is completely focused on = migrations - in reality it will take far longer.

Regardless, I'd thi= nk that in order to reasonably uphold Bitcoin's conservatism it would be pr= eferable to allow a 4 year migration window. In the meantime, mining pools = could coordinate emergency soft forking logic such that if quantum attacker= s materialized, they could accelerate the countdown to the quantum vulnerab= le funds burn.

Random Tangential BenefitsOn the plus side, burning all quantum vulnerable bitcoin would allow us to= prune all of those UTXOs out of the UTXO set, which would also clean up a = lot of dust. Dust UTXOs are a bit of an annoyance and there has even been a= recent proposal for how to incentivize cleaning them up.

We should = also expect that incentivizing migration of the entire UTXO set will create= substantial demand for block space that will sustain a fee market for a fa= irly lengthy amount of time.

In Summary
W= hile the moral quandary of violating any of Bitcoin's inviolable properties= can make this a very complex issue to discuss, the game theory and incenti= ves between burning vulnerable coins versus allowing them to be claimed by = entities with quantum supremacy appears to be a much simpler issue.

= I, for one, am not interested in rewarding quantum capable entities by infl= ating the circulating money supply just because some people lost their keys= long ago and some laggards are not upgrading their bitcoin wallet's securi= ty.

We can hope that this scenario never comes to pass, but hope is = not a strategy.

I welcome your feedback upon any of the above points= , and contribution of any arguments I failed to consider.

--
You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+...@googlegroups.com.=
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CA= DL_X_cF%3DUKVa7CitXReMq8nA_4RadCF%3D%3DkU4YG%2B0GYN97P6hQ%40mail.gmail.com<= /a>.

--
You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+...@googlegroups.com.=
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAGXD5f1= eTwqMAkxzdJOup3syR%2B5UjrkAaHroBJT0HQw5FA2_YQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.googl= e.com/d/msgid/bitcoindev/3fec8fc3-efa1-49c5-8bab-592e0138d31dn%40googlegrou= ps.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/9564E= AA8-807A-4448-8A92-FEEAC92D4709%40gmail.com.
--Apple-Mail-37F15B76-2010-41E5-A69E-9A4882AC6933--