path: root/8f/a1a9bcac3eb484bf3b1113669043f1672b9546

Delivery-date: Tue, 12 Aug 2025 02:02:33 -0700
Received: from mail-oa1-f58.google.com ([209.85.160.58])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBCL7RHHJZYJBBGUG5TCAMGQEMTWS7KQ@googlegroups.com>)
	id 1ulkto-0007wt-6x
	for bitcoindev@gnusha.org; Tue, 12 Aug 2025 02:02:33 -0700
Received: by mail-oa1-f58.google.com with SMTP id 586e51a60fabf-2e92a214e2esf2448746fac.1
        for <bitcoindev@gnusha.org>; Tue, 12 Aug 2025 02:02:27 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1754989342; cv=pass;
        d=google.com; s=arc-20240605;
        b=Cfj0iT9ZQl653UWUMtHqrzfJDoRObxUnAL00qbtor9lM8s74xf7XirfOkJy7DyucRC
         zYU3/P91X3cWBlNNv2J779FzE+o3GdVxgjfs1pH2vjUBgAFY9iUzXrYZEUhUcsyJkKeh
         j0mUClt7wNqCmWyvHvmoyOVdyk23J3fRG/gkIg/jnflLXCvu7qBJZNN0xIXLXXE+RFpm
         majTi0VxZYpv4htj9gteK/K+ZZfnzCThZSGZLd0HdS1fNorsRBasF0xgjsAA3Tt1P9ro
         exWvkViWWYWM3wDadEwwVsPKa3fEoooltVBXafBnfkrKnH1TUXPo2thPU45Pz/jEGioB
         Qriw==
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:reply-to:mime-version:feedback-id
         :references:in-reply-to:message-id:subject:cc:from:to:date
         :dkim-signature;
        bh=Zir+KfZC40fbiHhwcT5frJdQEV+IxWt3REUQkMAswJc=;
        fh=Apt0cyh/6AZOEUmVLSZ5fupgnjun8Ga2LF2uyZfJA6A=;
        b=FWn3Xo3Zmr58kGG6aRL7KIGQ56e4DwcYyek1G/PH668IfuhyxGikWEL88afxaZZQU1
         cvoEKo4zIMaX35Uj7Er0rCEVNe7hu22HuKbeMgEVg6NOPpHrFXG5MATNUlCdZc5KWqFB
         zgxUu/nq9e7XHcBomI4fHEch2XSggh4qTHnK+CiXAz5aXSLPBQtFJmHgKJYq36mBMqct
         osMYoffWu5n7EdmEheM+JkXnFvxROtv2xuvUM+f20mcaO2wVoHtjU0qx0JlEorlaRSZ1
         90F4QfXMb8ex/A0tX1MdrEYOcDIYe8dfr7ALTAC9uS9CmAGFDtSHY7QNPhDG/7vDyglP
         R5sA==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@proton.me header.s=protonmail header.b=J9ltySwm;
       spf=pass (google.com: domain of conduition@proton.me designates 185.70.43.22 as permitted sender) smtp.mailfrom=conduition@proton.me;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1754989342; x=1755594142; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:reply-to
         :x-original-authentication-results:x-original-sender:mime-version
         :feedback-id:references:in-reply-to:message-id:subject:cc:from:to
         :date:from:to:cc:subject:date:message-id:reply-to;
        bh=Zir+KfZC40fbiHhwcT5frJdQEV+IxWt3REUQkMAswJc=;
        b=YgrjxhoOYKCcOeJLUt/uPD0o6mTAa1vzq0UTgltv6jRYJ2DOqzmWdRy2K8pfzyAPw9
         QBQqs0cL3vlEGZaI8fHX9YFb7rzToXessfwPZXCU2UaBjkkUt1zW1XM1jqEFzlxlVw83
         zG/+LxHFNAsVCEpw+WTW28Fi7uEvaF3nszkLUCOnulgnpPB6m2+KivpECIhXeCEZmPWx
         vEw4oQ5vRvnlKhIHwmgOdhNBqZwINCF1kghZC3uNtxcCIJIzqORgTBuE1JjLeNnWH68Q
         t20cl9rGUnTuMk7J7Ju3rXQ0DnIwaPQX1KrF9P0rJXqXJgG/NMUm6hHwulT+9s8BtRya
         rBPA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1754989342; x=1755594142;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:reply-to
         :x-original-authentication-results:x-original-sender:mime-version
         :feedback-id:references:in-reply-to:message-id:subject:cc:from:to
         :date:x-beenthere:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Zir+KfZC40fbiHhwcT5frJdQEV+IxWt3REUQkMAswJc=;
        b=R/ekhOr1LhXQVcwyo+fQRKn3VLb+BkagOS+0NEtGkn8r2a0lbt2UrgDGSs478yITJO
         l+jT0hzAB6C6mZxk9TjB5YJVsi4Rjfepjo4KUrVMyPMdVGMs7BURHXC5xF6V/6R+l3nF
         zamEFrHtUveV9sa5o8k6wQclueK5x7CUzyhgqV7Ht/F5Sh3HgqEwgwDXQmLj6AZ/w11H
         WmOGjG7CSyRP9RaWa+wjjJQHaE6gwrjHlzSjX7bG5+aLjjQ1+3qoSUuAAujW5/87CnMZ
         VeDAvzNR88hCv1OCzyOprJUow6Erq4OwBjqbANzXsiB8TeuEWK1OQLzK/mzD+NXo6sCq
         h9CQ==
X-Forwarded-Encrypted: i=2; AJvYcCX2Ke4ojBwS9oHTTa4y2w+7d7kkvAZ16Yp4Stt/LxB/Ed9s/E2fg4J9/piX0248BhEKIPMbiCZ+5p3x@gnusha.org
X-Gm-Message-State: AOJu0YzujxOpCnDtPcG2Px6SJeUQk2KinIrKUNJi20KsGJxTwQJ/9jF4
	vXGDcAQ0cTZRr3KKo+X+nFiSZBTMYxoCqecD/ERCCCLGPYw1rF5UGqXX
X-Google-Smtp-Source: AGHT+IFyY+cXe3wNR9jGT1F80xUJKYr92XeshgcByL/Fu03ixvEV4pTjRqysEuG2GASjW/tK9ciJSg==
X-Received: by 2002:a05:6870:9e94:b0:301:a823:9cd1 with SMTP id 586e51a60fabf-30c95051dd8mr1664646fac.22.1754989341467;
        Tue, 12 Aug 2025 02:02:21 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZcJEuJ6MFgepUHoEyNns+jKF18AAXW3zvYNZF1rX5qJaA==
Received: by 2002:a05:6871:a190:b0:30b:bc0f:66ba with SMTP id
 586e51a60fabf-30bfe391363ls1212776fac.0.-pod-prod-04-us; Tue, 12 Aug 2025
 02:02:18 -0700 (PDT)
X-Forwarded-Encrypted: i=2; AJvYcCUz9rFqHwGfSv4XkMNkjTqVMStmhISBp5w33NFLJq73ggbteNkxEhJwB8CIdPLr9ZOZr2dL4tMHz1Sw@googlegroups.com
X-Received: by 2002:a05:6808:130e:b0:41b:eb59:7c5b with SMTP id 5614622812f47-435c91cebf8mr1401014b6e.25.1754989338192;
        Tue, 12 Aug 2025 02:02:18 -0700 (PDT)
Received: by 2002:a05:6504:9813:b0:2bc:427:fa2 with SMTP id a1c4a302cd1d6-2bf2ff93173msc7a;
        Sat, 9 Aug 2025 12:53:39 -0700 (PDT)
X-Forwarded-Encrypted: i=2; AJvYcCX1RYAi047cxHeo7JAFrwXd/cxrItNQYZUB3v2zR6V/doZnDdmKt2fhBrJ/hdf5xsTgK8NuxDHNBQGB@googlegroups.com
X-Received: by 2002:a05:6512:24d9:10b0:55c:caf2:683a with SMTP id 2adb3069b0e04-55ccaf26a34mr401200e87.56.1754769215208;
        Sat, 09 Aug 2025 12:53:35 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1754769215; cv=none;
        d=google.com; s=arc-20240605;
        b=BdxHmewWd6lEL8mLOmtg5AAKMHshfA2vbdxIeHIVjHmmJArEyZhu1J/75Uw9jxOtqh
         m1ba7UrZMmflyqZOglqShe0GyZbnCO1eUhJyhNqVtWiyGhPaOS02ArD+2qujR6oWuEKn
         NMsircGrXgocDaZ6Qa+Y0j238Hx7TidlSkdyJ7RmOO2QJDFhYsmI22KZARTnxTa/eq4F
         CGweBOAbY212ee1CjVpEmUXGexyDptgZKI5tb7RNHHXcteEs1rdmePvKSU5Jcma69xkS
         267tFa+UiIE4Zp9l3PDW5FIYl9f1BhKmxxaq6ZKIp89ZutCqoOzPWiSJvfhWGIOXlSvy
         7yGQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=mime-version:feedback-id:references:in-reply-to:message-id:subject
         :cc:from:to:date:dkim-signature;
        bh=jo9bJRRymehd9nvG83TR3Dkpi5S5P6OJByRwXjsdiMU=;
        fh=t6RoFpU5qWR8JrV3dkWkoGwt3dL5fndvQ5k6y2MpZ/Q=;
        b=GdvVOShJSgx1NMLNWRCqhzjeOZpLEx5yUGPyLOHfaUwN8/0kOEhXXa1pYPjmunBEMT
         Qgk9bTcdv7eRQBfQDiCBru/SgMy04zw3rLoDM8U1fSRxzTUkolAlc61Oar3zP0DUrB+Y
         rIQNDOnvvISI66CFA1bQ/6XlUnXtszPYI+MyK8Rki/nEsELqqqWtQlrUumA4Gy+oin52
         3t4BluRk7EzbXruCJRBEOi84sh3oeWz5rARa+ltDzklUcsfup30dqb3jc8DNgb/WlPqz
         CGJbD/53dK3fh3JMS3hJi6G5K385MYx4/T7PdFk3od6H27rcjaFy8toZeMvo32JEcIFG
         gxkA==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@proton.me header.s=protonmail header.b=J9ltySwm;
       spf=pass (google.com: domain of conduition@proton.me designates 185.70.43.22 as permitted sender) smtp.mailfrom=conduition@proton.me;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me
Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch. [185.70.43.22])
        by gmr-mx.google.com with ESMTPS id 2adb3069b0e04-55b9f778a88si448955e87.1.2025.08.09.12.53.34
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Sat, 09 Aug 2025 12:53:35 -0700 (PDT)
Received-SPF: pass (google.com: domain of conduition@proton.me designates 185.70.43.22 as permitted sender) client-ip=185.70.43.22;
Date: Sat, 09 Aug 2025 19:53:28 +0000
To: conduition <conduition@proton.me>
From: "'conduition' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
Cc: Nagaev Boris <bnagaev@gmail.com>, Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: Against Allowing Quantum Recovery of Bitcoin
Message-ID: <4wCyWdzfJTskjdcX3WSpbV53KAhAc_CwqS-65RAA9cD1lcttvdFgG4LPY1U8YRlcJrPJMAc_aR_d4uLiUxMypdxmoMAhN5WDlCByp1mWHnM=@proton.me>
In-Reply-To: <YX1Q8oL5phYHC8fM_m4aHakglTjz1RYlv8k7tGgbq9Rx_jx6BFmG6Y8uA7Vrma0fOX3kCTD30k0PCUGeBX_bnglN5GWCZdGABxKDOjvt_bA=@proton.me>
References: <CADL_X_cF=UKVa7CitXReMq8nA_4RadCF==kU4YG+0GYN97P6hQ@mail.gmail.com> <QMJUGIIUkotWOf1_QUMxTyaODEcZb9lgrw4ArvSJFA4SBpEaDNOzOOGdlULh1FNwarSZ01aMaMGI0loR049LM9OUv6mAsvNjG602w5pCpyE=@proton.me> <c56b179f-2753-4f1c-80a4-14969e737d37n@googlegroups.com> <b47CJPe1A4uDA93IAB6zaZ3UXh4AdcKo6TC1X5tVK_dCWqEfcF5iNLm9p-1dihgOvIWhfHo3pFfukVHa9-6_-t370vE9NQKHwzAvNtzVL1o=@proton.me> <CAFC_Vt4O37VzVEROquU6obyWhD73GkPvwMXYkiVVz-C8H_-bew@mail.gmail.com> <0FMBd3qAkpUT93zRc-SV_W7J3IA9uVjVQf5MEDkGXUoyFG_iS8jgLqhs5Pzw5T5zIZ9dL79KSS24ZlYLWOejrALx0Waa6L_oACBkNGnlWlI=@proton.me> <CAFC_Vt5VXtchj1nkMK0=Ozw4yX5L1YJ92a3dAzOMkXk4pdxwYQ@mail.gmail.com> <1_SQdVeoXT3nPyNf-k-kcrcUunu8EwV788dGA3u054NlldCDZAROTMJPgMOFJ5Amf3mEu_E9xkZXouCOavpewxfwWt8KlMm74-ySRVWL5A0=@proton.me> <CAFC_Vt7a1O9vCdycRtUmTAQyL=ifZAZt3Wzx-YBTQ1cKyJq55w@mail.gmail.com> <YX1Q8oL5phYHC8fM_m4aHakglTjz1RYlv8k7tGgbq9Rx_jx6BFmG6Y8uA7Vrma0fOX3kCTD30k0PCUGeBX_bnglN5GWCZdGABxKDOjvt_bA=@proton.me>
Feedback-ID: 72003692:user:proton
X-Pm-Message-ID: b303d401ea698b1f99be202dfd7cdd1dbba41e68
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------90797aa7ec662f091cb1e5e00eda6a4faf92cd16f8c025d9a4feae5f0ea6cd9f"; charset=utf-8
X-Original-Sender: conduition@proton.me
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@proton.me header.s=protonmail header.b=J9ltySwm;       spf=pass
 (google.com: domain of conduition@proton.me designates 185.70.43.22 as
 permitted sender) smtp.mailfrom=conduition@proton.me;       dmarc=pass
 (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me
X-Original-From: conduition <conduition@proton.me>
Reply-To: conduition <conduition@proton.me>
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: -1.0 (-)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------90797aa7ec662f091cb1e5e00eda6a4faf92cd16f8c025d9a4feae5f0ea6cd9f
Content-Type: multipart/mixed;boundary=---------------------de041f8d3fac70083a019e520307bbeb

-----------------------de041f8d3fac70083a019e520307bbeb
Content-Type: multipart/alternative;boundary=---------------------7359e0b8461b9366496a00df1ae9812f

-----------------------7359e0b8461b9366496a00df1ae9812f
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

I remember what i was talking about a few weeks back.

I was envisioning that all the pubkeys would be merged together across all =
inputs, but this would break the total ordering on commitments. Given a rev=
eal TX, the validator wouldn't know if the commitment being opened was the =
earliest, because a miner could censor a reveal transaction for a block or =
two and insert a different one with a different set of inputs, resulting in=
 a different HMAC key.=C2=A0

This is also the reason why my "witness hashing" idea won't work. The witne=
ss stack can be changed by a Quantum adversary after the reveal TX is opene=
d, by inverting one of the pubkeys and making a fresh new signature. This c=
hanges the HMAC key that would've been used in an authentic commitment, and=
 validators won't be able to check the commitment ordering. So we do still =
need to HMAC sign the TXID, and we have to do it on a per-input basis.

We can merge pubkeys into a single HMAC key as you suggested Boris, as long=
 as we merge only the pubkeys within a single locking script of a specific =
reveal TX input. This way the HMAC key that we reveal to open any commitmen=
t is always the same, regardless of who tries to spend the revealed input. =
Taproot would be an exception since a P2TR address can have many possible l=
ocking scripts with different sets of pubkeys, but a quantum attacker proba=
bly won't be able to find them without inverting SHA256.

This means the reveal TX validator can find a clean ordering of past commit=
ments for that reveal, and this thwarts any attacks from miners that rely o=
n censoring the reveal TX.

regards,
conduition
On Saturday, August 9th, 2025 at 10:58 AM, 'conduition' via Bitcoin Develop=
ment Mailing List <bitcoindev@googlegroups.com> wrote:

> Hey Boris,
>=20

>=20

> > I propose to simplify this by using just one MAC with all the pubkeys a=
s a single key. If you know why this is a bad idea, please share.
>=20

>=20

> I think I forgot my train of thought here on why this allowed miner attac=
k, probably should've written it down. Maybe i was thinking of merging indi=
vidual per-key MACs together with a hash... Anyway, your suggestion of HMAC=
(key=3D[k1, k2, k3...], msg=3Dtxid) seems like a reasonable way of compress=
ing the scheme. If I think of any way to break that I'll let you know.=C2=
=A0
>=20

> But perhaps there is an even better option. What if, rather than publishi=
ng a commitment to the EC keys (which is basically a commitment to the lock=
ing script), we publish a commitment to the witnesses that will be used to =
spend the UTXO?=C2=A0
>=20

> The witness stack always includes at least one EC signature, which is bou=
nd to both the transaction and the pubkey by OP_CHECKSIG. We are essentiall=
y pre-annoucning: "I will spend this UTXO using this set of signatures".
>=20

> Then we could get away with a 68 byte commitment made of two hashes and a=
 u32: `(utxo, witness_hash)`. We no longer need to publish the TXID in the =
commitment, because `witness_hash` indirectly commits to it.=C2=A0You'd com=
pute the witness hash by simply concatenating and hashing all the witness d=
ata for each input in consensus order.
>=20

> This is all for unexposed addresses, btw. For UTXOs with exposed pubkeys,=
 you could mix a BIP32 parent xpriv into the witness hash somehow, and woul=
d need to publish the xpriv in the reveal TX.
>=20

>=20

>=20

> regards,
> conduition
> On Tuesday, July 29th, 2025 at 1:24 AM, Nagaev Boris <bnagaev@gmail.com> =
wrote:
>=20

> > Hi Conduition,
> >=20

> > On Mon, Jul 28, 2025 at 9:24=E2=80=AFPM conduition <conduition@proton.m=
e> wrote:
> >=20

> > > Hi Boris,
> > >=20

> > >=20

> > > > We can't let multiple commits per UTXO be valid. Remember the origi=
nal problem you posted a couple of messages ago: miners can collude and del=
ay reveal transaction confirmation, so we need to make sure that the commit=
ment of this reveal tx is the first valid commitment for this UTXO
> > >=20

> > >=20

> > > Ah i see what you mean now. Your suggestion of requiring one and only=
 one hardened derivation step is probably the easiest option to fix that. T=
hat way, for any set of EC keys, there exists at most one matching parent x=
priv. Revealing that xpriv doesn't give observers any valid alternative HMA=
C keys.
> > >=20

> > >=20

> > > > It doesn't have to be in EC recovery soft fork, we can enable it in=
 phase B, since it is very simple and we have plenty of time to implement a=
nd test it. Also it doesn't block anyone and therefore it is much more like=
ly to be adopted than the original approach (block first, recover later, ma=
ybe)
> > >=20

> > >=20

> > > That won't work - If you deploy phase B (restricting EC outputs) with=
 bare pubkey commit/reveal without also supporting BIP32 commit/reveal for =
exposed pubkeys, then adding BIP32 commit/reveal later will be a hard fork.=
 You'd be relaxing consensus rules to allow spending of outputs with expose=
d pubkeys.
> >=20

> >=20

> > Both commit-reveal schemes would be deployed simultaneously, but the BI=
P32 scheme will function forever for all the coins and the pubkey scheme wi=
ll pause for old coins with exposed pubkeys after let's say 5 years for ano=
ther 10 years. For new coins both schemes will work forever.
> >=20

> > For example (exact years are just for illustration purposes):
> > 2025-2030 current rules work
> > 2030-2035 both commit-reveal schemes work for all coins, but it is impo=
ssible to spend from EC addresses without using a commit-reveal scheme anym=
ore. Both schemes are deployed as a softfork, so transactions are still val=
id from the point of view of old nodes
> > 2035-2045 the pubkey based commit-reveal scheme stops working for exist=
ing coins with exposed pubkeys. BIP32 scheme works and the pubkey scheme wo=
rks for any new coins (created after 2035). This is the first real confisca=
tory event, since the pubkey scheme would be the only scheme available for =
some coins in 2035.
> > 2045-inf the pubkey based scheme is revived
> >=20

> > The whole timeline is applied (in block heights, not years) as a single=
 fork in 2030. Another fork until 2045 can delay pubkey scheme revival. Thi=
s is just needed to avoid permanent freeze after which it would be impossib=
le to recover the coins without a hardfork.
> >=20

> > > > - array of MACs in the order of EC operations in the witness script
> > >=20

> > >=20

> > > Makes sense. At first i was going to suggest to merge the pubkeys tog=
ether into one single MAC, but that'd create opportunity for miner collusio=
n. You would indeed need one commitment hash per EC operation for watertigh=
t security.
> >=20

> >=20

> > One more caveat. We should include all the keys exposed in signature or=
 witness of UTXO in the reveal transaction. We can't put the used EC keys o=
nly. Imagine a 1/2 traditional multisig. Witness has two public keys, but o=
nly one signature. We should demand both keys in the commitment, because ot=
herwise a quantum attacker may see the reveal transaction and make a new re=
veal transaction, using another EC key of the multisig. The attacker would =
create a new commit transaction with that malicious reveal TXID and "sign" =
it with another public key (the one not used originally). A validator would=
 accept such a new pair of commit and reveal transactions, since they will =
also check MAC using the used EC key only, not all the keys. A validator wo=
uld consider a real commitment invalid and would think that the attacker's =
commitment is the first valid one. That is why it is important to put all E=
C pubkeys mentioned in witness (or traditional signature) of the reveal tra=
nsaction, not just used onces, to prevent such "hijacking".
> >=20

> > Actually, I didn't think about merging keys for MAC. Thanks for sharing=
 the idea! Can you elaborate why this is not possible, please? Let's say th=
e UTXO has 3 different keys in 1/3 traditional multisig. Can't we just comb=
ine them somehow, e.g. XOR or hash-and-XOR and use the result as a key for =
MAC? An attacker doesn't control these values and he doesn't control the sc=
ript (unless multiple reveal transactions with different tapleaves were pub=
lished, which is not allowed in such schemes). So until the reveal transact=
ion is published the attacker can't forge commits. And once the reveal tx i=
s published it doesn't make sense to forge, because it won't be the first v=
alid commit. I don't see any vulnerability which is created by merging keys=
 for MAC.
> >=20

> > > For single-party BIP32 commit/reveal on the other hand, you'd probabl=
y never need more than 1 MAC per commitment, since the xpriv would probably=
 cover every EC operation in the reveal TX (even across multiple UTXOs), an=
d any given pubkey has at most one matching parent xpriv (if hardening is d=
one only once).
> >=20

> >=20

> > Yes. Note that in the BIP32 variant the reveal transaction has to inclu=
de all derivation paths though, for every pubkey that is mentioned in the s=
cript.
> >=20

> > > To confirm, when validating a commitment that contains multiple MACs,=
 the validator would need to assert that every MAC is the earliest valid MA=
C, right? If even one pubkey was exposed and committed earlier, it'd render=
 the whole reveal TX invalid.
> >=20

> >=20

> > When validating a reveal transaction, a validator first collects all EC=
 pubkeys from the script; not only used keys, but all - see above why. Then=
 the validator loads all the commitments that were posted for that UTXO. Co=
mmitments may have this TXID or different TXID; the validator has to load a=
ll regardless of TXID. Then the validator goes through all the commitments =
and checks MACs. If the number of MACs doesn't match the number of EC pubke=
ys - exclude the commitment. Otherwise go through MACs and pubkeys one by o=
ne and check each MAC against the corresponding key. Cleartext for MAC is t=
he TXID from that commitment. If any MAC doesn't verify - exclude the commi=
tment. The remaining commitments passing these checks are valid. Check the =
first valid commitment. If it has TXID not matching TXID of the reveal tran=
saction - fail the reveal tx validation.
> >=20

> > An attacker can't copy MACs because they are bound to TXID of the origi=
nal commitment and that TXID is legit. So we don't worry if we see one vali=
d MAC in another commitment. To make the whole commitment valid an attacker=
 has to copy-paste the whole commitment, which doesn't change anything - th=
e list of commitments would have two identical valid commitments.
> >=20

> > I propose to simplify this by using just one MAC with all the pubkeys a=
s a single key. If you know why this is a bad idea, please share.
> >=20

> > Best,
> > Boris
> >=20

> >=20

> >=20

> >=20

> > > regards,
> > > conduition
> > > On Monday, July 28th, 2025 at 5:07 PM, Nagaev Boris <bnagaev@gmail.co=
m> wrote:
> > >=20

> > > > Hey Conduition,
> > > >=20

> > > > On Mon, Jul 28, 2025 at 6:38=E2=80=AFPM conduition <conduition@prot=
on.me> wrote:
> > > >=20

> > > > > Hey Boris,
> > > > >=20

> > > > > I've been doing more research into ZK-STARK solutions, and the mo=
re i read, the more I am warming to the idea of BIP32 commit/reveal as a re=
covery mechanism. The smallest concrete zk-STARK proofs I could find were h=
undreds of kilobytes for even something as simple as a SHA512 hash preimage=
. BIP32 proofs would need that, plus secp256k1 arithmetic.
> > > >=20

> > > >=20

> > > > AFAIK, the size of a STARK is a polylog of the evaluation trace. So=
 even if a single SHA512 evaluation costs several hundreds of kilobytes, ma=
ybe we can fit many signatures into a single STARK, since logarithm grows v=
ery slowly. Maybe even more than we have now. We may have a single STARK pe=
r block which validates all the stuff: recovery and PQ signatures. However =
I'm not an expert in STARKs, just starting to learn them. But I hope STARKs=
 are a real thing!
> > > >=20

> > > > > > We only need a symmetric equivalent of a digital signature (i.e=
. MAC) and a secure hash function. This is very exciting! The scheme can fu=
nction as a backup plan in case we don't find a way to scale regular post-q=
uantum signatures. Imagine the future in which we use expensive SPHINCS+ si=
gnatures for time-sensitive stuff and a cheap commit-reveal scheme for slow=
 transactions.
> > > > >=20

> > > > >=20

> > > > > Don't get too excited - Commit/reveal protocols on bitcoin presup=
pose the availability of a post-quantum signature scheme. Otherwise, how do=
 you publish the commitment TX securely? The commitment phase itself is a p=
ublished BTC transaction, and if that TX is secured via EC signatures, then=
 its inputs could be swiped by a fast CRQC.
> > > >=20

> > > >=20

> > > > I understand :)
> > > >=20

> > > > But I'm happy that at least we have secured one safe and affordable=
 way to use Bitcoin in the post-quantum era: using the commit-reveal scheme=
 and PQ to send commit transactions. Commits can be batched in a single tra=
nsaction. Everyone having PQ funds could run a small business publishing co=
mmits for other people for a fee. Not an ideal world, but it is functional =
and scales without a block size increase. Having a way to compress PQ signa=
tures (e.g. STARK) would be cooler, but the commit-reveal scheme is a stron=
g plan B in case something goes wrong with that approach.
> > > >=20

> > > > > > We need to ensure that the scheme accepts only a single xpriv+p=
ath value. If there are multiple combinations possible (i.e. starting from =
different levels of derivation), then a validator wouldn't be able to deter=
mine if a commit is valid afterwards.
> > > > >=20

> > > > >=20

> > > > >=20

> > > > > I'm not sure I understand the problem... Wouldn't this just mean =
that there can be more than one valid commitment for the same UTXO? That's =
always going to be possible because the owner could commit to more than one=
 reveal transaction. We can't verify commitments for reveal TXs which are n=
ever published. Which is fine - validators just care whether the sender kne=
w a valid parent xpriv before the reveal TX was published.
> > > >=20

> > > >=20

> > > > We can't let multiple commits per UTXO be valid. Remember the origi=
nal problem you posted a couple of messages ago: miners can collude and del=
ay reveal transaction confirmation, so we need to make sure that the commit=
ment of this reveal tx is the first valid commitment for this UTXO. How can=
 a validator verify other commitments posted for the UTXO? They need to kno=
w the key used for MAC to check it. If the MAC key is not fixed per UTXO, t=
his doesn't work: we can't check whether other commitments are valid, so we=
 can't guarantee that the commitments of this reveal tx comes from the owne=
r, not from a collusion of malicious miners who delayed the legitimate reve=
al transaction and made another commit tx using the private data from legit=
imate reveal tx.
> > > >=20

> > > > > Now that I think about it, we safely can omit the bip32 key paths=
 from the HMAC commitment. They serve no purpose there.
> > > >=20

> > > >=20

> > > > Yes, we can use the latest input of SHA512 during BIP32 key derivat=
ion as a MAC key. The reveal tx will have both the preimage and the BIP 32 =
path that should lead to the pubkey.
> > > >=20

> > > > > > Coins whose private key is not a child of BIP32. One important =
instance is MuSig2 coins.
> > > > >=20

> > > > >=20

> > > > > Also FROST keys, ECDSA threshold MPC keys, paper wallets, and man=
y others. I'm really not sure how we'd handle these. The lazy dev inside me=
 wants to ignore them and focus on BIP32 wallets as that probably will make=
 up the bulk volume of coins affected by an EC freeze.
> > > > >=20

> > > > > MuSig is an interesting special case, because the aggregation of =
the group key is actually a quantum resistant one-way function. More concre=
tely, given the musig group key `X =3D H(L, A)*A + H(L, B)*B` then a QC can=
not practically compute a valid key set `L =3D [A, B]`. So you could make a=
 commit/reveal scheme for MuSig keys by committing to (and then revealing) =
the key set `L`. Nodes verify the group key `X` was computed correctly from=
 `L`. We'd have to assume that key set `L` is not available to a quantum at=
tacker. No secret key sharing is needed for this.
> > > > >=20

> > > > > FROST is not so fortunate. A FROST key is just the constant term =
of a polynomial. Any quantum attacker could invert a public key, and then f=
orge an arbitrary polynomial with that key as its constant term.
> > > > >=20

> > > > > I wouldn't worry too much about untrusting multisig groups though=
 - such wallets are usually actively managed, so the parties involved would=
 likely be active enough to migrate their coins to post-quantum addresses b=
efore any EC-restricting soft forks occur. Then again, this is just an opin=
ion, no hard data to work with here.
> > > >=20

> > > >=20

> > > > I guess inheritance schemes may use MuSig2 in a tap leaf with a tim=
elock. MuSig2 is used, because it is more efficient; the timelock is just a=
 protection. However if we keep the pubkey commit-reveal scheme for a while=
 (see below), we won't need a separate scheme for MuSig2.
> > > >=20

> > > > > Ancient paper wallet holders on the other hand are much more at r=
isk, since these keys were often generated without BIP39 or BIP32. This mig=
ht be one reason why allowing commit/reveal with bare pubkeys could be bene=
ficial, but IDK if it outweighs the complexity costs.
> > > > >=20

> > > > >=20

> > > > > > Some xpubs may have too many coins to sweep in a single transac=
tion.
> > > > >=20

> > > > >=20

> > > > > This should be a pretty rare edgecase - but even in those cases, =
as you say, we can work around it by splitting up the reveal TX into multip=
le transactions and committing to each of them. Then wait a few blocks, and=
 publish all reveal TXs at once.
> > > > >=20

> > > > >=20

> > > > > > Note that the BIP32 scheme requires attaching additional data (=
xprivs + derivation paths) to a reveal transaction. ... We can make another=
 Merkle tree similar to Segwit and put it there.
> > > > >=20

> > > > >=20

> > > > > Same would be true of any PICNIC or zk-STARK based solution. It's=
 unavoidable if we want an EC recovery soft fork.
> > > >=20

> > > >=20

> > > > It can be avoided in my original scheme using pubkey as MAC key. In=
 this scheme, the reveal tx is just a regular transaction, no extra data ne=
eded. Everything needed to validate the commitment (the pubkey) is in the r=
eveal transaction itself. It makes the scheme compatible with any modern tr=
ansaction types and saves block space. The only downside is that it is not =
secure in case the pubkey leaks.
> > > >=20

> > > > It doesn't have to be in EC recovery soft fork, we can enable it in=
 phase B, since it is very simple and we have plenty of time to implement a=
nd test it. Also it doesn't block anyone and therefore it is much more like=
ly to be adopted than the original approach (block first, recover later, ma=
ybe). At the same time the public key commit-reveal scheme saves a lot of c=
oins in case of a quantum emergency, so it is definitely much better than d=
oing nothing. If a person advocates to block vulnerable coins because of th=
e price effect, they should support this scheme too, because it reduces dra=
matically the amount of vulnerable coins. Maybe this is the focal point?
> > > >=20

> > > >=20

> > > > BTW in both schemes we should think abouts UTXOs which have multipl=
e public keys and signatures: traditional multisigs, some smart scripts. Al=
l EC signatures used in the script must have a commitment. But how to find =
which commitment is for which pubkey? Remember we should find all valid com=
mitments and check that this one is the first... Just check all against all=
? It is O(N^2), where N is the number of EC signatures per witness. I propo=
se to change the format of the commitment OP_RETURN to this:
> > > >=20

> > > > - UTXO
> > > > - TXID
> > > > - array of MACs in the order of EC operations in the witness script
> > > >=20

> > > > This is also more space efficient, because UTXO and TXID will be th=
e same, only the MAC part is different.
> > > >=20

> > > >=20

> > > > > > Both of them can be provided but the pubkey-based scheme will b=
e blocked for coins whose pubkeys were exposed in the past. All such coins =
can be found once, at the fork time, and future pubkey exposures can be ign=
ored.
> > > > >=20

> > > > >=20

> > > > >=20

> > > > > This scan would miss a lot of exposed pubkeys - xpubs and other p=
ublic keys shared off-chain for high-value wallets would become highly valu=
able commodities that could be sold to quantum attackers. But i guess it is=
 doable. I'm not sure if its benefits outweigh its drawbacks. Basically it'=
s a pick-your-poison choice between (1) allowing QCs to steal from pubkeys =
exposed off-chain, or (2) destroying the coins of paper/brain wallet hodler=
s (or anyone else who didn't use BIP32).
> > > >=20

> > > >=20

> > > > Yes, this is a hard choice. Maybe there is a compromise solution: t=
he pubkey scheme can function for old coins for a limited amount of time. W=
e'll hope that quantum attacks won't happen during that period. It will be =
sufficient for owners of paper wallets to move their funds. Then the pubkey=
 scheme will stay disabled for old coins for 10 years. (Remember my another=
 proposal to replace a permanent block with a long temporary block, this co=
nsideration is applicable here as well.) The BIP32 scheme can be used for s=
uch coins at any time. New coins should be good to use with the pubkey sche=
me, since it would be the responsibility of the coin owner not to expose pu=
blic keys when the quantum threat is high.
> > > >=20

> > > > Best,
> > > > Boris
> > > >=20

> > > > > regards,
> > > > > conduition
> > > > > On Friday, July 25th, 2025 at 7:17 PM, Nagaev Boris <bnagaev@gmai=
l.com> wrote:
> > > > >=20

> > > > > > Hi Conduition,
> > > > > >=20

> > > > > > Thanks for pushing it forward! Interestingly, we don't really n=
eed EC crypto to organize a payment scheme. We only need a symmetric equiva=
lent of a digital signature (i.e. MAC) and a secure hash function. This is =
very exciting! The scheme can function as a backup plan in case we don't fi=
nd a way to scale regular post-quantum signatures. Imagine the future in wh=
ich we use expensive SPHINCS+ signatures for time-sensitive stuff and a che=
ap commit-reveal scheme for slow transactions. We can have a single type of=
 address which supports both types of spending: (1) expensive and fast, (2)=
 cheap and slow.
> > > > > >=20

> > > > > > Switching back to coin recovery, there are a few challenges. I =
have thoughts on how to solve some of them.
> > > > > >=20

> > > > > > 1. We need to ensure that the scheme accepts only a single xpri=
v+path value. If there are multiple combinations possible (i.e. starting fr=
om different levels of derivation), then a validator wouldn't be able to de=
termine if a commit is valid afterwards. Another commit may be valid, but m=
ade with a different xpriv+path input, so MAC won't verify. I think we can =
ensure that xpriv+path is unique by demanding that the path starts with a h=
ardened step (i.e. hashing) and has no other hardened steps.
> > > > > >=20

> > > > > > 2. Coins whose private key is not a child of BIP32. One importa=
nt instance is MuSig2 coins. In MuSig2 several private keys are generated b=
y different parties, probably from different BIP32 parents, but I know of a=
t least one case where completely different approach was chosen for derivat=
ion of a partial key. So there is no single BIP32 parent of MuSig2 addresse=
s. Another obstacle is MAC generation if parties don't trust each other and=
 don't want to share xprivs with each other. Maybe the scheme can be change=
d to pass xpriv through a tagged hash function prior to using it as a key i=
n MAC to address this.
> > > > > >=20

> > > > > > Maybe taproot addresses should have a special approach, because=
 they have a key path spend which is unique among all address types.
> > > > > >=20

> > > > > > 3. Some xpubs may have too many coins to sweep in a single tran=
saction. Since the BIP32 scheme exposes private xpriv in a reveal transacti=
on, to sweep all the coins the owner has to first send all commit transacti=
ons that would cover all future sweep (reveal) transactions. If this is don=
e one by one (commit1-reveal1-commit2-reveal2), then the remaining funds ca=
n be stolen by anyone, since the xpriv of the whole group is exposed.
> > > > > >=20

> > > > > > 4. Note that the BIP32 scheme requires attaching additional dat=
a (xprivs + derivation paths) to a reveal transaction. This is an additiona=
l burden compared with the pubkey scheme. We need to find a place to put th=
e additional data along with the reveal transaction without modifying the T=
XID. That is why we can't put it into OP_RETURN. We can't put it into Witne=
ss, since it would break the signature - we can't do it, if we want it to b=
e a softfork. We can make another Merkle tree similar to Segwit and put it =
there.
> > > > > >=20

> > > > > > It seems that BIP32 and pubkey-based schemes have different tra=
de-offs. Both of them can be provided but the pubkey-based scheme will be b=
locked for coins whose pubkeys were exposed in the past. All such coins can=
 be found once, at the fork time, and future pubkey exposures can be ignore=
d. It would involve reprocessing of all blocks, but this is a solvable tech=
nical issue, e.g. we can give nodes time to precalculate this data before v=
alidation rules change. The logic is that if someone exposed their pubkey i=
n the post-quantum era it's their own fault and it is the same as if they e=
xposed their private key now. So it is justifiable if a quantum attacker ca=
ptures such coins - it is not the business of the network to secure funds i=
n this case.
> > > > > >=20

> > > > > > Best,
> > > > > > Boris
> > > > > >=20

> > > > > > On Fri, Jul 25, 2025 at 2:56=E2=80=AFPM conduition <conduition@=
proton.me> wrote:
> > > > > >=20

> > > > > > > Hi Boris,
> > > > > > >=20

> > > > > > > That sound workable, it's similar to other commit/reveal prot=
ocols. I have no problem with these, they're perfectly valid ways to encumb=
er coins. The only issue I see with your suggested protocol is that it's on=
ly secure when pubkeys are still hidden. A quantum attacker could still com=
mit, reveal, and steal coins from addresses whose pubkeys are already expos=
ed.
> > > > > > >=20

> > > > > > > As Or and Shai's paper has shown, we can fix that by modifyin=
g the scheme to include a BIP32 parent xpriv in the commit TX, rather than =
a bare pubkey. For the sake of simplicity, this should probably be the only=
 commitment method available. If we also allowed bare pubkey commitments, v=
alidating nodes would have to keep track of whether or not an address's pub=
key has been exposed in the past, and determine what types of commit/reveal=
 spends to allow. Using just one method keeps things simpler.
> > > > > > >=20

> > > > > > > So the protocol becomes:
> > > > > > >=20

> > > > > > > The commit_tx includes:
> > > > > > > 1. UTXO
> > > > > > > 2. TXID
> > > > > > > 3. MAC(TXID, key=3Dbip32_xpriv_and_keypaths)
> > > > > > >=20

> > > > > > > The reveal transaction must attach the bip32_xpriv_and_keypat=
hs so validators can check the MAC.
> > > > > > >=20

> > > > > > > Because this exposes the wallet's BIP32 parent key, we have t=
o consider how to handle multi-input transactions, which would migrate the =
wallet's entire set of quantum-vulnerable UTXOs at once. Do i need to make =
a separate commit TX or OP_RETURN output for each UTXO i spend, each commit=
ting to the same TXID? Can i aggregate them together into one commitment so=
mehow with a merkle tree?
> > > > > > >=20

> > > > > > > These are all addressable problems, of course. I just haven't=
 seen them all addressed in one place yet. The solutions are scattered thro=
ugh the mailing list and through papers like Or's. A comprehensive solution=
 needs to have all these edgecases accounted for in a single concise protoc=
ol.
> > > > > > >=20

> > > > > > > regards,
> > > > > > > conduition
> > > > > > >=20

> > > > > > >=20

> > > > > > > On Sunday, July 20th, 2025 at 1:21 PM, Boris Nagaev <bnagaev@=
gmail.com> wrote:
> > > > > > >=20

> > > > > > > > Hi Conduition,
> > > > > > > >=20

> > > > > > > > Let's consider this scheme:
> > > > > > > >=20

> > > > > > > > The commit_tx includes:
> > > > > > > >=20

> > > > > > > > 1.  UTXO
> > > > > > > > 2.  TXID
> > > > > > > > 3.  MAC(TXID, key=3Dpubkey)
> > > > > > > >=20

> > > > > > > > The reveal transaction is just a normal Bitcoin transaction=
.
> > > > > > > >=20

> > > > > > > > Validators would need to maintain a list of commitments per=
 UTXO and only accept a reveal transaction that is the earliest one with a =
valid MAC. A validator of the reveal transaction sees the pubkey and can ve=
rify the MAC. A validator filters the list of commitments, keeping only the=
 valid ones, and then selects the earliest among them. The reveal transacti=
on must match the TXID from the winning commitment.
> > > > > > > >=20

> > > > > > > > If someone tries to steal the coin, they would need to publ=
ish another commit transaction for the same UTXO. But without knowing the p=
ubkey, how can they produce a valid MAC? They can't. All they can do is spa=
m invalid commit transactions, which would have no effect. Even if maliciou=
s miners wait until a legitimate reveal transaction is published and then c=
reate a valid commit transaction, it would not be the earliest valid one. T=
he earliest valid commit would still be the original one.
> > > > > > > >=20

> > > > > > > > The downside is that this scheme requires storing all commi=
tments (valid or not) until the coin is spent. Maybe the list can be compre=
ssed or pruned. Another limitation is that the reveal transaction must be f=
ully constructed at the time of the commit, since its TXID is part of the c=
ommitment. This means the sender cannot adjust the reveal transaction later=
, not even to change the fee or use RBF. That said, maybe the requirement t=
o know the TXID upfront could be relaxed with a different construction.
> > > > > > > >=20

> > > > > > > > Best,
> > > > > > > > Boris
> > > > > > > >=20

> > > > > > > > On Sunday, July 20, 2025 at 2:48:22=E2=80=AFPM UTC-3 condui=
tion wrote:
> > > > > > > >=20

> > > > > > > > > Hi Or,
> > > > > > > > >=20

> > > > > > > > >=20

> > > > > > > > > > Are you asking what happens if the =E2=80=9Creveal=E2=
=80=9D part of a Lifted FawkesCoin is censored by all the miners?
> > > > > > > > > >=20

> > > > > > > > > > Indeed, if all miners collude and decide to censor the =
"reveal" part of the transaction, they will be able to claim the pre-quantu=
m OTXO themselves. But even today, if all (or a majority of) miners collude=
, double-spends are already possible.
> > > > > > > > >=20

> > > > > > > > >=20

> > > > > > > > >=20

> > > > > > > > > Yes, that's my question. There is a big difference betwee=
n this and a double-spend attack.
> > > > > > > > >=20

> > > > > > > > >=20

> > > > > > > > > A double-spend attack involves exercising enormous hashpo=
wer in a 51% attack to orphan an existing block and "undo" a transaction wh=
ich the network previously saw as valid. Any gains from the double-spend at=
tack would be offset by the cost of electricity wasted by mining the new bl=
ock, and by the fees/block-reward lost in the orphaned block. And even then=
, the attacking miners have gained no new bitcoin - They probably only gain=
ed something off-chain, of equivalent value to the coins they double-spent.=
 For instance, they may have deposited into an exchange and converted their=
 double-spent coins into some other currency.
> > > > > > > > >=20

> > > > > > > > >=20

> > > > > > > > > By contrast, censoring a lifted fawkescoin reveal TX requ=
ires no hashpower. It only requires collusion between miners to agree not t=
o mine specific transactions. If they do this, they can swipe the vulnerabl=
e users' bitcoins with no real-world energy expenditure or on-chain losses.
> > > > > > > > >=20

> > > > > > > > > Unless i'm mistaken there, I'd say this property makes Li=
fted FawkesCoin a non-starter.
> > > > > > > > >=20

> > > > > > > > > Restrictive FawkesCoin could be a viable option. It's abo=
ut the same as any other commit/reveal protocol except that you've thought =
out how to rescue funds with exposed pubkeys, by providing a BIP32 parent x=
priv in the reveal TX. This is great but does implicitly require that the c=
oins must be restricted such that the QC attacker can't use a regular EC si=
gnature to steal them first. That requirement would be needed for any proto=
col that rescues UTXOs with exposed pubkeys of course. You're right that th=
is would be simpler to implement than zk-STARKs, so maybe I spoke too soon.
> > > > > > > > >=20

> > > > > > > > > regards,
> > > > > > > > > conduition
> > > > > > > > >=20

> > > > > > > > >=20

> > > > > > > > > On Thursday, July 17th, 2025 at 6:54 AM, Or Sattath <sat.=
..@gmail.com> wrote:
> > > > > > > > >=20

> > > > > > > > > > Dear conduition,
> > > > > > > > > >=20

> > > > > > > > > >=20

> > > > > > > > > > On Tuesday, July 15, 2025 at 4:57:23=E2=80=AFPM UTC+3 c=
onduition wrote:
> > > > > > > > > >=20

> > > > > > > > > > > Thanks for pointing this out Or. For those not famili=
ar with Or's approach, it would share many of the same properties as the fo=
lklore BIP39 zk-STARK approach discussed elsewhere. It uses Picnic in the s=
ame way, to prove (in zero-knowledge) either:
> > > > > > > > > > >=20

> > > > > > > > > > >=20

> > > > > > > > > > > -   (For UTXOs whose pubkeys are exposed) I know a BI=
P39 seed that derives an EC secret key such that hash160(pubkey(ec_secret))=
 =3D=3D <hash>
> > > > > > > > > > > -   (For UTXOs whose pubkeys are still secret) I know=
 a public key such that hash160(pubkey) =3D=3D <hash>
> > > > > > > > > > >    =20

> > > > > > > > > > >=20

> > > > > > > > > > >=20

> > > > > > > > > > > From Or's paper, section 2.5:
> > > > > > > > > > >=20

> > > > > > > > > > >=20

> > > > > > > > > > > > Spending Hashed UTXOs: To spend a hashed UTXO, the =
user signs it with a key-lifted signature (see Section 2.2).
> > > > > > > > > > > >=20

> > > > > > > > > > > > Spending Derived UTXOs: To spend a derived UTXO, th=
e user signs it with a seed-lifted signature (see Section 2.3).
> > > > > > > > > > >=20

> > > > > > > > > > >=20

> > > > > > > > > > >=20

> > > > > > > > > > > I see a couple problems with this. We won't be able t=
o straight-up replace the EC signature with a Picnic signature without a ha=
rd fork. Old Bitcoin clients will still need to see a valid EC signature an=
d verify hash160(pubkey) =3D=3D <hash> by classical re-computation. This ex=
poses the EC pubkey, which would let a QC attacker forge new key-lifted sig=
natures. Thus, sadly, we can't rely on key-lifted signatures.
> > > > > > > > > >=20

> > > > > > > > > > >=20

> > > > > > > > > > >=20

> > > > > > > > > > > That said, we don't always require a hard fork as you=
 note in the paper. It's totally fine to expose the EC signature and pubkey=
 if we also have a way to prove honest derivation of the EC secret key from=
 a seed, and as long as that proof commits to the same transaction. Either =
seed-lifted Picnic signatures or ZK-STARKs could satisfy this. To get soft-=
fork backwards-compatibility, we'd introduce a new transaction data field t=
o carry the proof, much like segwit added the witness data field. Then we r=
equire new clients to reject any EC signatures unless accompanied by this "=
proof-of-seed-derivation". Old clients still see valid EC spend TXs. Soft f=
ork achieved.
> > > > > > > > > > >=20

> > > > > > > > > > > As for the "Lifted FawkesCoin" commit/reveal protocol=
, it has some issues. I think it'd require a hard fork to implement as ther=
e are some properties of the protocol which we can't enforce without relaxi=
ng consensus rules. For example, letting miners claim UTXOs using the post-=
quantum proofs of ownership:
> > > > > > > > > > >=20

> > > > > > > > > > >=20

> > > > > > > > > > > > After the commitment has been posted, the spender h=
as a limited time to post a reveal of the commitment to the blockchain. If =
they fail to do so, the miner can post the proof of ownershipto claim the e=
ntire UTXO, making spam attempts costly
> > > > > > > > > > >=20

> > > > > > > > > > >=20

> > > > > > > > > > >=20

> > > > > > > > > > > This is impossible without relaxing consensus rules o=
n existing UTXOs' script pubkeys. Donating half of a TX's mining fees to an=
 unrelated miner would also need a hard fork:
> > > > > > > > > > >=20

> > > > > > > > > > >=20

> > > > > > > > > > > > The fee paid for including tx is split equally betw=
een the miner who included tx and the miner who included (H(tx))
> > > > > > > > > >=20

> > > > > > > > > > > (though this might be fixable if you modify the proto=
col to instead require direct payment to the address of the miner who mined=
 the H(tx) commitment.)
> > > > > > > > > > >=20

> > > > > > > > > >=20

> > > > > > > > > >=20

> > > > > > > > > > The table on p. 11 here (which is key to understanding =
the different trade-offs of the different methods) indicates which methods =
work as a soft-fork out of the box:
> > > > > > > > > >=20

> > > > > > > > > >=20

> > > > > > > > > > You=E2=80=99re right that Lifted Spending (Section 2.2 =
& 2.3) and Lifted Fawkes-Coin use a hard fork. I suspect that some of the o=
ther methods could potentially be implemented as a soft fork, using various=
 tricks=E2=80=94along the lines of the ideas you=E2=80=99re suggesting. Our=
 rationale was to avoid overcomplicating the paper in order to make it soft=
-fork-compatible.
> > > > > > > > > >=20

> > > > > > > > > > > The other problem is incentives. Why would miners eve=
r mine a Lifted FawkesCoin reveal TX if they could simply wait and claim th=
e pre-quantum UTXO themselves using the proof of ownership? The protocol se=
ems to rely on miners ignoring this opportunity, or at least that the major=
 mining pools won't collude to exploit it.
> > > > > > > > > >=20

> > > > > > > > > >=20

> > > > > > > > > > I=E2=80=99m not sure I fully understand your point. Are=
 you asking what happens if the =E2=80=9Creveal=E2=80=9D part of a Lifted F=
awkesCoin is censored by all the miners?
> > > > > > > > > > Indeed, if all miners collude and decide to censor the =
"reveal" part of the transaction, they will be able to claim the pre-quantu=
m OTXO themselves. But even today, if all (or a majority of) miners collude=
, double-spends are already possible.
> > > > > > > > > > Recall that there's a period of 100 blocks (see p. 20, =
especially step 7) for miners to include the "reveal". It is sufficient for=
 just one honest miner to include the =E2=80=9Creveal=E2=80=9D transaction =
for the issue to be resolved.
> > > > > > > > > >=20

> > > > > > > > > > > The "Restrictive FawkesCoin" protocol would seem to f=
ix this problem though.
> > > > > > > > > >=20

> > > > > > > > > > >=20

> > > > > > > > > > > Finally, the consensus implementation complexity for =
any Fawkescoin implementation would be enormous. There are so many context-=
specific validation steps. The modifications described in section 3.3 and s=
ection 4 only further exacerbate this. Sections 3 thru 5 describe all the v=
arious Fawkescoin protocols and modifications, and in total they are 16 pag=
es long. I don't expect anyone could push that much protocol complexity int=
o consensus in the next decade.
> > > > > > > > > > >=20

> > > > > > > > > > > We're having a hard enough time coming to consensus o=
n the "to freeze or not to freeze" debate, the OP_CTV debate, the OP_CAT de=
bate, etc. I don't see a future where Bitcoin users can even comprehend all=
 the rules and parameters included in the final FawkesCoin-driven protocol,=
 let alone a world where we can all agree on them. We need something simple=
r, more closely aligned with existing consensus rules, that can be implemen=
ted and slotted into existing BIPs and UX neatly.
> > > > > > > > > > >=20

> > > > > > > > > > > Personally I think the answer is to require a proof-o=
f-seed-knowledge to spend any EC-signature-locked UTXO, and to implement it=
 as a soft fork. It'd be expensive, and throughput would be low, but it'd a=
lso be far better than the bikeshed hell which we'd doubtless find ourselve=
s in if we try to push the hulking mass of Fawkescoin into consensus. There=
'd be no complex timelock conditions, no commit/reveal protocols; just one =
new encumbrance added to old EC script pubkeys. Existing wallets can be upg=
raded without any time-sensitive migration procedures.
> > > > > > > > > >=20

> > > > > > > > > >=20

> > > > > > > > > > I agree that the protocols are complicated. We laid out=
 the possible choices, with a special focus on tradeoffs, and I hope that a=
t least one of them (and certainly not all) would get implemented. I think =
that unrestrictive Fawkes Coin is a fairly simple protocol, which doesn't r=
equire any cryptography either the type already used in Bitcoin (hashing fo=
r commit/reveal, and existing digital signatures, and the post-quantum digi=
tal signature which hopefully be decided upon in BIP-360). The only downsid=
e being that users need a post-quantum wallet to pay the fee from. The main=
 advantage of Lifed Fawkes Coin is that the need to pay the fee from a post=
-quantum transaction is removed (at the cost of a more sophisticated protoc=
ol).
> > > > > > > > > >=20

> > > > > > > > > > >=20

> > > > > > > > > > > So then we're left with this question: What primitive=
 should we use to prove seed knowledge: Seed-lifted Picnic signatures or zk=
-STARKs?
> > > > > > > > > >=20

> > > > > > > > > > >=20

> > > > > > > > > > > Cards on the table: I'm not very familiar with Picnic=
, but I am with zk-STARKs. I know zk-STARKs would be very useful to have on=
-hand as a primitive available to consensus, especially in a post-quantum w=
orld. They work for any general computation, with arbitrary private and pub=
lic inputs. They are quick to verify but take a lot of work to produce. The=
y are usually large, measured in tens of kilobytes, but that's similar to P=
icnic.
> > > > > > > > > > >=20

> > > > > > > > > > > Maybe it'd be worthwhile for someone to do some quant=
itative benchmarking and qualitative compare/contrast research between zk-S=
TARKs and Picnic signatures (and maybe other alternatives too?), specifical=
ly for the case of BIP39 seed derivation proofs. I'm especially curious if =
an optimized zk-STARK circuit for BIP39/BIP32 derivation can be designed to=
 reduce proving runtime and proof size. I'd also love to know if Picnic sig=
natures could be reused for other things like rollups, IBD speedup, etc, as=
 I know zk-STARKs could be used for.
> > > > > > > > > > >=20

> > > > > > > > > > > In any case, while I don't think commit/reveal protoc=
ols like Lifted FawkesCoin or its variants are appropriate for a bitcoin co=
nsensus upgrade, I do really appreciate all the research that went into you=
r paper Or. It is a perfect resource for anyone interested in PQ commit/rev=
eal protocols and contains many nuggets of wisdom in that realm.
> > > > > > > > > >=20

> > > > > > > > > >=20

> > > > > > > > > > Thanks again for the kind words!
> > > > > > > > > > I don't share the same sentiment regarding the conclusi=
on:
> > > > > > > > > > First, our FawkesCoin approach doesn't require new prim=
itives (Picnic / zk-STARKs), so it can be implemented relatively easily. Mo=
re importantly, it can accommodate many more transactions per block: AFAIK,=
 a zk-STARK and similarly Picnic are roughly 2-3 orders of magnitude larger=
 than an ECDSA signature (~100 Bytes vs.~10-100KB). A transaction fee costs=
 an order of a dollar these days, so PICNIC/zk-STARK based approaches would=
 cost hundreds of dollars, and would allow only a small number of people to=
 recover their funds. The only downside of FawkesCoin is that spending is d=
one in two separate steps (commit-wait 100 blocks-reveal), which is more cu=
mbersome and takes longer. See my comment above regarding the advantages of=
 Lifted FawkesCoin: FawkesCoin and Lifted FawkesCoin approaches can be used=
 together.
> > > > > > > > > >=20

> > > > > > > > > > Best,
> > > > > > > > > > Or
> > > > > > > > > >=20

> > > > > > > > > >=20

> > > > > > > > > >=20

> > > > > > > > > > >=20

> > > > > > > > > > > regards,
> > > > > > > > > > > conduition
> > > > > > > > > > >=20

> > > > > > > > > > >=20

> > > > > > > > > > >=20

> > > > > > > > > > >=20

> > > > > > > > > > >=20

> > > > > > > > > > >=20

> > > > > > > > > > >=20

> > > > > > > > > > > On Sunday, July 13th, 2025 at 9:49 AM, Or Sattath <sa=
t...@gmail.com> wrote:
> > > > > > > > > > >=20

> > > > > > > > > > > > Hi,
> > > > > > > > > > > >=20

> > > > > > > > > > > > Jameson Lopp presented the freeze/not-freeze dilemm=
a. I would like to point out that there=E2=80=99s a third approach. The mai=
n insight is that even though the quantum attacker knows the digital signat=
ure private key, the attacker and the owner are not symmetric: the owner, i=
n most cases, knows the seed (master secret key), whereas the quantum attac=
ker does not. This approach, which was done in collaboration with Shai Wybo=
rski, is available here: https://eprint.iacr.org/2023/362 (our work was pee=
r reviewed and presented here: https://www.qsmc.org/pqcsm-workshop-2023).
> > > > > > > > > > > >=20

> > > > > > > > > > > > Our main technique is called =E2=80=9Csignature lif=
ting=E2=80=9D: it=E2=80=99s a way to transform an existing quantum-insecure=
 signature scheme into a quantum-secure signature scheme, while still using=
 the old keys. This is possible whenever the function that maps the secret =
key to the public key is a quantum-secure one-way function. Informally (and=
 there are some details under the rug that I=E2=80=99m not getting into), t=
he quantum-secure one-way function maps the seed to the public key. (Of cou=
rse, the function that maps the ECDSA signing key to the public key is not =
a quantum-secure one-way function. Therefore, our approach does not apply t=
o pre-2013 wallets, which did not use BIP-38.) We use Picnic (https://dl.ac=
m.org/doi/abs/10.1145/3133956.3133997) as the underlying primitive that ena=
bles signature lifting.
> > > > > > > > > > > >=20

> > > > > > > > > > > > The main drawback of signature lifting is that the =
signatures are extremely long. To address this, we also designed an interac=
tive way to transact, using a commit-wait-reveal approach, which we called =
=E2=80=9CLifted FawkesCoin" (our main contribution over the original Fawkes=
Coin approach by Bonneau and Miller in https://jbonneau.com/doc/BM14-SPW-fa=
wkescoin.pdf is that we resolve the issue of transaction fees, using lifted=
 signatures). When the spender and the miner are honest, a transaction is r=
oughly the same size as today; only if one of the parties deviates from the=
 honest protocol must the long signature be added to the blockchain, and th=
e cheating party is financially penalized. The main burden of Lifted Fawkes=
Coin is that users who haven=E2=80=99t transitioned to quantum-secure signa=
tures yet need to occasionally (e.g., once a year) come online and check fo=
r fraud attempts. I believe that even though this burden exists, it is a Pa=
reto improvement over both the =E2=80=9Cfreeze=E2=80=9D and =E2=80=9Cnot-fr=
eeze=E2=80=9D approaches.
> > > > > > > > > > > >=20

> > > > > > > > > > > > Best,
> > > > > > > > > > > > Or
> > > > > > > > > > > >=20

> > > > > > > > > > > > On Sunday, March 16, 2025 at 5:22:16=E2=80=AFPM UTC=
+2 Jameson Lopp wrote:
> > > > > > > > > > > >=20

> > > > > > > > > > > > > The quantum computing debate is heating up. There=
 are many controversial aspects to this debate, including whether or not qu=
antum computers will ever actually become a practical threat.
> > > > > > > > > > > > > I won't tread into the unanswerable question of h=
ow worried we should be about quantum computers. I think it's far from a cr=
isis, but given the difficulty in changing Bitcoin it's worth starting to s=
eriously discuss. Today I wish to focus on a philosophical quandary related=
 to one of the decisions that would need to be made if and when we implemen=
t a quantum safe signature scheme.
> > > > > > > > > > > > >=20

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

> > > > > > > > > > > > > 1. Quantum computing never materializes, never be=
comes a threat, and thus everything discussed in this essay is moot.
> > > > > > > > > > > > > 2. A quantum computing threat materializes sudden=
ly and Bitcoin does not have quantum safe signatures as part of the protoco=
l. In this scenario it would likely make the points below moot because Bitc=
oin would be fundamentally broken and it would take far too long to upgrade=
 the protocol, wallet software, and migrate user funds in order to restore =
confidence in the network.
> > > > > > > > > > > > > 3. Quantum computing advances slowly enough that =
we come to consensus about how to upgrade Bitcoin and post quantum security=
 has been minimally adopted by the time an attacker appears.
> > > > > > > > > > > > > 4. Quantum computing advances 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 appears.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > For the purposes of this post, I'm envisioning be=
ing in situation 3 or 4.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > To Freeze or not to Freeze?
> > > > > > > > > > > > > I've started seeing more people weighing in on wh=
at is likely the most contentious aspect of how a quantum resistance upgrad=
e should be handled in terms of migrating user funds. Should quantum vulner=
able funds be left open to be swept by anyone with a sufficiently powerful =
quantum computer OR should they be permanently locked?
> > > > > > > > > > > > >=20

> > > > > > > > > > > > >=20

> > > > > > > > > > > > > > "I don't see why old coins should be confiscate=
d. The better option is to let those with quantum computers free up old coi=
ns. While this might have an inflationary impact on bitcoin's price, to use=
 a turn of phrase, the inflation is transitory. Those with low time prefere=
nce should support returning lost coins to circulation."
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > > - Hunter Beast
> > > > > > > > > > > > >=20

> > > > > > > > > > > > >=20

> > > > > > > > > > > > > On the other hand:
> > > > > > > > > > > > >=20

> > > > > > > > > > > > >=20

> > > > > > > > > > > > > > "Of course they have to be confiscated. If and =
when (and that's a big if) the existence of a cryptography-breaking QC beco=
mes a credible threat, the Bitcoin ecosystem has no other option than softf=
orking out the ability to spend from signature schemes (including ECDSA and=
 BIP340) that are vulnerable to QCs. The alternative is that millions of BT=
C become vulnerable to theft; I cannot see how the currency can maintain an=
y value at all in such a setting. And this affects everyone; even those whi=
ch diligently moved their coins to PQC-protected schemes."
> > > > > > > > > > > > > > - Pieter Wuille
> > > > > > > > > > > > >=20

> > > > > > > > > > > > >=20

> > > > > > > > > > > > > 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 discussing would be better described as "burning" - placing t=
he funds out of reach of everyone.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > Not freezing user funds is one of Bitcoin's invio=
lable properties. However, if quantum computing becomes a threat to Bitcoin=
's elliptic curve cryptography, an inviolable property of Bitcoin will be v=
iolated one way or another.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > Fundamental Properties at Risk
> > > > > > > > > > > > > 5 years ago I attempted to comprehensively catego=
rize all of Bitcoin's fundamental properties that give it value. https://na=
kamoto.com/what-are-the-key-properties-of-bitcoin/
> > > > > > > > > > > > > The particular properties in play with regard to =
this issue seem to be:
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > Censorship Resistance - No one should have the po=
wer to prevent others from using their bitcoin or interacting with the netw=
ork.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > Forward Compatibility - changing the rules such t=
hat certain valid transactions become invalid could undermine confidence in=
 the protocol.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > Conservatism - Users should not be expected to be=
 highly responsive to system issues.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > As a result of the above principles, we have deve=
loped a strong meme (kudos to Andreas Antonopoulos) that goes as follows:
> > > > > > > > > > > > >=20

> > > > > > > > > > > > >=20

> > > > > > > > > > > > > > Not your keys, not your coins.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > >=20

> > > > > > > > > > > > > I posit that the corollary to this principle is:
> > > > > > > > > > > > >=20

> > > > > > > > > > > > >=20

> > > > > > > > > > > > > > Your keys, only your coins.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > >=20

> > > > > > > > > > > > > A quantum capable entity breaks the corollary of =
this foundational principle. We secure our bitcoin with the mathematical pr=
obabilities related to extremely large random numbers. Your funds are only =
secure because truly random large numbers should not be guessable or discov=
erable by anyone else in the world.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > This is the principle behind the motto vires in n=
umeris - strength in numbers. In a world with quantum enabled adversaries, =
this principle is null and void for many types of cryptography, including t=
he elliptic curve digital signatures used in Bitcoin.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > Who is at Risk?
> > > > > > > > > > > > > There has long been a narrative that Satoshi's co=
ins and others from the Satoshi era of P2PK locking scripts that exposed th=
e public key directly on the blockchain will be those that get scooped up b=
y a quantum "miner." But unfortunately it's not that simple. If I had a pow=
erful quantum computer, which coins would I target? I'd go to the Bitcoin r=
ich list and find the wallets that have exposed their public keys due to re=
-using addresses that have previously been spent from. You can easily find =
them at https://bitinfocharts.com/top-100-richest-bitcoin-addresses.html
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > Note that a few of these wallets, like Bitfinex /=
 Kraken / Tether, would be slightly harder to crack because they are multis=
ig wallets. So a quantum attacker would need to reverse engineer 2 keys for=
 Kraken or 3 for Bitfinex / Tether in order to spend funds. But many are si=
ngle signature.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > Point being, it's not only the really old lost BT=
C that are at risk to a quantum enabled adversary, at least at time of writ=
ing. If we add a quantum safe signature scheme, we should expect those wall=
ets to be some of the first to upgrade given their incentives.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > The Ethical Dilemma: Quantifying Harm
> > > > > > > > > > > > > Which decision results in the most harm?
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > By making quantum vulnerable funds unspendable we=
 potentially harm some Bitcoin users who were not paying attention and negl=
ected to migrate their funds to a quantum safe locking script. This violate=
s the "conservativism" principle stated earlier. On the flip side, we preve=
nt those funds plus far more lost funds from falling into the hands of the =
few privileged folks who gain early access to quantum computers.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > By leaving quantum vulnerable funds available to =
spend, the same set of users who would otherwise have funds frozen are like=
ly to see them stolen. And many early adopters who lost their keys will eve=
ntually see their unreachable funds scooped up by a quantum enabled adversa=
ry.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > Imagine, for example, being James Howells, who ac=
cidentally threw away a hard drive with 8,000 BTC on it, currently worth ov=
er $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 to excavate. I suspec=
t that, given the choice, he'd prefer those funds be permanently frozen rat=
her than fall into someone else's possession - I know I would.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > Allowing a quantum computer to access lost funds =
doesn't make those users any worse off than they were before, however it wo=
uld have a negative impact upon everyone who is currently holding bitcoin.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > It's prudent to expect significant economic disru=
ption if large amounts of coins fall into new hands. Since a quantum comput=
er is going to have a massive up front cost, expect those behind it to desi=
re to recoup their investment. We also know from experience that when someo=
ne suddenly finds themselves in possession of 9+ figures worth of highly li=
quid assets, they tend to diversify into other things by selling.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > Allowing quantum recovery of bitcoin is tantamoun=
t to wealth redistribution. What we'd be allowing is for bitcoin to be redi=
stributed from those who are ignorant of quantum computers to those who hav=
e won the technological race to acquire quantum computers. It's hard to see=
 a bright side to that scenario.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > Is Quantum Recovery Good for Anyone?
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > Does quantum recovery HELP anyone? I've yet to co=
me across an argument that it's a net positive in any way. It certainly doe=
sn'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 n=
ot earn them.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > But wait, you may be thinking, wouldn't quantum "=
miners" have earned their coins by all the work and resources invested in b=
uilding a quantum computer? I suppose, in the same sense that a burglar ear=
ns their spoils by the resources they invest into surveilling targets and l=
earning the skills needed to break into buildings. What I say "earned" I me=
an through productive mutual trade.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > For example:
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > * Investors earn BTC by trading for other currenc=
ies.
> > > > > > > > > > > > > * Merchants earn BTC by trading for goods and ser=
vices.
> > > > > > > > > > > > > * Miners earn BTC by trading thermodynamic securi=
ty.
> > > > > > > > > > > > > * Quantum miners don't trade anything, they are v=
ampires feeding upon the system.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > There's no reason to believe that allowing quantu=
m adversaries to recover vulnerable bitcoin will be of benefit to anyone ot=
her than the select few organizations that win the technological arms race =
to build the first such computers. Probably nation states and/or the top fe=
w largest tech companies.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > One could certainly hope that an organization wit=
h quantum supremacy is benevolent and acts in a "white hat" manner to retur=
n lost coins to their owners, but that's incredibly optimistic and foolish =
to rely upon. Such a situation creates an insurmountable ethical dilemma of=
 only recovering lost bitcoin rather than currently 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 keys then proving they ever=
 had the keys becomes rather difficult. I imagine that any such white hat r=
ecovery efforts would have to rely upon attestations from trusted third par=
ties like exchanges.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > Even if the first actor with quantum supremacy is=
 benevolent, we must assume the technology could fall into adversarial hand=
s and thus think adversarially about the potential worst case outcomes. Ima=
gine, for example, that North Korea continues scooping up billions of dolla=
rs from hacking crypto exchanges and decides to invest some of those procee=
ds into building a quantum computer for the biggest payday ever...
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > Downsides to Allowing Quantum Recovery
> > > > > > > > > > > > > Let's think through an exhaustive list of pros an=
d cons for allowing or preventing the seizure of funds by a quantum adversa=
ry.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > Historical Precedent
> > > > > > > > > > > > > Previous protocol vulnerabilities weren=E2=80=99t=
 celebrated as "fair game" but rather were treated as failures to be remedi=
ated. Treating quantum theft differently risks rewriting Bitcoin=E2=80=99s =
history as a free-for-all rather than a system that seeks to protect its us=
ers.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > Violation of Property Rights
> > > > > > > > > > > > > Allowing a quantum adversary to take control of f=
unds undermines the fundamental principle of cryptocurrency - if you keep y=
our keys in your possession, only you should be able to access your money. =
Bitcoin is 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 legitimate transfer.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > Erosion of Trust in Bitcoin
> > > > > > > > > > > > > If quantum attackers can exploit vulnerable addre=
sses, confidence in Bitcoin as a secure store of value would collapse. User=
s and investors rely on cryptographic integrity, and widespread theft could=
 drive adoption away from Bitcoin, destabilizing its ecosystem.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > This is essentially the counterpoint to claiming =
the burning of vulnerable funds is a violation of property rights. While so=
me will certainly see it as such, others will find the apathy toward stoppi=
ng quantum theft to be similarly concerning.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > 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 where only the te=
chnologically elite can exploit others, contradicting Bitcoin=E2=80=99s eth=
os of decentralized power.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > Bitcoin is designed to create an asymmetric advan=
tage for DEFENDING one's wealth. It's supposed to be impractically expensiv=
e for attackers to crack the entropy and cryptography protecting one's coin=
s. But now we find ourselves discussing a situation where this asymmetric a=
dvantage is compromised in favor of a specific class of attackers.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > Economic Disruption
> > > > > > > > > > > > > Large-scale theft from vulnerable addresses could=
 crash Bitcoin=E2=80=99s price as quantum recovered funds are dumped on exc=
hanges. This would harm all holders, not just those directly targeted, lead=
ing to broader financial chaos in the markets.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > Moral Responsibility
> > > > > > > > > > > > > Permitting theft via quantum computing sets a pre=
cedent that technological superiority justifies unethical behavior. This is=
 essentially 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 situa=
tions.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > Burning of coins can certainly be considered a fo=
rm of theft, thus I think it's worth differentiating the two different thef=
ts being discussed:
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > 1. self-enriching & likely malicious
> > > > > > > > > > > > > 2. harm prevention & not necessarily malicious
> > > > > > > > > > > > >=20

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

> > > > > > > > > > > > > Incentives Drive Security
> > > > > > > > > > > > > I can tell you from a decade of working in Bitcoi=
n security - the average user is lazy and is a procrastinator. If Bitcoiner=
s are given a "drop dead date" after which they know vulnerable funds will =
be burned, this pressure accelerates the adoption of post-quantum cryptogra=
phy and strengthens Bitcoin long-term. Allowing vulnerable users to delay u=
pgrading indefinitely will result in more laggards, leaving the network mor=
e exposed when quantum tech becomes available.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > Steel Manning
> > > > > > > > > > > > > Clearly this is a complex and controversial topic=
, thus it's worth thinking through the opposing arguments.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > Protecting Property Rights
> > > > > > > > > > > > > Allowing quantum computers to take vulnerable bit=
coin could potentially be spun as a hard money narrative - we care so great=
ly about not violating someone's access to their coins that we allow them t=
o be stolen!
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > But I think the flip side to the property rights =
narrative is that burning vulnerable coins prevents said property from fall=
ing into undeserving hands. If the entire Bitcoin ecosystem just stands aro=
und and allows quantum adversaries to claim funds that rightfully belong to=
 other users, is that really a "win" in the "protecting property rights" ca=
tegory? It feels more like apathy to me.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > As such, I think the "protecting property rights"=
 argument is a wash.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > Quantum Computers Won't Attack Bitcoin
> > > > > > > > > > > > > There is a great deal of skepticism that sufficie=
ntly powerful quantum computers will ever exist, so we shouldn't bother pre=
paring for a non-existent threat. Others have argued that even if such a co=
mputer was built, a quantum attacker would not go after bitcoin because the=
y wouldn't want to reveal their hand by doing so, and would instead attack =
other infrastructure.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > It's quite difficult to quantify exactly how valu=
able attacking other infrastructure would be. It also really depends upon w=
hen 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 t=
hat certain entities gaining quantum capability might not attack Bitcoin, i=
t would only delay the inevitable - eventually somebody will achieve the ca=
pability who decides to use it for such an attack.
> > > > > > > > > > > > >=20

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

> > > > > > > > > > > > > I'm not so sure about that; why go after 50 BTC a=
t a time when you could take 250,000 BTC with the same effort as 50 BTC? Th=
is is a classic "zero day exploit" game theory in which an attacker knows t=
hey 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 B=
yBit attack - the highest value crypto hack of all time. Lazarus Group had =
compromised the Safe wallet front end JavaScript app and they could have si=
mply had it reassign ownership of everyone's Safe wallets as they were inte=
racting with their wallet. But instead they chose to only specifically targ=
et ByBit's wallet with $1.5 billion in it because they wanted to maximize t=
heir extractable value. If Lazarus had started stealing from every wallet, =
they would have been discovered quickly and the Safe web app would likely h=
ave been patched well before any billion dollar wallets executed the malici=
ous code.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > I think the "only stealing small amounts" argumen=
t is strongest for Situation #2 described earlier, where a quantum attacker=
 arrives before quantum safe cryptography has been deployed across the Bitc=
oin ecosystem. Because if it became clear that Bitcoin's cryptography was b=
roken AND there was nowhere safe for vulnerable users to migrate, the only =
logical option would be for everyone to liquidate their bitcoin as quickly =
as possible. As such, I don't think it applies as strongly for situations i=
n which we have a migration path available.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > The 21 Million Coin Supply Should be in Circulati=
on
> > > > > > > > > > > > > Some folks are arguing that it's important for th=
e "circulating / spendable" supply to be as close to 21M as possible and th=
at having a significant portion of the supply out of circulation is somehow=
 undesirable.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > 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, an=
d that's actually part of the game theory of owning bitcoin!
> > > > > > > > > > > > >=20

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

> > > > > > > > > > > > > Self-Sovereignty and Personal Responsibility
> > > > > > > > > > > > > Bitcoin=E2=80=99s design empowers individuals to =
control their own wealth, free from centralized intervention. This freedom =
comes with the burden of securing one'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 shiel=
d users from their own negligence undermines the principle that you, and no=
t a third party, are accountable for your assets.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > I think this is generally a fair point that "the =
community" doesn't owe you anything in terms of helping you. I think that w=
e do, however, need to consider the incentives and game theory in play with=
 regard to quantum safe Bitcoiners vs quantum vulnerable Bitcoiners. More o=
n that later.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > Code is Law
> > > > > > > > > > > > > Bitcoin operates on transparent, immutable rules =
embedded in its protocol. If a quantum attacker uses superior technology to=
 derive private keys from public keys, they=E2=80=99re not "hacking" the sy=
stem - they're simply following what's mathematically permissible within th=
e current code. Altering the protocol to stop this introduces subjective hu=
man intervention, which clashes with the objective, deterministic nature of=
 blockchain.
> > > > > > > > > > > > >=20

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

> > > > > > > > > > > > > Technological Evolution as a Feature, Not a Bug
> > > > > > > > > > > > > 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-resis=
tant wallets when available) are akin to those who ignored technological ad=
vancements like multisig or hardware wallets. Allowing quantum theft incent=
ivizes innovation and keeps Bitcoin=E2=80=99s ecosystem dynamic, punishing =
complacency while rewarding vigilance.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > Market Signals Drive Security
> > > > > > > > > > > > > If quantum attackers start stealing funds, it sen=
ds a clear signal to the market: upgrade your security or lose everything. =
This pressure accelerates the adoption of post-quantum cryptography and str=
engthens Bitcoin long-term. Coddling vulnerable users delays this necessary=
 evolution, potentially leaving the network more exposed when quantum tech =
becomes widely accessible. Theft is a brutal but effective teacher.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > Centralized Blacklisting Power
> > > > > > > > > > > > > Burning vulnerable funds requires centralized dec=
ision-making - a soft fork to invalidate certain transactions. This sets a =
dangerous precedent for future interventions, eroding Bitcoin=E2=80=99s dec=
entralization. If quantum theft is blocked, what=E2=80=99s next - reversing=
 exchange hacks? The system must remain neutral, even if it means some lose=
 out.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > I think this could be a potential slippery slope =
if the proposal was to only burn specific addresses. Rather, I'd expect a n=
eutral proposal to burn all funds in locking script types that are known to=
 be quantum vulnerable. Thus, we could eliminate any subjectivity from the =
code.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > Fairness in Competition
> > > > > > > > > > > > > Quantum attackers aren't cheating; they're using =
publicly available physics and math. Anyone with the resources and foresigh=
t can build or access quantum tech, just as anyone could mine Bitcoin in 20=
09 with a CPU. Early adopters took risks and reaped rewards; quantum innova=
tors are doing the same. Calling it =E2=80=9Cunfair=E2=80=9D ignores that B=
itcoin has never promised equality of outcome - only equality of opportunit=
y within its rules.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > I find this argument to be a mischaracterization =
because we're not talking about CPUs. This is more akin to talking about AS=
ICs, except each ASIC costs millions if not billions of dollars. This is ou=
t of reach from all but the wealthiest organizations.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > Economic Resilience
> > > > > > > > > > > > > Bitcoin has weathered thefts before (MTGOX, Bitfi=
nex, FTX, etc) and emerged stronger. The market can absorb quantum losses, =
with unaffected users continuing to hold and new entrants buying in at lowe=
r prices. Fear of economic collapse overestimates the impact - the network=
=E2=80=99s antifragility thrives on such challenges.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > This is a big grey area because we don't know whe=
n a quantum computer will come online and we don't know how quickly said co=
mputers would be able to steal bitcoin. If, for example, the first generati=
on of sufficiently powerful quantum computers were stealing less volume tha=
n the current block reward then of course it will have minimal economic imp=
act. But if they're taking thousands of BTC per day and bringing them back =
into circulation, there will likely be a noticeable market impact as it abs=
orbs the new supply.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > This is where the circumstances will really matte=
r. If a quantum attacker appears AFTER the Bitcoin protocol has been upgrad=
ed to support quantum resistant cryptography then we should expect the most=
 valuable active wallets will have upgraded and the juiciest target would b=
e the 31,000 BTC in the address 12ib7dApVFvg82TXKycWBNpN8kFyiAN1dr which ha=
s 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 e=
mission curve: volume would start off very high as the most valuable addres=
ses are drained and then it would fall off as quantum computers went down t=
he list targeting addresses with less and less BTC.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > Why is economic impact a factor worth considering=
? Miners and businesses in general. More coins being liquidated will push d=
own 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, burnin=
g quantum vulnerable bitcoin is good for the entire industry.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > Practicality & Neutrality of Non-Intervention
> > > > > > > > > > > > > There=E2=80=99s no reliable way to distinguish =
=E2=80=9Ctheft=E2=80=9D from legitimate "white hat" key recovery. If someon=
e loses their private key and a quantum computer recovers it, is that steal=
ing or reclaiming? Policing quantum actions requires invasive assumptions a=
bout intent, which Bitcoin=E2=80=99s trustless design can=E2=80=99t accommo=
date. Letting the chips fall where they may avoids this mess.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > Philosophical Purity
> > > > > > > > > > > > > Bitcoin rejects bailouts. It=E2=80=99s a cold, ha=
rd system where outcomes reflect preparation and skill, not sentimentality.=
 If quantum computing upends the game, that=E2=80=99s the point - Bitcoin i=
sn=E2=80=99t meant to be safe or fair in a nanny-state sense; 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 injustice.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > Bitcoin's DAO Moment
> > > > > > > > > > > > > This situation has some similarities to The DAO h=
ack of an Ethereum smart contract in 2016, which resulted in a fork to stop=
 the attacker and return 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 mitigate the attack by changing the protocol.
> > > > > > > > > > > > >=20

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

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

> > > > > > > > > > > > > Incentives Matter
> > > > > > > > > > > > > We can wax philosophical until the cows come home=
, but what are the actual incentives for existing Bitcoin holders regarding=
 this decision?
> > > > > > > > > > > > >=20

> > > > > > > > > > > > >=20

> > > > > > > > > > > > > > "Lost coins only make everyone else's coins wor=
th slightly more. Think of it as a donation to everyone." - Satoshi Nakamot=
o
> > > > > > > > > > > > >=20

> > > > > > > > > > > > >=20

> > > > > > > > > > > > > If true, the corollary is:
> > > > > > > > > > > > >=20

> > > > > > > > > > > > >=20

> > > > > > > > > > > > > > "Quantum recovered coins only make everyone els=
e's coins worth less. Think of it as a theft from everyone." - Jameson Lopp
> > > > > > > > > > > > >=20

> > > > > > > > > > > > >=20

> > > > > > > > > > > > > Thus, assuming we get to a point where quantum re=
sistant signatures are supported within the Bitcoin protocol, what's the in=
centive to let vulnerable coins remain spendable?
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > * It's not good for the actual owners of those co=
ins. It disincentivizes owners from upgrading until perhaps it's too late.
> > > > > > > > > > > > > * It's not good for the more attentive / responsi=
ble owners of coins who have quantum secured their stash. Allowing the circ=
ulating supply to balloon will assuredly reduce the purchasing power of all=
 bitcoin holders.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > Forking Game Theory
> > > > > > > > > > > > > From a game theory point of view, I see this as i=
ncentivizing users to upgrade their wallets. If you disagree with the burni=
ng 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 economic maj=
ority (or even more than a tiny minority) of users who would fight such a s=
oft fork. Why expend significant resources fighting a fork when you can jus=
t move your coins to a new address?
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > Remember that blocking spending of certain classe=
s of locking scripts is a tightening of the rules - a soft fork. As such, i=
t can be meaningfully enacted and enforced by a mere majority of hashpower.=
 If miners generally agree that it's in their best interest to burn vulnera=
ble 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.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > How to Execute Burning
> > > > > > > > > > > > > In order to be as objective as possible, the goal=
 would be to announce to the world that after a specific block height / tim=
estamp, Bitcoin nodes will no longer accept transactions (or blocks contain=
ing such transactions) that spend funds from any scripts other than the new=
ly instituted quantum safe schemes.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > It could take a staggered approach to first freez=
e funds that are susceptible to long-range attacks such as those in P2PK sc=
ripts or those that exposed their public keys due to previously re-using ad=
dresses, but I expect the additional complexity would drive further controv=
ersy.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > How long should the grace period be in order to g=
ive the ecosystem time to upgrade? I'd say a minimum of 1 year for software=
 wallets to upgrade. We can only hope that hardware wallet manufacturers ar=
e able to implement post quantum cryptography on their existing hardware wi=
th only a firmware update.
> > > > > > > > > > > > >=20

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

> > > > > > > > > > > > > Regardless, I'd think that in order to reasonably=
 uphold Bitcoin's conservatism it would be preferable to allow a 4 year mig=
ration window. In the meantime, mining pools could coordinate emergency sof=
t forking logic such that if quantum attackers materialized, they could acc=
elerate the countdown to the quantum vulnerable funds burn.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > Random Tangential Benefits
> > > > > > > > > > > > > On the plus side, burning all quantum vulnerable =
bitcoin would allow us to prune all of those UTXOs out of the UTXO set, whi=
ch 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 t=
hem up.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > We should also expect that incentivizing migratio=
n of the entire UTXO set will create substantial demand for block space tha=
t will sustain a fee market for a fairly lengthy amount of time.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > In Summary
> > > > > > > > > > > > > While the moral quandary of violating any of Bitc=
oin's inviolable properties can make this a very complex issue to discuss, =
the game theory and incentives between burning vulnerable coins versus allo=
wing them to be claimed by entities with quantum supremacy appears to be a =
much simpler issue.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > I, for one, am not interested in rewarding quantu=
m capable entities by inflating the circulating money supply just because s=
ome people lost their keys long ago and some laggards are not upgrading the=
ir bitcoin wallet's security.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > We can hope that this scenario never comes to pas=
s, but hope is not a strategy.
> > > > > > > > > > > > >=20

> > > > > > > > > > > > > I welcome your feedback upon any of the above poi=
nts, and contribution of any arguments I failed to consider.
> > > > > > > > > > >=20

> > > > > > > > > > > > --
> > > > > > > > > > >=20

> > > > > > > > > > > > You received this message because you are subscribe=
d to the Google Groups "Bitcoin Development Mailing List" group.
> > > > > > > > > > > > To unsubscribe from this group and stop receiving e=
mails from it, send an email to bitcoindev+...@googlegroups.com.
> > > > > > > > > > >=20

> > > > > > > > > > > > To view this discussion visit https://groups.google=
.com/d/msgid/bitcoindev/f17de19d-a6f5-46b3-abcd-09c056d9bd64n%40googlegroup=
s.com.
> > > > > > > > > >=20

> > > > > > > > > > --
> > > > > > > > > > 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 email=
s from it, send an email to bitcoindev+...@googlegroups.com.
> > > > > > > > >=20

> > > > > > > > > > To view this discussion visit https://groups.google.com=
/d/msgid/bitcoindev/6326b5d0-df6b-4f40-9d15-9ed502278397n%40googlegroups.co=
m.
> > > > > > > >=20

> > > > > > > > --
> > > > > > > > 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 fr=
om it, send an email to bitcoindev+unsubscribe@googlegroups.com.
> > > > > > > > To view this discussion visit https://groups.google.com/d/m=
sgid/bitcoindev/c56b179f-2753-4f1c-80a4-14969e737d37n%40googlegroups.com.
> > > > > >=20

> > > > > >=20

> > > > > >=20

> > > > > > --
> > > > > > Best regards,
> > > > > > Boris Nagaev
> > > >=20

> > > >=20

> > > >=20

> > > > --
> > > > Best regards,
> > > > Boris Nagaev
> >=20

> >=20

> >=20

> > --
> > Best regards,
> > Boris Nagaev
> >=20

> > --
> > You received this message because you are subscribed to the Google Grou=
ps "Bitcoin Development Mailing List" group.
> > To unsubscribe from this group and stop receiving emails from it, send =
an email to bitcoindev+unsubscribe@googlegroups.com.
> > To view this discussion visit https://groups.google.com/d/msgid/bitcoin=
dev/CAFC_Vt7a1O9vCdycRtUmTAQyL%3DifZAZt3Wzx-YBTQ1cKyJq55w%40mail.gmail.com.
>=20

> --
> 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=
 email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/bitcoinde=
v/YX1Q8oL5phYHC8fM_m4aHakglTjz1RYlv8k7tGgbq9Rx_jx6BFmG6Y8uA7Vrma0fOX3kCTD30=
k0PCUGeBX_bnglN5GWCZdGABxKDOjvt_bA%3D%40proton.me.

--=20
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.google.com/d/msgid/bitcoindev/=
4wCyWdzfJTskjdcX3WSpbV53KAhAc_CwqS-65RAA9cD1lcttvdFgG4LPY1U8YRlcJrPJMAc_aR_=
d4uLiUxMypdxmoMAhN5WDlCByp1mWHnM%3D%40proton.me.

-----------------------7359e0b8461b9366496a00df1ae9812f
Content-Type: multipart/related;boundary=---------------------5da4cd42e798bcfc4b1e2cb62bb0b6da

-----------------------5da4cd42e798bcfc4b1e2cb62bb0b6da
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div style=3D"font-family: Arial, sans-serif; font-size: 14px;">I remember =
what i was talking about a few weeks back.</div><div style=3D"font-family: =
Arial, sans-serif; font-size: 14px;"><br></div><div style=3D"font-family: A=
rial, sans-serif; font-size: 14px;">I was envisioning that all the pubkeys =
would be merged together <i>across all inputs</i>=E2=80=8B, but this would =
break the total ordering on commitments. Given a reveal TX, the validator w=
ouldn't know if the commitment being opened was the <i>earliest</i>=E2=80=
=8B, because a miner could censor a reveal transaction for a block or two a=
nd insert a different one with a different set of inputs, resulting in a di=
fferent HMAC key.&nbsp;</div><div style=3D"font-family: Arial, sans-serif; =
font-size: 14px;"><br></div><div style=3D"font-family: Arial, sans-serif; f=
ont-size: 14px;">This is also the reason why my "witness hashing" idea won'=
t work. The witness stack can be changed by a Quantum adversary after the r=
eveal TX is opened, by inverting one of the pubkeys and making a fresh new =
signature. This changes the HMAC key that would've been used in an authenti=
c commitment, and validators won't be able to check the commitment ordering=
. So we do still need to HMAC sign the TXID, and we have to do it on a per-=
input basis.</div><div style=3D"font-family: Arial, sans-serif; font-size: =
14px;"><br></div><div style=3D"font-family: Arial, sans-serif; font-size: 1=
4px;">We <i>can</i>=E2=80=8B merge pubkeys into a single HMAC key as you su=
ggested Boris, as long as we merge only the pubkeys within a single locking=
 script of a specific reveal TX input. This way the HMAC key that we reveal=
 to open any commitment is always the same, regardless of who tries to spen=
d the revealed input. <span style=3D"display: inline !important; background=
-color: rgb(255, 255, 255);">Taproot would be an exception since a P2TR add=
ress can have many possible locking scripts with different sets of pubkeys,=
 but a quantum attacker probably won't be able to find them without inverti=
ng SHA256.</span></div><div style=3D"font-family: Arial, sans-serif; font-s=
ize: 14px;"><br></div><div style=3D"font-family: Arial, sans-serif; font-si=
ze: 14px;">This means the reveal TX validator can find a clean ordering of =
past commitments for that reveal, and this thwarts any attacks from miners =
that rely on censoring the reveal TX.</div><div style=3D"font-family: Arial=
, sans-serif; font-size: 14px;"><br></div><div style=3D"font-family: Arial,=
 sans-serif; font-size: 14px;">regards,</div><div style=3D"font-family: Ari=
al, sans-serif; font-size: 14px;">conduition</div><div class=3D"protonmail_=
quote">
        On Saturday, August 9th, 2025 at 10:58 AM, 'conduition' via Bitcoin=
 Development Mailing List &lt;bitcoindev@googlegroups.com&gt; wrote:<br>
        <blockquote class=3D"protonmail_quote" type=3D"cite">
            <div style=3D"font-family: Arial, sans-serif; font-size: 14px;"=
>Hey Boris,</div><div style=3D"font-family: Arial, sans-serif; font-size: 1=
4px;"><br></div><blockquote style=3D"border-left: 3px solid rgb(200, 200, 2=
00); border-top-color: rgb(200, 200, 200); border-right-color: rgb(200, 200=
, 200); border-bottom-color: rgb(200, 200, 200); padding-left: 10px; color:=
 rgb(102, 102, 102);"><div style=3D"font-family: Arial, sans-serif; font-si=
ze: 14px;"><span>I propose to simplify this by using just one MAC with all =
the pubkeys as a single key. If you know why this is a bad idea, please sha=
re.</span><br></div></blockquote><div style=3D"font-family: Arial, sans-ser=
if; font-size: 14px;"><br></div><div style=3D"font-family: Arial, sans-seri=
f; font-size: 14px;">I think I forgot my train of thought here on why this =
allowed miner attack, probably should've written it down. Maybe i was think=
ing of merging individual per-key MACs together with a hash... Anyway, your=
 suggestion of HMAC(key=3D[k1, k2, k3...], msg=3Dtxid) seems like a reasona=
ble way of compressing the scheme. If I think of any way to break that I'll=
 let you know.&nbsp;</div><div style=3D"font-family: Arial, sans-serif; fon=
t-size: 14px;"><br></div><div style=3D"font-family: Arial, sans-serif; font=
-size: 14px;">But perhaps there is an even better option. What if, rather t=
han publishing a commitment to the EC keys (which is basically a commitment=
 to the locking script), we publish a commitment to the <i>witnesses</i>=E2=
=80=8B that will be used to spend the UTXO?&nbsp;</div><div style=3D"font-f=
amily: Arial, sans-serif; font-size: 14px;"><br></div><div style=3D"font-fa=
mily: Arial, sans-serif; font-size: 14px;">The witness stack always include=
s at least one EC signature, which is bound to both the transaction and the=
 pubkey by OP_CHECKSIG. We are essentially pre-annoucning: "I will spend th=
is UTXO using this set of signatures". </div><div style=3D"font-family: Ari=
al, sans-serif; font-size: 14px;"><br></div><div style=3D"font-family: Aria=
l, sans-serif; font-size: 14px;">Then we could get away with a 68 byte comm=
itment made of two hashes and a u32: <code>(utxo, witness_hash)</code>=E2=
=80=8B. We no longer need to publish the TXID in the commitment, because <c=
ode>witness_hash</code>=E2=80=8B indirectly commits to it.&nbsp;<span style=
=3D"display: inline !important; background-color: rgb(255, 255, 255);">You'=
d compute the witness hash by simply concatenating and hashing all the witn=
ess data for each input in consensus order.</span></div><div style=3D"font-=
family: Arial, sans-serif; font-size: 14px;"><br></div><div style=3D"font-f=
amily: Arial, sans-serif; font-size: 14px;"><span style=3D"display: inline =
!important; background-color: rgb(255, 255, 255);">This is all for unexpose=
d addresses, btw. For UTXOs with exposed pubkeys, you could mix a BIP32 par=
ent xpriv into the witness hash somehow, and would need to publish the xpri=
v in the reveal TX.</span><br></div><div style=3D"font-family: Arial, sans-=
serif; font-size: 14px;"><br></div><div style=3D"font-family: Arial, sans-s=
erif; font-size: 14px;"></div><div style=3D"font-family: Arial, sans-serif;=
 font-size: 14px;"><br></div><div style=3D"font-family: Arial, sans-serif; =
font-size: 14px;">regards,</div><div style=3D"font-family: Arial, sans-seri=
f; font-size: 14px;">conduition</div><div class=3D"protonmail_quote">
        On Tuesday, July 29th, 2025 at 1:24 AM, Nagaev Boris &lt;bnagaev@gm=
ail.com&gt; wrote:<br>
        <blockquote class=3D"protonmail_quote" type=3D"cite">
            <div dir=3D"ltr"><div>Hi Conduition,</div><br><div class=3D"gma=
il_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Mo=
n, Jul 28, 2025 at 9:24=E2=80=AFPM conduition &lt;<a href=3D"mailto:conduit=
ion@proton.me" rel=3D"noreferrer nofollow noopener">conduition@proton.me</a=
>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px=
 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><di=
v style=3D"font-family:Arial,sans-serif;font-size:14px">Hi Boris,</div><div=
 style=3D"font-family:Arial,sans-serif;font-size:14px"><br></div><blockquot=
e style=3D"border-left:3px solid rgb(200,200,200);border-color:rgb(200,200,=
200);padding-left:10px;color:rgb(102,102,102)"><div style=3D"font-family:Ar=
ial,sans-serif;font-size:14px"><span>We can't let multiple commits per UTXO=
 be valid. Remember the original problem you posted a couple of messages ag=
o: miners can collude and delay reveal transaction confirmation, so we need=
 to make sure that the commitment of this reveal tx is the first valid comm=
itment for this UTXO</span><br></div></blockquote><div style=3D"font-family=
:Arial,sans-serif;font-size:14px"><br></div><div style=3D"font-family:Arial=
,sans-serif;font-size:14px">Ah i see what you mean now. Your suggestion of =
requiring one and only one hardened derivation step is probably the easiest=
 option to fix that. That way, for any set of EC keys, there exists at most=
 one matching parent xpriv. Revealing that xpriv doesn't give observers any=
 valid alternative HMAC keys.</div><div style=3D"font-family:Arial,sans-ser=
if;font-size:14px"><br></div><blockquote style=3D"border-left:3px solid rgb=
(200,200,200);border-color:rgb(200,200,200);padding-left:10px;color:rgb(102=
,102,102)"><div style=3D"font-family:Arial,sans-serif;font-size:14px"><span=
>It doesn't have to be in EC recovery soft fork, we can enable it in phase =
B, since it is very simple and we have plenty of time to implement and test=
 it. Also it doesn't block anyone and therefore it is much more likely to b=
e adopted than the original approach (block first, recover later, maybe)</s=
pan><br></div></blockquote><div style=3D"font-family:Arial,sans-serif;font-=
size:14px"><br></div><div style=3D"font-family:Arial,sans-serif;font-size:1=
4px">That won't work - If you deploy phase B (restricting EC outputs) with =
bare pubkey commit/reveal <i>without</i> also supporting BIP32 commit/revea=
l for exposed pubkeys, then adding BIP32 commit/reveal later will be a hard=
 fork. You'd be relaxing consensus rules to allow spending of outputs with =
exposed pubkeys.</div></blockquote><div><br></div><div>Both commit-reveal s=
chemes would be deployed simultaneously, but the BIP32 scheme will function=
 forever for all the coins and the pubkey scheme will pause for old coins w=
ith exposed pubkeys after let's say 5 years for another 10 years. For new c=
oins both schemes will work forever.</div><div><br></div><div>For example (=
exact years are just for illustration purposes):</div><div>2025-2030 curren=
t rules work</div><div>2030-2035 both commit-reveal schemes work for all co=
ins, but it is impossible to spend from EC addresses without using a commit=
-reveal scheme anymore. Both schemes are deployed as a softfork, so transac=
tions are still valid from the point of view of old nodes</div><div>2035-20=
45 the pubkey based commit-reveal scheme stops working for existing coins w=
ith exposed pubkeys. BIP32 scheme works and the pubkey scheme works for any=
 new coins (created after 2035). This is the first real confiscatory event,=
 since the pubkey scheme would be the only scheme available for some coins =
in 2035.</div><div>2045-inf the pubkey based scheme is revived</div><div><b=
r></div><div>The whole timeline is applied (in block heights, not years) as=
 a single fork in 2030. Another fork until 2045 can delay pubkey scheme rev=
ival. This is just needed to avoid permanent freeze after which it would be=
 impossible to recover the coins without a hardfork.</div><div> </div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex"><div style=3D"font-family:Aria=
l,sans-serif;font-size:14px"></div><blockquote style=3D"border-left:3px sol=
id rgb(200,200,200);border-color:rgb(200,200,200);padding-left:10px;color:r=
gb(102,102,102)"><div style=3D"font-family:Arial,sans-serif;font-size:14px"=
><span><span>- array of MACs in the order of EC operations in the witness s=
cript</span></span></div></blockquote><div style=3D"font-family:Arial,sans-=
serif;font-size:14px"><br></div><div style=3D"font-family:Arial,sans-serif;=
font-size:14px">Makes sense. At first i was going to suggest to merge the p=
ubkeys together into one single MAC, but that'd create opportunity for mine=
r collusion. You would indeed need one commitment hash per EC operation for=
 watertight security.</div></blockquote><div><br></div><div>One more caveat=
. We should include all the keys exposed in signature or witness of UTXO in=
 the reveal transaction. We can't put the used EC keys only. Imagine a 1/2 =
traditional multisig. Witness has two public keys, but only one signature. =
We should demand both keys in the commitment, because otherwise a quantum a=
ttacker may see the reveal transaction and make a new reveal transaction, u=
sing another EC key of the multisig. The attacker would create a new commit=
 transaction with that malicious reveal TXID and "sign" it with another pub=
lic key (the one not used originally). A validator would accept such a new =
pair of commit and reveal transactions, since they will also check MAC usin=
g the used EC key only, not all the keys. A validator would consider a real=
 commitment invalid and would think that the attacker's commitment is the f=
irst valid one. That is why it is important to put all EC pubkeys mentioned=
 in witness (or traditional signature) of the reveal transaction, not just =
used onces, to prevent such "hijacking".</div><div><br></div><div>Actually,=
 I didn't think about merging keys for MAC. Thanks for sharing the idea! Ca=
n you elaborate why this is not possible, please? Let's say the UTXO has 3 =
different keys in 1/3 traditional multisig. Can't we just combine them some=
how, e.g. XOR or hash-and-XOR and use the result as a key for MAC? An attac=
ker doesn't control these values and he doesn't control the script (unless =
multiple reveal transactions with different tapleaves were published, which=
 is not allowed in such schemes). So until the reveal transaction is publis=
hed the attacker can't forge commits. And once the reveal tx is published i=
t doesn't make sense to forge, because it won't be the first valid commit. =
I don't see any vulnerability which is created by merging keys for MAC.</di=
v><div> </div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style=
=3D"font-family:Arial,sans-serif;font-size:14px"></div><div style=3D"font-f=
amily:Arial,sans-serif;font-size:14px">For single-party BIP32 commit/reveal=
 on the other hand, you'd probably never need more than 1 MAC per commitmen=
t, since the xpriv would probably cover every EC operation in the reveal TX=
 (even across multiple UTXOs), and any given pubkey has at most one matchin=
g parent xpriv (if hardening is done only once).</div></blockquote><div><br=
></div><div>Yes. Note that in the BIP32 variant the reveal transaction has =
to include all derivation paths though, for every pubkey that is mentioned =
in the script.</div><div> </div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef=
t:1ex"><div style=3D"font-family:Arial,sans-serif;font-size:14px"></div><di=
v style=3D"font-family:Arial,sans-serif;font-size:14px">To confirm, when va=
lidating a commitment that contains multiple MACs, the validator would need=
 to assert that <i>every</i> MAC is the earliest valid MAC, right? If even =
one pubkey was exposed and committed earlier, it'd render the whole reveal =
TX invalid.</div></blockquote><div><br></div><div>When validating a reveal =
transaction, a validator first collects all EC pubkeys from the script; not=
 only used keys, but all - see above why. Then the validator loads all the =
commitments that were posted for that UTXO. Commitments may have this TXID =
or different TXID; the validator has to load all regardless of TXID. Then t=
he validator goes through all the commitments and checks MACs. If the numbe=
r of MACs doesn't match the number of EC pubkeys - exclude the commitment. =
Otherwise go through MACs and pubkeys one by one and check each MAC against=
 the corresponding key. Cleartext for MAC is the TXID from that commitment.=
 If any MAC doesn't verify - exclude the commitment. The remaining commitme=
nts passing these checks are valid. Check the first valid commitment. If it=
 has TXID not matching TXID of the reveal transaction - fail the reveal tx =
validation.</div><div><br></div><div>An attacker can't copy MACs because th=
ey are bound to TXID of the original commitment and that TXID is legit. So =
we don't worry if we see one valid MAC in another commitment. To make the w=
hole commitment valid an attacker has to copy-paste the whole commitment, w=
hich doesn't change anything - the list of commitments would have two ident=
ical valid commitments.</div><div><br></div><div>I propose to simplify this=
 by using just one MAC with all the pubkeys as a single key. If you know wh=
y this is a bad idea, please share.</div><div><br></div><div>Best,</div><di=
v>Boris</div><div></div><div><br></div><div><br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex"><div style=3D"font-family:Arial,sans-serif;fon=
t-size:14px"></div><div style=3D"font-family:Arial,sans-serif;font-size:14p=
x">regards,</div><div style=3D"font-family:Arial,sans-serif;font-size:14px"=
>conduition</div><div>
        On Monday, July 28th, 2025 at 5:07 PM, Nagaev Boris &lt;<a href=3D"=
mailto:bnagaev@gmail.com" target=3D"_blank" rel=3D"noreferrer nofollow noop=
ener">bnagaev@gmail.com</a>&gt; wrote:<br>
        <blockquote type=3D"cite">
            <div dir=3D"ltr"><div>Hey Conduition,</div><br><div class=3D"gm=
ail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Jul 28, 2025 at 6:=
38=E2=80=AFPM conduition &lt;<a href=3D"mailto:conduition@proton.me" rel=3D=
"noreferrer nofollow noopener" target=3D"_blank">conduition@proton.me</a>&g=
t; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div s=
tyle=3D"font-family:Arial,sans-serif;font-size:14px">Hey Boris,</div><div s=
tyle=3D"font-family:Arial,sans-serif;font-size:14px"><br></div><div style=
=3D"font-family:Arial,sans-serif;font-size:14px"><span>I've been doing more=
 research into ZK-STARK solutions, and the more i read, the more I am warmi=
ng to the idea of BIP32 commit/reveal as a recovery mechanism. The smallest=
 concrete zk-STARK proofs I could find were hundreds of kilobytes for even =
something as simple as a SHA512 hash preimage. BIP32 proofs would need that=
, plus secp256k1 arithmetic.</span></div></blockquote><div><br></div><div>A=
FAIK, the size of a STARK is a polylog of the evaluation trace. So even if =
a single SHA512 evaluation costs several hundreds of <span>kilobytes, maybe=
 we can fit many signatures into a single STARK, since logarithm grows very=
 slowly. Maybe even more than we have now. We may have a single STARK per b=
lock which validates all the stuff: recovery and PQ signatures. However I'm=
 not an expert in STARKs, just starting to learn them. But I hope STARKs ar=
e a real thing!</span></div><div> </div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex"><div style=3D"font-family:Arial,sans-serif;font-size:14px"><=
/div><blockquote style=3D"border-left:3px solid rgb(200,200,200);border-col=
or:rgb(200,200,200);padding-left:10px;color:rgb(102,102,102)"><div style=3D=
"font-family:Arial,sans-serif;font-size:14px"><span>We only need a symmetri=
c equivalent of a digital signature (i.e. MAC) and a secure hash function. =
This is very exciting! The scheme can function as a backup plan in case we =
don't find a way to scale regular post-quantum signatures. Imagine the futu=
re in which we use expensive SPHINCS+ signatures for time-sensitive stuff a=
nd a cheap commit-reveal scheme for slow transactions.</span><br></div></bl=
ockquote><div style=3D"font-family:Arial,sans-serif;font-size:14px"><br></d=
iv><div style=3D"font-family:Arial,sans-serif;font-size:14px">Don't get too=
 excited - Commit/reveal protocols on bitcoin presuppose the availability o=
f a post-quantum signature scheme. Otherwise, how do you publish the commit=
ment TX securely? The commitment phase itself is a published BTC transactio=
n, and if that TX is secured via EC signatures, then its inputs could be sw=
iped by a fast CRQC.</div></blockquote><div><br></div><div>I understand :)<=
/div><div><br></div><div>But I'm happy that at least we have secured one sa=
fe and affordable way to use Bitcoin in the post-quantum era: using the com=
mit-reveal scheme and PQ to send commit transactions. Commits can be batche=
d in a single transaction. Everyone having PQ funds could run a small busin=
ess publishing commits for other people for a fee. Not an ideal world, but =
it is functional and scales without a block size increase. Having a way to =
compress PQ signatures (e.g. STARK) would be cooler, but the commit-reveal =
scheme is a strong plan B in case something goes wrong with that approach.<=
/div><div> </div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div sty=
le=3D"font-family:Arial,sans-serif;font-size:14px"></div><blockquote style=
=3D"border-left:3px solid rgb(200,200,200);border-color:rgb(200,200,200);pa=
dding-left:10px;color:rgb(102,102,102)"><div style=3D"font-family:Arial,san=
s-serif;font-size:14px"><span>We need to ensure that the scheme accepts onl=
y a single xpriv+path value. If there are multiple combinations possible (i=
.e. starting from different levels of derivation), then a validator wouldn'=
t be able to determine if a commit is valid afterwards.</span><br></div></b=
lockquote><div style=3D"font-family:Arial,sans-serif;font-size:14px"><span>=
<br></span></div><div style=3D"font-family:Arial,sans-serif;font-size:14px"=
>I'm not sure I understand the problem... Wouldn't this just mean that ther=
e can be more than one valid commitment for the same UTXO? That's always go=
ing to be possible because the owner could commit to more than one reveal t=
ransaction. <span style=3D"display:inline;background-color:rgb(255,255,255)=
">We can't verify commitments for reveal TXs which are never published.</sp=
an> Which is fine - validators just care whether the sender knew a valid pa=
rent xpriv <i>before</i> the reveal TX was published.</div></blockquote><di=
v><br></div><div>We can't let multiple commits per UTXO be valid. Remember =
the original problem you posted a couple of messages ago: miners can collud=
e and delay reveal transaction confirmation, so we need to make sure that t=
he commitment of this reveal tx is the first valid commitment for this UTXO=
. How can a validator verify other commitments posted for the UTXO? They ne=
ed to know the key used for MAC to check it. If the MAC key is not fixed pe=
r UTXO, this doesn't work: we can't check whether other commitments are val=
id, so we can't guarantee that the commitments of this reveal tx comes from=
 the owner, not from a collusion of malicious miners who delayed the legiti=
mate reveal transaction and made another commit tx using the private data f=
rom legitimate reveal tx.</div><div> </div><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);=
padding-left:1ex"><div style=3D"font-family:Arial,sans-serif;font-size:14px=
"></div><div style=3D"font-family:Arial,sans-serif;font-size:14px">Now that=
 I think about it, we safely can omit the bip32 key paths from the HMAC com=
mitment. They serve no purpose there. </div></blockquote><div><br></div><di=
v>Yes, we can use the latest input of SHA512 during BIP32 key derivation as=
 a MAC key. The reveal tx will have both the preimage and the BIP 32 path t=
hat should lead to the pubkey.</div><div> </div><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,=
204);padding-left:1ex"><div style=3D"font-family:Arial,sans-serif;font-size=
:14px"></div><blockquote style=3D"border-left:3px solid rgb(200,200,200);bo=
rder-color:rgb(200,200,200);padding-left:10px;color:rgb(102,102,102)"><div =
style=3D"font-family:Arial,sans-serif;font-size:14px"><span>Coins whose pri=
vate key is not a child of BIP32. One important instance is MuSig2 coins.</=
span><br></div></blockquote><div style=3D"font-family:Arial,sans-serif;font=
-size:14px"><br></div><div style=3D"font-family:Arial,sans-serif;font-size:=
14px">Also FROST keys, ECDSA threshold MPC keys, paper wallets, and many ot=
hers. I'm really not sure how we'd handle these. The lazy dev inside me wan=
ts to ignore them and focus on BIP32 wallets as that probably will make up =
the bulk volume of coins affected by an EC freeze.</div><div style=3D"font-=
family:Arial,sans-serif;font-size:14px"><br></div><div style=3D"font-family=
:Arial,sans-serif;font-size:14px">MuSig is an interesting special case, bec=
ause the aggregation of the group key is actually a quantum resistant one-w=
ay function. More concretely, given the musig group key <code>X =3D H(L, A)=
*A + H(L, B)*B</code> then a QC cannot practically compute a valid key set =
<code>L =3D [A, B]</code>. So you could make a commit/reveal scheme for MuS=
ig keys by committing to (and then revealing) the key set <code>L</code>. N=
odes verify the group key <code>X</code> was computed correctly from <code>=
L</code>. We'd have to assume that key set <code>L</code> is not available =
to a quantum attacker. No secret key sharing is needed for this.</div><div =
style=3D"font-family:Arial,sans-serif;font-size:14px"><br></div><div style=
=3D"font-family:Arial,sans-serif;font-size:14px">FROST is not so fortunate.=
 A FROST key is just the constant term of a polynomial. Any quantum attacke=
r could invert a public key, and then forge an arbitrary polynomial with th=
at key as its constant term.</div><div style=3D"font-family:Arial,sans-seri=
f;font-size:14px"><br></div><div style=3D"font-family:Arial,sans-serif;font=
-size:14px">I wouldn't worry too much about untrusting multisig groups thou=
gh - such wallets are usually actively managed, so the parties involved wou=
ld likely be active enough to migrate their coins to post-quantum addresses=
 before any EC-restricting soft forks occur. Then again, this is just an op=
inion, no hard data to work with here.</div></blockquote><div><br></div><di=
v>I guess inheritance schemes may use MuSig2 in a tap leaf with a timelock.=
 MuSig2 is used, because it is more efficient; the timelock is just a prote=
ction. However if we keep the pubkey commit-reveal scheme for a while (see =
below), we won't need a separate scheme for MuSig2.</div><div> </div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex"><div style=3D"font-family:Arial=
,sans-serif;font-size:14px"></div><div style=3D"font-family:Arial,sans-seri=
f;font-size:14px">Ancient paper wallet holders on the other hand are much m=
ore at risk, since these keys were often generated without BIP39 or BIP32. =
This might be one reason why allowing commit/reveal with bare pubkeys could=
 be beneficial, but IDK if it outweighs the complexity costs.</div><div sty=
le=3D"font-family:Arial,sans-serif;font-size:14px"><br></div><blockquote st=
yle=3D"border-left:3px solid rgb(200,200,200);border-color:rgb(200,200,200)=
;padding-left:10px;color:rgb(102,102,102)"><div style=3D"font-family:Arial,=
sans-serif;font-size:14px"><span>Some xpubs may have too many coins to swee=
p in a single transaction.</span><br></div></blockquote><div style=3D"font-=
family:Arial,sans-serif;font-size:14px"><br></div><div style=3D"font-family=
:Arial,sans-serif;font-size:14px">This should be a pretty rare edgecase - b=
ut even in those cases, as you say, we can work around it by splitting up t=
he reveal TX into multiple transactions and committing to each of them. The=
n wait a few blocks, and publish all reveal TXs at once.</div><div style=3D=
"font-family:Arial,sans-serif;font-size:14px"><br></div><blockquote style=
=3D"border-left:3px solid rgb(200,200,200);border-color:rgb(200,200,200);pa=
dding-left:10px;color:rgb(102,102,102)"><div style=3D"font-family:Arial,san=
s-serif;font-size:14px"><span>Note that the BIP32 scheme requires attaching=
 additional data (xprivs + derivation paths) to a reveal transaction. ... W=
e can make another Merkle tree similar to Segwit and put it there.</span><b=
r></div></blockquote><div style=3D"font-family:Arial,sans-serif;font-size:1=
4px"><br></div><div style=3D"font-family:Arial,sans-serif;font-size:14px">S=
ame would be true of any PICNIC or zk-STARK based solution. It's unavoidabl=
e if we want an EC recovery soft fork.</div></blockquote><div><br></div><di=
v>It can be avoided in my original scheme using pubkey as MAC key. In this =
scheme, the reveal tx is just a regular transaction, no extra data needed. =
Everything needed to validate the commitment (the pubkey) is in the reveal =
transaction itself. It makes the scheme compatible with any modern transact=
ion types and saves block space. The only downside is that it is not secure=
 in case the pubkey leaks.</div><div><br></div><div>It doesn't have to be i=
n EC recovery soft fork, we can enable it in phase B, since it is very simp=
le and we have plenty of time to implement and test it. Also it doesn't blo=
ck anyone and therefore it is much more likely to be adopted than the origi=
nal approach (block first, recover later, maybe). At the same time the publ=
ic key commit-reveal scheme saves a lot of coins in case of a quantum emerg=
ency, so it is definitely much better than doing nothing. If a person advoc=
ates to block vulnerable coins because of the price effect, they should sup=
port this scheme too, because it reduces dramatically the amount of vulnera=
ble coins. Maybe this is the focal point?</div><div><br></div><div><br></di=
v><div>BTW in both schemes we should think abouts UTXOs which have multiple=
 public keys and signatures: traditional multisigs, some smart scripts. All=
 EC signatures used in the script must have a commitment. But how to find w=
hich commitment is for which pubkey? Remember we should find all valid comm=
itments and check that this one is the first... Just check all against all?=
 It is O(N^2), where N is the number of EC signatures per witness. I propos=
e to change the format of the commitment OP_RETURN to this:</div><div><br><=
/div><div> - UTXO</div><div> - TXID</div><div> - array of MACs in the order=
 of EC operations in the witness script</div><div> </div><div>This is also =
more space efficient, because UTXO and TXID will be the same, only the MAC =
part is different.</div><div><br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex"><div style=3D"font-family:Arial,sans-serif;font-size:14px"></=
div><blockquote style=3D"border-left:3px solid rgb(200,200,200);border-colo=
r:rgb(200,200,200);padding-left:10px;color:rgb(102,102,102)"><div style=3D"=
font-family:Arial,sans-serif;font-size:14px"><span>Both of them can be prov=
ided but the pubkey-based scheme will be blocked for coins whose pubkeys we=
re exposed in the past. All such coins can be found once, at the fork time,=
 and future pubkey exposures can be ignored.</span><br></div></blockquote><=
div style=3D"font-family:Arial,sans-serif;font-size:14px"><span><br></span>=
</div><div style=3D"font-family:Arial,sans-serif;font-size:14px"><span>This=
 scan would miss a lot of exposed pubkeys - xpubs and other public keys sha=
red off-chain for high-value wallets would become highly valuable commoditi=
es that could be sold to quantum attackers. But i guess it is doable. I'm n=
ot sure if its benefits  outweigh its drawbacks. Basically it's a pick-your=
-poison choice between (1) <span style=3D"display:inline;background-color:r=
gb(255,255,255)">allowing</span> QCs to steal from pubkeys exposed off-chai=
n, or (2) destroying the coins of <span style=3D"display:inline;background-=
color:rgb(255,255,255)">paper/brain wallet hodlers (or anyone else who didn=
't use BIP32).</span></span></div></blockquote><div><br></div><div>Yes, thi=
s is a hard choice. Maybe there is a compromise solution: the pubkey scheme=
 can function for old coins for a limited amount of time. We'll hope that q=
uantum attacks won't happen during that period. It will be sufficient for o=
wners of paper wallets to move their funds. Then the pubkey scheme will sta=
y disabled for old coins for 10 years. (Remember my another proposal to rep=
lace a permanent block with a long temporary block, this consideration is a=
pplicable here as well.) The BIP32 scheme can be used for such coins at any=
 time. New coins should be good to use with the pubkey scheme, since it wou=
ld be the responsibility of the coin owner not to expose public keys when t=
he quantum threat is high.</div><div><br></div><div>Best,</div><div>Boris</=
div><div> </div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div styl=
e=3D"font-family:Arial,sans-serif;font-size:14px"></div><div style=3D"font-=
family:Arial,sans-serif;font-size:14px">regards,</div><div style=3D"font-fa=
mily:Arial,sans-serif;font-size:14px">conduition</div><div>
        On Friday, July 25th, 2025 at 7:17 PM, Nagaev Boris &lt;<a href=3D"=
mailto:bnagaev@gmail.com" rel=3D"noreferrer nofollow noopener" target=3D"_b=
lank">bnagaev@gmail.com</a>&gt; wrote:<br>
        <blockquote type=3D"cite">
            <div dir=3D"ltr"><div dir=3D"ltr"><div>Hi Conduition,</div><div=
><br></div><div>Thanks for pushing it forward! Interestingly, we don't real=
ly need EC crypto to organize a payment scheme. We only need a symmetric eq=
uivalent of a digital signature (i.e. MAC) and a secure hash function. This=
 is very exciting! The scheme can function as a backup plan in case we don'=
t find a way to scale regular post-quantum signatures. Imagine the future i=
n which we use expensive SPHINCS+ signatures for time-sensitive stuff and a=
 cheap commit-reveal scheme for slow transactions. We can have a single typ=
e of address which supports both types of spending: (1) expensive and fast,=
 (2) cheap and slow.</div><div><br></div><div>Switching back to coin recove=
ry, there are a few challenges. I have thoughts on how to solve some of the=
m.</div><div><br></div><div>1. We need to ensure that the scheme accepts on=
ly a single xpriv+path value. If there are multiple combinations possible (=
i.e. starting from different levels of derivation), then a validator wouldn=
't be able to determine if a commit is valid afterwards. Another commit may=
 be valid, but made with a different xpriv+path input, so MAC won't verify.=
 I think we can ensure that xpriv+path is unique by demanding that the path=
 starts with a hardened step (i.e. hashing) and has no other hardened steps=
.</div><div><br></div><div>2. Coins whose private key is not a child of BIP=
32. One important instance is MuSig2 coins. In MuSig2 several private keys =
are generated by different parties, probably from different BIP32 parents, =
but I know of at least one case where completely different approach was cho=
sen for derivation of a partial key. So there is no single BIP32 parent of =
MuSig2 addresses. Another obstacle is MAC generation if parties don't trust=
 each other and don't want to share xprivs with each other. Maybe the schem=
e can be changed to pass xpriv through a tagged hash function prior to usin=
g it as a key in MAC to address this.</div><div><br></div><div>Maybe taproo=
t addresses should have a special approach, because they have a key path sp=
end which is unique among all address types.</div><div><br></div><div>3. So=
me xpubs may have too many coins to sweep in a single transaction. Since th=
e BIP32 scheme exposes private xpriv in a reveal transaction, to sweep all =
the coins the owner has to first send all commit transactions that would co=
ver all future sweep (reveal) transactions. If this is done one by one (com=
mit1-reveal1-commit2-reveal2), then the remaining funds can be stolen by an=
yone, since the xpriv of the whole group is exposed.</div><div><br></div><d=
iv>4. Note that the BIP32 scheme requires attaching additional data (xprivs=
 + derivation paths) to a reveal transaction. This is an additional burden =
compared with the pubkey scheme. We need to find a place to put the additio=
nal data along with the reveal transaction without modifying the TXID. That=
 is why we can't put it into OP_RETURN. We can't put it into Witness, since=
 it would break the signature - we can't do it, if we want it to be a softf=
ork. We can make another Merkle tree similar to Segwit and put it there.</d=
iv><div><br></div><div>It seems that BIP32 and pubkey-based schemes have di=
fferent trade-offs. Both of them can be provided but the pubkey-based schem=
e will be blocked for coins whose pubkeys were exposed in the past. All suc=
h coins can be found once, at the fork time, and future pubkey exposures ca=
n be ignored. It would involve reprocessing of all blocks, but this is a so=
lvable technical issue, e.g. we can give nodes time to precalculate this da=
ta before validation rules change. The logic is that if someone exposed the=
ir pubkey in the post-quantum era it's their own fault and it is the same a=
s if they exposed their private key now. So it is justifiable if a quantum =
attacker captures such coins - it is not the business of the network to sec=
ure funds in this case.</div><div><br></div><div>Best,</div><div>Boris</div=
><div><br></div><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_=
attr">On Fri, Jul 25, 2025 at 2:56=E2=80=AFPM conduition &lt;<a href=3D"mai=
lto:conduition@proton.me" rel=3D"noreferrer nofollow noopener" target=3D"_b=
lank">conduition@proton.me</a>&gt; wrote:<br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex"><div style=3D"font-family:Arial,sans-serif;font-s=
ize:14px">Hi Boris,</div><div style=3D"font-family:Arial,sans-serif;font-si=
ze:14px"><br></div><div style=3D"font-family:Arial,sans-serif;font-size:14p=
x">That sound workable, it's similar to other commit/reveal protocols. I ha=
ve no problem with these, they're perfectly valid ways to encumber coins. T=
he only issue I see with your suggested protocol is that it's only secure w=
hen pubkeys are still hidden. A quantum attacker could still commit, reveal=
, and steal coins from addresses whose pubkeys are already exposed.</div><d=
iv style=3D"font-family:Arial,sans-serif;font-size:14px"><br></div><div sty=
le=3D"font-family:Arial,sans-serif;font-size:14px">As Or and Shai's paper h=
as shown, we can fix that by modifying the scheme to include a BIP32 parent=
 xpriv in the commit TX, rather than a bare pubkey. For the sake of simplic=
ity, this should probably be the only commitment method available. If we al=
so allowed bare pubkey commitments, validating nodes would have to keep tra=
ck of whether or not an address's pubkey has been exposed in the past, and =
determine what types of commit/reveal spends to allow. Using just one metho=
d keeps things simpler.</div><div style=3D"font-family:Arial,sans-serif;fon=
t-size:14px"><br></div><div style=3D"font-family:Arial,sans-serif;font-size=
:14px">So the protocol becomes:</div><div style=3D"font-family:Arial,sans-s=
erif;font-size:14px"><br></div><div style=3D"font-family:Arial,sans-serif;f=
ont-size:14px">The commit_tx includes:<div><br></div><div><span>1.  UTXO</s=
pan></div><div><span>2.  TXID</span></div><div><span>3.  MAC(TXID, key=3D<b=
>bip32_xpriv_and_keypaths</b>)</span></div><div><br></div>The reveal transa=
ction must attach the <b style=3D"background-color:rgb(255,255,255)">bip32_=
xpriv_and_keypaths</b><span style=3D"background-color:rgb(255,255,255)"> so=
 validators can check the MAC.</span><br></div><div style=3D"font-family:Ar=
ial,sans-serif;font-size:14px"><br></div><div style=3D"font-family:Arial,sa=
ns-serif;font-size:14px">Because this exposes the wallet's BIP32 parent key=
, we have to consider how to handle multi-input transactions, which would m=
igrate the wallet's entire set of quantum-vulnerable UTXOs at once. Do i ne=
ed to make a separate commit TX or OP_RETURN output for each UTXO i spend, =
each committing to the same TXID? Can i aggregate them together into one co=
mmitment somehow with a merkle tree?</div><div style=3D"font-family:Arial,s=
ans-serif;font-size:14px"><br></div><div style=3D"font-family:Arial,sans-se=
rif;font-size:14px">These are all addressable problems, of course. I just h=
aven't seen them all addressed in one place yet. The solutions are scattere=
d through the mailing list and through papers like Or's. A comprehensive so=
lution needs to have all these edgecases accounted for in a single concise =
protocol.</div><div style=3D"font-family:Arial,sans-serif;font-size:14px"><=
br></div><div style=3D"font-family:Arial,sans-serif;font-size:14px">regards=
,</div><div style=3D"font-family:Arial,sans-serif;font-size:14px">conduitio=
n</div><div style=3D"font-family:Arial,sans-serif;font-size:14px"><br></div=
><div style=3D"font-family:Arial,sans-serif;font-size:14px"><br></div><div>
        On Sunday, July 20th, 2025 at 1:21 PM, Boris Nagaev &lt;<a href=3D"=
mailto:bnagaev@gmail.com" rel=3D"noreferrer nofollow noopener" target=3D"_b=
lank">bnagaev@gmail.com</a>&gt; wrote:<br>
        <blockquote type=3D"cite">
            Hi Conduition,<br><br>Let's consider this scheme:<br><br>The co=
mmit_tx includes:<br><ol><li>UTXO  </li><li>TXID  </li><li>MAC(TXID, key=3D=
pubkey)</li></ol>The reveal transaction is just a normal Bitcoin transactio=
n.<br><br>Validators would need to maintain a list of commitments per UTXO =
and only accept a reveal transaction that is the earliest one with a valid =
MAC. A validator of the reveal transaction sees the pubkey and can verify t=
he MAC. A validator filters the list of commitments, keeping only the valid=
 ones, and then selects the earliest among them. The reveal transaction mus=
t match the TXID from the winning commitment.<br><br>If someone tries to st=
eal the coin, they would need to publish another commit transaction for the=
 same UTXO. But without knowing the pubkey, how can they produce a valid MA=
C? They can't. All they can do is spam invalid commit transactions, which w=
ould have no effect. Even if malicious miners wait until a legitimate revea=
l transaction is published and then create a valid commit transaction, it w=
ould not be the earliest valid one. The earliest valid commit would still b=
e the original one.<br><br>The downside is that this scheme requires storin=
g all commitments (valid or not) until the coin is spent. Maybe the list ca=
n be compressed or pruned. Another limitation is that the reveal transactio=
n must be fully constructed at the time of the commit, since its TXID is pa=
rt of the commitment. This means the sender cannot adjust the reveal transa=
ction later, not even to change the fee or use RBF. That said, maybe the re=
quirement to know the TXID upfront could be relaxed with a different constr=
uction.<br><br>Best,<br>Boris<div><br></div><br><div><div dir=3D"auto">On S=
unday, July 20, 2025 at 2:48:22=E2=80=AFPM UTC-3 conduition wrote:<br></div=
><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex"><div style=3D"font-family:Arial,sans-serif;fon=
t-size:14px">Hi Or,</div><div style=3D"font-family:Arial,sans-serif;font-si=
ze:14px"><br></div><blockquote style=3D"border-left:3px solid rgb(200,200,2=
00);border-color:rgb(200,200,200);padding-left:10px;color:rgb(102,102,102)"=
><div style=3D"font-family:Arial,sans-serif;font-size:14px"><span>Are you a=
sking what happens if the =E2=80=9Creveal=E2=80=9D part of a Lifted FawkesC=
oin is censored by all the miners?</span></div><div style=3D"font-family:Ar=
ial,sans-serif;font-size:14px"><br></div><div style=3D"font-family:Arial,sa=
ns-serif;font-size:14px"><span>Indeed, if all miners collude and decide to =
censor the "reveal" part of the transaction, they will be able to claim the=
 pre-quantum OTXO themselves. But even today, if all (or a majority of) min=
ers collude, double-spends are already possible.</span><br></div></blockquo=
te><div><span><br></span></div><div><span>Yes, that's my question. There is=
 a big difference between this and a double-spend attack.</span></div><div>=
<span><br></span></div><div><span>A double-spend attack involves exercising=
 enormous hashpower in a 51% attack to orphan an existing block and "undo" =
a transaction which the network previously saw as valid. Any gains from the=
 double-spend attack would be offset by the cost of electricity wasted by m=
ining the new block, and by the fees/block-reward lost in the orphaned bloc=
k. </span><span style=3D"font-size:0.875rem">And even then, the attacking m=
iners have gained no new bitcoin - They probably only gained something off-=
chain, of equivalent value to the coins they double-spent. For instance, th=
ey may have deposited into an exchange and converted their double-spent coi=
ns into some other currency.</span></div><div><span><br></span></div><div>B=
y contrast, censoring a lifted fawkescoin reveal TX requires no hashpower. =
It only requires collusion between miners to agree not to mine specific tra=
nsactions. If they do this, they can swipe the vulnerable users' bitcoins w=
ith no real-world energy expenditure or on-chain losses. </div><div><br></d=
iv><div>Unless i'm mistaken there, I'd say this property makes Lifted Fawke=
sCoin a non-starter.</div><div><br></div><div>Restrictive <span style=3D"di=
splay:inline;background-color:rgb(255,255,255)">FawkesCoin</span> could be =
a viable option. It's about the same as any other commit/reveal protocol ex=
cept that you've thought out how to rescue funds with exposed pubkeys, by p=
roviding a BIP32 parent xpriv in the reveal TX. This is great but does impl=
icitly require that the coins must be restricted such that the QC attacker =
can't use a regular EC signature to steal them first. That requirement woul=
d be needed for any protocol that rescues UTXOs with exposed pubkeys of cou=
rse. <span style=3D"font-size:0.875rem">You're right that this would be sim=
pler to implement than zk-STARKs, so maybe I spoke too soon.</span></div><d=
iv><br></div><div>regards,</div><div>conduition</div><div><br></div><div></=
div><div>
        On Thursday, July 17th, 2025 at 6:54 AM, Or Sattath &lt;<a rel=3D"n=
oreferrer nofollow noopener">sat...@gmail.com</a>&gt; wrote:<br>
        </div><div><blockquote type=3D"cite">
            <div>Dear conduition,</div><div><br style=3D"font-family:Arial,=
sans-serif"></div><br><div><div dir=3D"auto">On Tuesday, July 15, 2025 at 4=
:57:23=E2=80=AFPM UTC+3 conduition wrote:<br></div><blockquote style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex"><div style=3D"font-family:Arial,sans-serif;font-size:14px">Thanks for p=
ointing this out Or. For those not familiar with Or's approach, it would sh=
are many of the same properties as the folklore BIP39 zk-STARK approach dis=
cussed elsewhere. It uses Picnic in the same way, to prove (in zero-knowled=
ge) either:</div><div style=3D"font-family:Arial,sans-serif;font-size:14px"=
><br></div><div style=3D"font-family:Arial,sans-serif;font-size:14px"><ul s=
tyle=3D"margin-top:0px;margin-bottom:0px"><li style=3D"list-style-type:&quo=
t;- &quot;"><span>(For UTXOs whose pubkeys are exposed) I know a BIP39 seed=
 that derives an EC secret key such that <span>hash160(pubkey(ec_secret)) =
=3D=3D &lt;hash&gt;</span></span></li><li style=3D"list-style-type:&quot;- =
&quot;"><span>(For UTXOs whose pubkeys are still secret) I know a public ke=
y such that <span>hash160(pubkey) =3D=3D &lt;hash&gt;</span><br></span></li=
></ul></div><div style=3D"font-family:Arial,sans-serif;font-size:14px"><br>=
</div><div style=3D"font-family:Arial,sans-serif;font-size:14px">From <a hr=
ef=3D"https://eprint.iacr.org/2023/362.pdf" title=3D"Or's paper" rel=3D"nor=
eferrer nofollow noopener" target=3D"_blank">Or's paper</a>, section 2.5:</=
div><div style=3D"font-family:Arial,sans-serif;font-size:14px"><br></div><b=
lockquote style=3D"border-left:3px solid rgb(200,200,200);border-color:rgb(=
200,200,200);padding-left:10px;color:rgb(102,102,102)"><div style=3D"font-f=
amily:Arial,sans-serif;font-size:14px"><span>Spending Hashed UTXOs: To spen=
d a hashed UTXO, the user signs it with a key-lifted </span><span>signature=
 (see Section 2.2).</span></div><div style=3D"font-family:Arial,sans-serif;=
font-size:14px"><br></div><div style=3D"font-family:Arial,sans-serif;font-s=
ize:14px"><div><span><span>Spending Derived UTXOs: To spend a derived UTXO,=
 the user signs it with a seed-lifted </span><span>signature (see Section 2=
.3).</span></span></div></div></blockquote><div><span><span><br></span></sp=
an></div><div style=3D"font-family:Arial,sans-serif;font-size:14px"><div><s=
pan><span>I see a couple problems with this. We won't be able to straight-u=
p replace the EC signature with a Picnic signature without a hard fork. Old=
 Bitcoin clients will still need to see a valid EC signature and verify <sp=
an>hash160(pubkey) =3D=3D &lt;hash&gt;</span> by classical re-computation. =
This exposes the EC pubkey, which would let a QC attacker forge new key-lif=
ted signatures. Thus, sadly, we can't rely on key-lifted signatures.</span>=
</span></div></div></blockquote><blockquote style=3D"margin:0px 0px 0px 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style=3D"f=
ont-family:Arial,sans-serif;font-size:14px"><div><span><span><br></span></s=
pan></div><div>That said, we don't <i>always</i> require a hard fork as you=
 note in the paper. It's totally fine to expose the EC signature and pubkey=
 <i>if</i> we also have a way to prove honest derivation of the EC secret k=
ey from a seed, and as long as that proof commits to the same transaction. =
Either seed-lifted Picnic signatures or ZK-STARKs could  satisfy this. To g=
et soft-fork backwards-compatibility, we'd introduce a new transaction data=
 field to carry the proof, much like segwit added the witness data field. T=
hen we require new clients to reject any EC signatures unless accompanied b=
y this "proof-of-seed-derivation". Old clients still see valid EC spend TXs=
. Soft fork achieved.</div><div><br></div><div><span style=3D"display:inlin=
e;background-color:rgb(255,255,255)">As for the "Lifted FawkesCoin" commit/=
reveal protocol, it has some issues. I think it'd require a hard fork to im=
plement as there are some properties of the protocol which we can't enforce=
 without relaxing consensus rules. For example, letting miners claim UTXOs =
using the post-quantum proofs of ownership:</span><br></div><div><span styl=
e=3D"display:inline;background-color:rgb(255,255,255)"><br></span></div><bl=
ockquote style=3D"border-left:3px solid rgb(200,200,200);border-color:rgb(2=
00,200,200);padding-left:10px;color:rgb(102,102,102)"><div><span>After the =
commitment has been posted, the spender has a limited time to post a reveal=
 of the </span>commitment to the blockchain. If they fail to do so, the min=
er can post the proof of ownership<span>to claim the entire UTXO, making sp=
am attempts costly </span></div></blockquote><div><span><br></span></div><d=
iv><span>This is impossible without relaxing consensus rules on existing UT=
XOs' script pubkeys. Donating half of a TX's mining fees to an unrelated mi=
ner would also need a hard fork:</span></div><div><span><br></span></div><b=
lockquote style=3D"border-left:3px solid rgb(200,200,200);border-color:rgb(=
200,200,200);padding-left:10px;color:rgb(102,102,102)"><div><span><span>The=
 fee paid for including tx is split equally between the miner who </span><s=
pan>included tx and the miner who included (H(tx))</span><br></span></div><=
/blockquote><div><span style=3D"font-family:Roboto,RobotoDraft,Helvetica,Ar=
ial,sans-serif"> </span></div></div></blockquote><blockquote style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
"><div style=3D"font-family:Arial,sans-serif;font-size:14px"><div></div><di=
v>(though this might be fixable if you modify the protocol to instead requi=
re direct payment to the address of the miner who mined the H(tx) commitmen=
t.)</div><div><br></div></div></blockquote><div><br></div><div><div>The tab=
le on p. 11 <a href=3D"https://eprint.iacr.org/2023/362.pdf" rel=3D"norefer=
rer nofollow noopener" target=3D"_blank">here</a> (which is key to understa=
nding the different trade-offs of the different methods) indicates which me=
thods work as a soft-fork out of the box:</div><div><img alt=3D"Screenshot =
2025-07-17 at 11.04.00.png" width=3D"1518px" height=3D"1590px" class=3D"pro=
ton-embedded" src=3D"cid:ii_198540da0f2e32adf7e1"><br></div><div><br></div>=
You=E2=80=99re right that Lifted Spending (Section 2.2 &amp; 2.3) and Lifte=
d Fawkes-Coin use a hard fork. I suspect that some of the other methods cou=
ld potentially be implemented as a soft fork, using various tricks=E2=80=94=
along the lines of the ideas you=E2=80=99re suggesting. Our rationale was t=
o avoid overcomplicating the paper in order to make it soft-fork-compatible=
.</div><div> </div><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t:1px solid rgb(204,204,204);padding-left:1ex"><div style=3D"font-family:Ar=
ial,sans-serif;font-size:14px"><div></div><div>The other problem is incenti=
ves. Why would miners ever mine a Lifted FawkesCoin reveal TX if they could=
 simply wait and claim the pre-quantum UTXO themselves using the proof of o=
wnership? The protocol seems to rely on miners ignoring this opportunity, o=
r at least that the major mining pools won't collude to exploit it. </div><=
/div></blockquote><div><br></div><div>I=E2=80=99m not sure I fully understa=
nd your point. Are you asking what happens if the =E2=80=9Creveal=E2=80=9D =
part of a Lifted FawkesCoin is censored by all the miners?<br>Indeed, if al=
l miners collude and decide to censor the "reveal" part of the transaction,=
 they will be able to claim the pre-quantum OTXO themselves. But even today=
, if all (or a majority of) miners collude, double-spends are already possi=
ble.<br>Recall that there's a period of 100 blocks (see p. 20, especially s=
tep 7) for miners to include the "reveal". It is sufficient for just one ho=
nest miner to include the =E2=80=9Creveal=E2=80=9D transaction for the issu=
e to be resolved.</div><div> </div><blockquote style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style=
=3D"font-family:Arial,sans-serif;font-size:14px"><div>The "Restrictive Fawk=
esCoin" protocol would seem to fix this problem though.</div></div></blockq=
uote><div> </div><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex"><div style=3D"font-family:Aria=
l,sans-serif;font-size:14px"><div><br></div><div>Finally, the consensus imp=
lementation complexity for any Fawkescoin implementation would be enormous.=
 There are so many context-specific validation steps. The modifications des=
cribed in section 3.3 and section 4 only further exacerbate this. Sections =
3 thru 5 describe all the various Fawkescoin protocols and modifications, a=
nd in total they are <b>16 pages long</b>. I don't expect anyone could push=
 that much protocol complexity into consensus in the next decade.</div><div=
><br></div><div>We're having a hard enough time coming to consensus on the =
"to freeze or not to freeze" debate, the OP_CTV debate, the OP_CAT debate, =
etc. I don't see a future where Bitcoin users can even <i>comprehend</i> al=
l the rules and parameters included in the final FawkesCoin-driven protocol=
, <span style=3D"display:inline;background-color:rgb(255,255,255)">let alon=
e a world where we can all agree on<span> them</span></span>. We need somet=
hing simpler, more closely aligned with existing consensus rules, that can =
be implemented and slotted into existing BIPs and UX neatly.</div><div><br>=
</div><div>Personally I think the answer is to require a proof-of-seed-know=
ledge to spend any EC-signature-locked UTXO, and to implement it as a soft =
fork. It'd be expensive, and throughput would be low, but it'd also be far =
better than the bikeshed hell which we'd doubtless find ourselves in if we =
try to push the hulking mass of Fawkescoin into consensus. There'd be no co=
mplex timelock conditions, no commit/reveal protocols; just one new encumbr=
ance added to old EC script pubkeys. Existing wallets can be upgraded witho=
ut any time-sensitive migration procedures.</div></div></blockquote><div><b=
r></div><div>I agree that the protocols are complicated. We laid out the po=
ssible choices, with a special focus on tradeoffs, and I hope that at least=
 one of them (and certainly not all) would get implemented. I think that un=
restrictive Fawkes Coin is a fairly simple protocol, which doesn't require =
any cryptography either the type already used in Bitcoin (hashing for commi=
t/reveal, and existing digital signatures, and the post-quantum digital sig=
nature which hopefully be decided upon in BIP-360). The only downside being=
 that users need a post-quantum wallet to pay the fee from. The main advant=
age of Lifed Fawkes Coin is that the need to pay the fee from a post-quantu=
m transaction is removed (at the cost of a more sophisticated protocol). </=
div><div> </div><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex"><div style=3D"font-family:Arial=
,sans-serif;font-size:14px"><div><br></div><div>So then we're left with thi=
s question: What primitive should we use to prove seed knowledge: Seed-lift=
ed Picnic signatures or zk-STARKs? </div></div></blockquote><blockquote sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex"><div style=3D"font-family:Arial,sans-serif;font-size:14px"><di=
v><br></div><div>Cards on the table: I'm not very familiar with Picnic, but=
 I am with zk-STARKs. I know zk-STARKs would be very useful to have on-hand=
 as a primitive available to consensus, especially in a post-quantum world.=
 They work for any general computation, with arbitrary private and public i=
nputs. They are quick to verify but take a lot of work to produce. They are=
 usually large, measured in tens of kilobytes, but that's similar to Picnic=
. </div><div><br></div><div>Maybe it'd be worthwhile for someone to do some=
 quantitative benchmarking and qualitative compare/contrast research betwee=
n zk-STARKs and Picnic signatures (and maybe other alternatives too?), spec=
ifically for the case of BIP39 seed derivation proofs. I'm especially curio=
us if an optimized zk-STARK circuit for BIP39/BIP32 derivation can be desig=
ned to reduce proving runtime and proof size. I'd also love to know if Picn=
ic signatures could be reused for other things like rollups, IBD speedup, e=
tc, as I know zk-STARKs could be used for. </div><div><br></div><div>In any=
 case, while I don't think commit/reveal protocols like Lifted FawkesCoin o=
r its variants are appropriate for a bitcoin consensus upgrade, I do really=
 appreciate all the research that went into your paper Or. It is a perfect =
resource for anyone interested in PQ commit/reveal protocols and contains m=
any nuggets of wisdom in that realm.</div></div></blockquote><div><br></div=
><div>Thanks again for the kind words!<br>I don't share the same sentiment =
regarding the conclusion:<br>First, our FawkesCoin approach doesn't require=
 new primitives (Picnic / zk-STARKs), so it can be implemented relatively e=
asily. More importantly, it can accommodate many more transactions per bloc=
k: AFAIK, a zk-STARK and similarly Picnic are roughly 2-3 orders of magnitu=
de larger than an ECDSA signature (~100 Bytes vs.~10-100KB). A transaction =
fee costs an order of a dollar these days, so PICNIC/zk-STARK based approac=
hes would cost hundreds of dollars, and would allow only a small number of =
people to recover their funds. The only downside of FawkesCoin is that spen=
ding is done in two separate steps (commit-wait 100 blocks-reveal), which i=
s more cumbersome and takes longer. See my comment above regarding the adva=
ntages of Lifted FawkesCoin: FawkesCoin and Lifted FawkesCoin approaches ca=
n be used together.</div><div><br></div><div>Best,</div><div>Or</div><div><=
br></div><div><br></div><blockquote style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex"><div style=3D"font-fami=
ly:Arial,sans-serif;font-size:14px"><div><br></div><div>regards,</div><div>=
conduition</div><div><br></div><div><span style=3D"display:inline;backgroun=
d-color:rgb(255,255,255)"><span><br></span></span></div><div><span style=3D=
"display:inline;background-color:rgb(255,255,255)"><span><br></span></span>=
</div><div><br></div><div></div></div><div></div><div>
        On Sunday, July 13th, 2025 at 9:49 AM, Or Sattath &lt;<a rel=3D"nor=
eferrer nofollow noopener">sat...@gmail.com</a>&gt; wrote:<br>
        </div><div><blockquote type=3D"cite">
            <div style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,s=
ans-serif;font-size:small">Hi,<br><br>Jameson Lopp presented the freeze/not=
-freeze dilemma. I would like to point out that there=E2=80=99s a third app=
roach. The main insight is that even though the quantum attacker knows the =
digital signature private key, the attacker and the owner are not symmetric=
: the owner, in most cases, knows the seed (master secret key), whereas the=
 quantum attacker does not. This approach, which was done in collaboration =
with Shai Wyborski, is available here: <a href=3D"https://eprint.iacr.org/2=
023/362" style=3D"color:rgb(17,85,204)" rel=3D"noreferrer nofollow noopener=
" target=3D"_blank">https://eprint.iacr.org/2023/362</a> (our work was peer=
 reviewed and presented here: <a href=3D"https://www.qsmc.org/pqcsm-worksho=
p-2023" style=3D"color:rgb(17,85,204)" rel=3D"noreferrer nofollow noopener"=
 target=3D"_blank">https://www.qsmc.org/pqcsm-workshop-2023</a>).<br><br>Ou=
r main technique is called =E2=80=9Csignature lifting=E2=80=9D: it=E2=80=99=
s a way to transform an existing quantum-insecure signature scheme into a q=
uantum-secure signature scheme, while still using the old keys. This is pos=
sible whenever the function that maps the secret key to the public key is a=
 quantum-secure one-way function. Informally (and there are some details un=
der the rug that I=E2=80=99m not getting into), the quantum-secure one-way =
function maps the seed to the public key. (Of course, the function that map=
s the ECDSA signing key to the public key is not a quantum-secure one-way f=
unction. Therefore, our approach does not apply to pre-2013 wallets, which =
did not use BIP-38.) We use Picnic (<a href=3D"https://dl.acm.org/doi/abs/1=
0.1145/3133956.3133997" style=3D"color:rgb(17,85,204)" rel=3D"noreferrer no=
follow noopener" target=3D"_blank">https://dl.acm.org/doi/abs/10.1145/31339=
56.3133997</a>) as the underlying primitive that enables signature lifting.=
<br><br>The main drawback of signature lifting is that the signatures are e=
xtremely long. To address this, we also designed an interactive way to tran=
sact, using a commit-wait-reveal approach, which we called =E2=80=9CLifted =
FawkesCoin" (our main contribution over the original FawkesCoin approach by=
 Bonneau and Miller in <a href=3D"https://jbonneau.com/doc/BM14-SPW-fawkesc=
oin.pdf" style=3D"color:rgb(17,85,204)" rel=3D"noreferrer nofollow noopener=
" target=3D"_blank">https://jbonneau.com/doc/BM14-SPW-fawkescoin.pdf</a> is=
 that we resolve the issue of transaction fees, using lifted signatures). W=
hen the spender and the miner are honest, a transaction is roughly the same=
 size as today; only if one of the parties deviates from the honest protoco=
l must the long signature be added to the blockchain, and the cheating part=
y is financially penalized. The main burden of Lifted FawkesCoin is that us=
ers who haven=E2=80=99t transitioned to quantum-secure signatures yet need =
to occasionally (e.g., once a year) come online and check for fraud attempt=
s. I believe that even though this burden exists, it is a Pareto improvemen=
t over both the =E2=80=9Cfreeze=E2=80=9D and =E2=80=9Cnot-freeze=E2=80=9D a=
pproaches. </div><div style=3D"color:rgb(34,34,34);font-family:Arial,Helvet=
ica,sans-serif;font-size:small"><br>Best,<br>Or</div><br><div><div dir=3D"a=
uto">On Sunday, March 16, 2025 at 5:22:16=E2=80=AFPM UTC+2 Jameson Lopp wro=
te:<br></div><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">The quantum compu=
ting debate is heating up. There are many controversial aspects to this deb=
ate, including whether or not quantum computers will ever actually become a=
 practical threat.<div><br>I won't tread into the unanswerable question of =
how worried we should be about quantum computers. I think it's far from a c=
risis, but given the difficulty in changing Bitcoin it's worth starting to =
seriously discuss. Today I wish to focus on a philosophical quandary relate=
d to one of the decisions that would need to be made if and when we impleme=
nt a quantum safe signature scheme.<br><br><font size=3D"6">Several Scenari=
os<br></font>Because this essay will reference game theory a fair amount, a=
nd there are many variables at play that could change the nature of the gam=
e, I think it's important to clarify the possible scenarios up front.<br><b=
r>1. Quantum computing never materializes, never becomes a threat, and thus=
 everything discussed in this essay is moot.<br>2. A quantum computing thre=
at materializes suddenly and Bitcoin does not have quantum safe signatures =
as part of the protocol. In this scenario it would likely make the points b=
elow moot because Bitcoin would be fundamentally broken and it would take f=
ar too long to upgrade the protocol, wallet software, and migrate user fund=
s in order to restore confidence in the network.<br>3. Quantum computing ad=
vances slowly enough that we come to consensus about how to upgrade Bitcoin=
 and post quantum security has been minimally adopted by the time an attack=
er appears.<br>4. Quantum computing advances slowly enough that we come to =
consensus about how to upgrade Bitcoin and post quantum security has been h=
ighly adopted by the time an attacker appears.<br><br>For the purposes of t=
his post, I'm envisioning being in situation 3 or 4.<br><br><font size=3D"6=
">To Freeze or not to Freeze?<br></font>I've started seeing more people wei=
ghing in on what is likely the most contentious aspect of how a quantum res=
istance upgrade should be handled in terms of migrating user funds. Should =
quantum vulnerable funds be left open to be swept by anyone with a sufficie=
ntly powerful quantum computer OR should they be permanently locked?<br><br=
><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex">"I don't see why old coins should be confiscat=
ed. The better option is to let those with quantum computers free up old co=
ins. While this might have an inflationary impact on bitcoin's price, to us=
e a turn of phrase, the inflation is transitory. Those with low time prefer=
ence should support returning lost coins to circulation." </blockquote><blo=
ckquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204=
,204);padding-left:1ex">- Hunter Beast</blockquote><div><br></div>On the ot=
her hand:</div><div><br><blockquote style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex">"Of course they have to=
 be confiscated. If and when (and that's a big if) the existence of a crypt=
ography-breaking QC becomes a credible threat, the Bitcoin ecosystem has no=
 other option than softforking out the ability to spend from signature sche=
mes (including ECDSA and BIP340) that are vulnerable to QCs. The alternativ=
e 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 diligently moved their coins to PQC-protected sc=
hemes."<br>- Pieter Wuille</blockquote><br>I don't think "confiscation" is =
the most precise term to use, as the funds are not being seized and reassig=
ned. Rather, what we're really discussing would be better described as "bur=
ning" - placing the funds <b>out of reach of everyone</b>.<br><br>Not freez=
ing user funds is one of Bitcoin's inviolable properties. However, if quant=
um computing becomes a threat to Bitcoin's elliptic curve cryptography, <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 ag=
o I attempted to comprehensively categorize all of Bitcoin's fundamental pr=
operties that give it value. <a href=3D"https://nakamoto.com/what-are-the-k=
ey-properties-of-bitcoin/" rel=3D"noreferrer nofollow noopener" target=3D"_=
blank">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> - No one should have the power to prev=
ent others from using their bitcoin or interacting with the network.<br><br=
><b>Forward Compatibility</b> - changing the rules such that certain valid =
transactions become invalid could undermine confidence in the protocol.<br>=
<br><b>Conservatism</b> - Users should not be expected to be highly respons=
ive to system issues.<br><br>As a result of the above principles, we have d=
eveloped a strong meme (kudos to Andreas Antonopoulos) that goes as follows=
:<br><br><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli=
d rgb(204,204,204);padding-left:1ex">Not your keys, not your coins.</blockq=
uote><br>I posit that the corollary to this principle is:<br><br><blockquot=
e style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);=
padding-left:1ex">Your keys, only your coins.</blockquote><br>A quantum cap=
able entity breaks the corollary of this foundational principle. We secure =
our bitcoin with the mathematical probabilities related to extremely large =
random numbers. Your funds are only secure because truly random large numbe=
rs should not be guessable or discoverable by anyone else in the world.<br>=
<br>This is the principle behind the motto <i>vires in numeris</i> - streng=
th in numbers. In a world with quantum enabled adversaries, this principle =
is null and void for many types of cryptography, including the elliptic cur=
ve digital signatures used in Bitcoin.<br><br><font size=3D"6">Who is at Ri=
sk?<br></font>There has long been a narrative that Satoshi's coins and othe=
rs 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 quantu=
m computer, which coins would I target? I'd go to the Bitcoin rich list and=
 find the wallets that have exposed their public keys due to re-using addre=
sses that have previously been spent from. You can easily find them at <a h=
ref=3D"https://bitinfocharts.com/top-100-richest-bitcoin-addresses.html" re=
l=3D"noreferrer nofollow noopener" target=3D"_blank">https://bitinfocharts.=
com/top-100-richest-bitcoin-addresses.html</a><br><br>Note that a few of th=
ese wallets, like Bitfinex / Kraken / Tether, would be slightly harder to c=
rack because they are multisig wallets. So a quantum attacker would need to=
 reverse engineer 2 keys for Kraken or 3 for Bitfinex / Tether in order to =
spend funds. But many are single signature.<br><br>Point being, it's not on=
ly 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 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 Ethical Dilemma: Quantifying Harm<=
br></font>Which decision results in the most harm?<br><br>By making quantum=
 vulnerable funds unspendable we potentially harm some Bitcoin users who we=
re not paying attention and neglected to migrate their funds to a quantum s=
afe locking script. This violates the "conservativism" principle stated ear=
lier. On the flip side, we prevent those funds plus far more lost funds fro=
m falling into the hands of the few privileged folks who gain early access =
to quantum computers.<br><br>By leaving quantum vulnerable funds available =
to spend, the same set of users who would otherwise have funds frozen are l=
ikely to see them stolen. And many early adopters who lost their keys will =
eventually see their unreachable funds scooped up by a quantum enabled adve=
rsary.<br><br>Imagine, for example, being James Howells, who accidentally t=
hrew 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 kn=
ows it's buried, but can't get permission to excavate. I suspect that, give=
n the choice, he'd prefer those funds be permanently frozen rather than fal=
l into someone else's possession - I know I would.<br><br>Allowing a quantu=
m computer to access lost funds doesn't make those users any worse off than=
 they were before, however it <i>would</i> have a negative impact upon ever=
yone who is currently holding bitcoin.<br><br>It's prudent to expect signif=
icant economic disruption if large amounts of coins fall into new hands. Si=
nce a quantum computer is going to have a massive up front cost, expect tho=
se behind it to desire to recoup their investment. We also know from experi=
ence that when someone suddenly finds themselves in possession of 9+ figure=
s worth of highly liquid assets, they tend to diversify into other things b=
y selling.<br><br>Allowing quantum recovery of bitcoin is <i>tantamount to =
wealth redistribution</i>. What we'd be allowing is for bitcoin to be redis=
tributed from those who are ignorant of quantum computers to those who have=
 won the technological race to acquire 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>Does quantum recovery HELP anyone? I've yet=
 to come across an argument that it's a net positive in any way. It certain=
ly doesn't add any security to the network. If anything, it greatly decreas=
es the security of the network by allowing funds to be claimed by those who=
 did not earn them.<br><br>But wait, you may be thinking, wouldn't quantum =
"miners" have earned their coins by all the work and resources invested in =
building a quantum computer? I suppose, in the same sense that a burglar ea=
rns their spoils by the resources they invest into surveilling targets and =
learning the skills needed to break into buildings. What I say "earned" I m=
ean through productive mutual trade.<br><br>For example:<br><br>* Investors=
 earn BTC by trading for other currencies.<br>* Merchants earn BTC by tradi=
ng for goods and services.<br>* Miners earn BTC by trading thermodynamic se=
curity.<br>* Quantum miners don't trade anything, they are vampires feeding=
 upon the system.<br><br>There's no reason to believe that allowing quantum=
 adversaries to recover vulnerable bitcoin will be of benefit to anyone oth=
er than the select few organizations that win the technological arms race t=
o build the first such computers. Probably nation states and/or the top few=
 largest tech companies.<br><br>One could certainly hope that an organizati=
on with quantum supremacy is benevolent and acts in a "white hat" manner to=
 return lost coins to their owners, but that's incredibly optimistic and fo=
olish to rely upon. Such a situation creates an insurmountable ethical dile=
mma of only recovering lost bitcoin rather than currently owned bitcoin. Th=
ere's no way to precisely differentiate between the two; anyone can claim t=
o have lost their bitcoin but if they have lost their keys then proving the=
y ever had the keys becomes rather difficult. I imagine that any such white=
 hat recovery efforts would have to rely upon attestations from trusted thi=
rd parties like exchanges.<br><br>Even if the first actor with quantum supr=
emacy is benevolent, we must assume the technology could fall into adversar=
ial hands and thus think adversarially about the potential worst case outco=
mes. Imagine, for example, that North Korea continues scooping up billions =
of dollars from hacking crypto exchanges and decides to invest some of thos=
e proceeds into building a quantum computer for the biggest payday ever...<=
br><br><font size=3D"6">Downsides to Allowing Quantum Recovery</font><br>Le=
t's think through an exhaustive list of pros and cons for allowing or preve=
nting the seizure of funds by a quantum adversary.<br><br><font size=3D"4">=
Historical Precedent</font><br>Previous protocol vulnerabilities weren=E2=
=80=99t celebrated as "fair game" but rather were treated as failures to be=
 remediated. Treating quantum theft differently risks rewriting Bitcoin=E2=
=80=99s history as a free-for-all rather than a system that seeks to protec=
t 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 funda=
mental principle of cryptocurrency - if you keep your keys in your possessi=
on, only you should be able to access your money. Bitcoin is built on the i=
dea that private keys secure an individual=E2=80=99s assets, and unauthoriz=
ed 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 attac=
kers can exploit vulnerable addresses, confidence in Bitcoin as a secure st=
ore of value would collapse. Users and investors rely on cryptographic inte=
grity, and widespread theft could drive adoption away from Bitcoin, destabi=
lizing its ecosystem.<br><br>This is essentially the counterpoint to claimi=
ng 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 sto=
pping quantum theft to be similarly concerning.<br><br><font size=3D"4">Unf=
air Advantage</font><br>Quantum attackers, likely equipped with rare and ex=
pensive technology, would have an unjust edge over regular users who lack a=
ccess to such tools. This creates an inequitable system where only the tech=
nologically elite can exploit others, contradicting Bitcoin=E2=80=99s ethos=
 of decentralized power.<br><br>Bitcoin is designed to create an asymmetric=
 advantage for DEFENDING one's wealth. It's supposed to be impractically ex=
pensive for attackers to crack the entropy and cryptography protecting one'=
s coins. But now we find ourselves discussing a situation where this asymme=
tric advantage is compromised in favor of a specific class of attackers.<br=
><br><font size=3D"4">Economic Disruption</font><br>Large-scale theft from =
vulnerable addresses could crash Bitcoin=E2=80=99s price as quantum recover=
ed funds are dumped on exchanges. This would harm all holders, not just tho=
se directly targeted, leading to broader financial chaos in the markets.<br=
><br><font size=3D"4">Moral Responsibility</font><br>Permitting theft via q=
uantum computing sets a precedent that technological superiority justifies =
unethical behavior. This is essentially taking a "code is law" stance in wh=
ich 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 think it's worth differentiating the two=
 different thefts being discussed:<br><br>1. self-enriching &amp; likely ma=
licious<br>2. harm prevention &amp; not necessarily malicious<br><br>Both o=
ptions lack the consent of the party whose coins are being burnt or transfe=
rred, thus I think the simple argument that theft is immoral becomes a wash=
 and it's important to drill down into the details of each.<br><br><font si=
ze=3D"4">Incentives Drive Security</font><br>I can tell you from a decade o=
f working in Bitcoin security - the average user is lazy and is a procrasti=
nator. If Bitcoiners are given a "drop dead date" after which they know vul=
nerable funds will be burned, this pressure accelerates the adoption of pos=
t-quantum cryptography and strengthens Bitcoin long-term. Allowing vulnerab=
le users to delay upgrading indefinitely will result in more laggards, leav=
ing the network more exposed when quantum tech becomes available.<br><br><f=
ont size=3D"6">Steel Manning<br></font>Clearly this is a complex and contro=
versial topic, thus it's worth thinking through the opposing arguments.<br>=
<br><font size=3D"4">Protecting Property Rights</font><br>Allowing quantum =
computers to take vulnerable bitcoin could potentially be spun as a hard mo=
ney narrative - we care so greatly about not violating someone's access to =
their coins that we allow them to be stolen!<br><br>But I think the flip si=
de to the property rights narrative is that burning vulnerable coins preven=
ts said property from falling into undeserving hands. If the entire Bitcoin=
 ecosystem just stands around and allows quantum adversaries to claim funds=
 that rightfully belong to other users, is that really a "win" in the "prot=
ecting property rights" category? It feels more like apathy to me.<br><br>A=
s such, I think the "protecting property rights" argument is a wash.<br><br=
><font size=3D"4">Quantum Computers Won't Attack Bitcoin</font><br>There is=
 a great deal of skepticism that sufficiently powerful quantum computers wi=
ll 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 attack=
er would not go after bitcoin because they wouldn't want to reveal their ha=
nd by doing so, and would instead attack other infrastructure.<br><br>It's =
quite difficult to quantify exactly how valuable attacking other infrastruc=
ture would be. It also really depends upon when an entity gains quantum sup=
remacy and thus if by that time most of the world's systems have already be=
en upgraded. While I think you could argue that certain entities gaining qu=
antum capability might not attack Bitcoin, it would only delay the inevitab=
le - 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 St=
eal Small Amounts</font><br>Some have argued that even if a quantum attacke=
r targeted bitcoin, they'd only go after old, likely lost P2PK outputs so a=
s 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 w=
ith the same effort as 50 BTC? This is a classic "zero day exploit" game th=
eory in which an attacker knows they have a limited amount of time before s=
omeone else discovers the exploit and either benefits from it or patches it=
. Take, for example, the recent ByBit attack - the highest value crypto hac=
k of all time. Lazarus Group had compromised the Safe wallet front end Java=
Script app and they could have simply had it reassign ownership of everyone=
's Safe wallets as they were interacting with their wallet. But instead the=
y 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 sta=
rted stealing from every wallet, they would have been discovered quickly an=
d the Safe web app would likely have been patched well before any billion d=
ollar wallets executed the malicious code.<br><br>I think the "only stealin=
g small amounts" argument is strongest for Situation #2 described earlier, =
where a quantum attacker arrives before quantum safe cryptography has been =
deployed across the Bitcoin ecosystem. Because if it became clear that Bitc=
oin's cryptography was broken AND there was nowhere safe for vulnerable use=
rs to migrate, the only logical option would be for everyone to liquidate t=
heir bitcoin as quickly as possible. As such, I don't think it applies as s=
trongly for situations in which we have 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 / spend=
able" supply to be as close to 21M as possible and that having a significan=
t portion of the supply out of circulation is somehow undesirable.<br><br>W=
hile the "21M BTC" attribute is a strong memetic narrative, I don't think a=
nyone 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 t=
he game theory of owning bitcoin!<br><br>And remember, the 21M number in an=
d of itself is not a particularly important detail - it's not even mentione=
d in the whitepaper. What's important is that the supply is well known and =
not subject to change.<br><br><font size=3D"4">Self-Sovereignty and Persona=
l 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 one'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 shie=
ld users from their own negligence undermines the principle that you, and n=
ot a third party, are accountable for your assets.<br><br>I think this is g=
enerally a fair point that "the community" doesn't owe you anything in term=
s of helping you. I think that we do, however, need to consider the incenti=
ves and game theory in play with regard to quantum safe Bitcoiners vs quant=
um vulnerable Bitcoiners. More on that 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 attacker uses superior technology to derive p=
rivate keys from public keys, they=E2=80=99re not "hacking" the system - th=
ey're simply following what's mathematically permissible within the current=
 code. Altering the protocol to stop this introduces subjective human inter=
vention, which clashes with the objective, deterministic nature of blockcha=
in.<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 more like a pro-ossification stance that =
it's better to do nothing and allow harm to occur rather than take action t=
o stop an attack that was foreseen far in advance.<br><br><font size=3D"4">=
Technological Evolution as a Feature, Not a Bug</font><br>It's well known t=
hat cryptography tends to weaken over time and eventually break. Quantum co=
mputing 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 th=
ose who ignored technological advancements like multisig or hardware wallet=
s. Allowing quantum theft incentivizes innovation and keeps Bitcoin=E2=80=
=99s ecosystem dynamic, punishing complacency while rewarding vigilance.<br=
><br><font size=3D"4">Market Signals Drive Security</font><br>If quantum at=
tackers start stealing funds, it sends a clear signal to the market: upgrad=
e your security or lose everything. This pressure accelerates the adoption =
of post-quantum cryptography and strengthens Bitcoin long-term. Coddling vu=
lnerable users delays this necessary evolution, potentially leaving the net=
work more exposed when quantum tech becomes widely accessible. Theft is a b=
rutal but effective teacher.<br><br><font size=3D"4">Centralized Blacklisti=
ng Power</font><br>Burning vulnerable funds requires centralized decision-m=
aking - a soft fork to invalidate certain transactions. This sets a dangero=
us precedent for future interventions, eroding Bitcoin=E2=80=99s decentrali=
zation. If quantum theft is blocked, what=E2=80=99s next - reversing exchan=
ge hacks? The system must remain neutral, even if it means some lose out.<b=
r><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 b=
urn all funds in locking script types that are known to be quantum vulnerab=
le. Thus, we could eliminate any subjectivity from the code.<br><br><font s=
ize=3D"4">Fairness in Competition</font><br>Quantum attackers aren't cheati=
ng; they're using publicly available physics and math. Anyone with the reso=
urces 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 rewar=
ds; quantum innovators are doing the same. Calling it =E2=80=9Cunfair=E2=80=
=9D ignores that Bitcoin has never promised equality of outcome - only equa=
lity of opportunity within its rules.<br><br>I find this argument to be a m=
ischaracterization because we're not talking about CPUs. This is more akin =
to talking about ASICs, except each ASIC 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 Resilience</font><br>Bitcoin has weathered t=
hefts before (MTGOX, Bitfinex, FTX, etc) and emerged stronger. The market c=
an absorb quantum losses, with unaffected users continuing to hold and new =
entrants buying in at lower prices. Fear of economic collapse overestimates=
 the impact - the network=E2=80=99s antifragility thrives on such challenge=
s.<br><br>This is a big grey area because we don't know when a quantum comp=
uter 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 sufficient=
ly powerful quantum computers were stealing less volume than the current bl=
ock 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 market impact as it absorbs the new sup=
ply.<br><br>This is where the circumstances will really matter. If a quantu=
m attacker appears AFTER the Bitcoin protocol has been upgraded to support =
quantum resistant cryptography then we should expect the most valuable acti=
ve wallets will have upgraded and the juiciest target would be the 31,000 B=
TC in the address 12ib7dApVFvg82TXKycWBNpN8kFyiAN1dr which has been dormant=
 since 2010. In general I'd expect that the amount of BTC re-entering the c=
irculating supply would look somewhat similar to the mining emission curve:=
 volume would start off very high as the most valuable addresses are draine=
d and then it would fall off as quantum computers went down the list target=
ing addresses with less and less BTC.<br><br>Why is economic impact a facto=
r worth considering? Miners and businesses in general. More coins being liq=
uidated will push down the price, which will negatively impact miner revenu=
e. Similarly, I can attest from working in the industry for a decade, that =
lower prices result in less demand from businesses across the entire indust=
ry. As such, burning quantum vulnerable bitcoin is good for the entire indu=
stry.<br><br><font size=3D"4">Practicality &amp; Neutrality of Non-Interven=
tion</font><br>There=E2=80=99s no reliable way to distinguish =E2=80=9Cthef=
t=E2=80=9D from legitimate "white hat" key recovery. If someone loses their=
 private key and a quantum computer recovers it, is that stealing or reclai=
ming? Policing quantum actions requires invasive assumptions about intent, =
which Bitcoin=E2=80=99s trustless design can=E2=80=99t accommodate. Letting=
 the chips fall where they may avoids this mess.<br><br><font size=3D"4">Ph=
ilosophical Purity</font><br>Bitcoin rejects bailouts. It=E2=80=99s a cold,=
 hard system where outcomes reflect preparation and skill, not sentimentali=
ty. If quantum computing upends the game, that=E2=80=99s the point - Bitcoi=
n isn=E2=80=99t meant to be safe or fair in a nanny-state sense; it=E2=80=
=99s meant to be free. Users who lose funds to quantum attacks are casualti=
es of liberty and their own ignorance, not victims of injustice.<br><br><fo=
nt size=3D"6">Bitcoin's DAO Moment</font><br>This situation has some simila=
rities to The DAO hack of an Ethereum smart contract in 2016, which resulte=
d in a fork to stop the attacker and return funds to their original owners.=
 The game theory is similar because it's a situation where a threat is know=
n but there's some period of time before the attacker can actually execute =
the theft. As such, there's time to mitigate the attack by changing the pro=
tocol.<br><br>It also created a schism in the community around the true mea=
ning of "code is law," resulting in Ethereum Classic, which decided to allo=
w the attacker to retain control of the stolen 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 and continue including transactions=
.<br><br><font size=3D"6">Incentives Matter</font><br>We can wax philosophi=
cal until the cows come home, but what are the actual incentives for existi=
ng Bitcoin holders regarding this decision?<br><br><blockquote style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex">"Lost coins only make everyone else's coins worth slightly more. Think =
of it as a donation to everyone." - Satoshi Nakamoto</blockquote><br>If tru=
e, the corollary is:<br><br><blockquote style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex">"Quantum recovered =
coins only make everyone else's coins worth less. Think of it as a theft fr=
om everyone." - Jameson Lopp</blockquote><br>Thus, assuming we get to a poi=
nt where quantum resistant signatures are supported within the Bitcoin prot=
ocol, what's the incentive to let vulnerable coins remain spendable?<br><br=
>* It's not good for the actual owners of those coins. It disincentivizes o=
wners from upgrading until perhaps it's too late.<br>* It's not good for th=
e more attentive / responsible owners of coins who have quantum secured the=
ir stash. Allowing the circulating supply to balloon will assuredly reduce =
the purchasing power of all bitcoin holders.<br><br><font size=3D"6">Forkin=
g Game Theory</font><br>From a game theory point of view, I see this as inc=
entivizing users to upgrade their wallets. If you disagree with the burning=
 of vulnerable coins, all you have to do is move your funds to a quantum sa=
fe signature scheme. Point being, I don't see there being an economic major=
ity (or even more than a tiny minority) of users who would fight such a sof=
t fork. Why expend significant resources fighting a fork when you can just =
move your coins to a new address?<br><br>Remember that blocking spending of=
 certain classes of locking scripts is a tightening of the rules - a soft f=
ork. As such, it can be meaningfully enacted and enforced by a mere majorit=
y 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 th=
e effort to run new node software that resists the soft fork? Seems unlikel=
y 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 longe=
r accept transactions (or blocks containing such transactions) that spend f=
unds from any scripts other than the newly instituted quantum safe schemes.=
<br><br>It could take a staggered approach to first freeze funds that are s=
usceptible to long-range attacks such as those in P2PK scripts or those tha=
t exposed their public keys due to previously re-using addresses, but I exp=
ect the additional complexity would drive further controversy.<br><br>How l=
ong should the grace period be in order to give the ecosystem time to upgra=
de? I'd say a minimum of 1 year for software wallets to upgrade. We can onl=
y hope that hardware wallet manufacturers are able to implement post quantu=
m 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. Though if you =
exclude dust UTXOs you could probably get 95% of BTC value migrated in 1 mo=
nth. Of course this is a highly optimistic situation where everyone is comp=
letely focused on migrations - in reality it will take far longer.<br><br>R=
egardless, I'd think that in order to reasonably uphold Bitcoin's conservat=
ism it would be preferable to allow a 4 year migration window. In the meant=
ime, mining pools could coordinate emergency soft forking logic such that i=
f quantum attackers materialized, they could accelerate the countdown to th=
e quantum vulnerable funds burn.<br><br><font size=3D"6">Random Tangential =
Benefits</font><br>On the plus side, burning all quantum vulnerable bitcoin=
 would allow us to prune all of those UTXOs out of the UTXO set, which woul=
d also clean up a lot of dust. Dust UTXOs are a bit of an annoyance and the=
re has even been a recent proposal for how to incentivize cleaning them up.=
<br><br>We should also expect that incentivizing migration of the entire UT=
XO set will create substantial demand for block space that will sustain a f=
ee market for a fairly lengthy amount of time.<br><br><font size=3D"6">In S=
ummary</font><br>While the moral quandary of violating any of Bitcoin's inv=
iolable properties can make this a very complex issue to discuss, the game =
theory and incentives between burning vulnerable coins versus allowing them=
 to be claimed by entities with quantum supremacy appears to be a much simp=
ler issue.<br><br>I, for one, am not interested in rewarding quantum capabl=
e entities by inflating the circulating money supply just because some peop=
le lost their keys long ago and some laggards are not upgrading their bitco=
in wallet's security.<br><br>We can hope that this scenario never comes to =
pass, but hope is not a strategy.<br><br>I welcome your feedback upon any o=
f the above points, and contribution of any arguments I failed to consider.=
</div></div>
</blockquote></div>

<p></p></blockquote></div><div><blockquote type=3D"cite">

-- <br></blockquote></div><div><blockquote type=3D"cite">
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"noreferrer nofollow noopener">bitcoindev+...@googlegroups=
.com</a>.<br></blockquote></div><div><blockquote type=3D"cite">
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/f17de19d-a6f5-46b3-abcd-09c056d9bd64n%40googlegroups.com" rel=3D=
"noreferrer nofollow noopener" target=3D"_blank">https://groups.google.com/=
d/msgid/bitcoindev/f17de19d-a6f5-46b3-abcd-09c056d9bd64n%40googlegroups.com=
</a>.<br>

        </blockquote><br>
    </div></blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"noreferrer nofollow noopener">bitcoindev+...@googlegroups=
.com</a>.<br></blockquote></div><div><blockquote type=3D"cite">
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/6326b5d0-df6b-4f40-9d15-9ed502278397n%40googlegroups.com" rel=3D=
"noreferrer nofollow noopener" target=3D"_blank">https://groups.google.com/=
d/msgid/bitcoindev/6326b5d0-df6b-4f40-9d15-9ed502278397n%40googlegroups.com=
</a>.<br>

        </blockquote><br>
    </div></blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" 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" rel=3D"n=
oreferrer nofollow noopener" target=3D"_blank">bitcoindev+unsubscribe@googl=
egroups.com</a>.<br>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/c56b179f-2753-4f1c-80a4-14969e737d37n%40googlegroups.com" rel=3D=
"noreferrer nofollow noopener" target=3D"_blank">https://groups.google.com/=
d/msgid/bitcoindev/c56b179f-2753-4f1c-80a4-14969e737d37n%40googlegroups.com=
</a>.<br>

        </blockquote><br>
    </div></blockquote></div><div><br clear=3D"all"></div><br><span class=
=3D"gmail_signature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_s=
ignature">Best regards,<br>Boris Nagaev</div></div>
</div>

        </blockquote><br>
    </div></blockquote></div><div><br clear=3D"all"></div><br><span class=
=3D"gmail_signature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_s=
ignature">Best regards,<br>Boris Nagaev</div></div>

        </blockquote><br>
    </div></blockquote></div><div><br clear=3D"all"></div><br><span class=
=3D"gmail_signature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_s=
ignature">Best regards,<br>Boris Nagaev</div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" 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" rel=3D"n=
oreferrer nofollow noopener">bitcoindev+unsubscribe@googlegroups.com</a>.<b=
r>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/CAFC_Vt7a1O9vCdycRtUmTAQyL%3DifZAZt3Wzx-YBTQ1cKyJq55w%40mail.gma=
il.com" target=3D"_blank" rel=3D"noreferrer nofollow noopener">https://grou=
ps.google.com/d/msgid/bitcoindev/CAFC_Vt7a1O9vCdycRtUmTAQyL%3DifZAZt3Wzx-YB=
TQ1cKyJq55w%40mail.gmail.com</a>.<br>

        </blockquote><br>
    </div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" 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" rel=3D"n=
oreferrer nofollow noopener">bitcoindev+unsubscribe@googlegroups.com</a>.<b=
r>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/YX1Q8oL5phYHC8fM_m4aHakglTjz1RYlv8k7tGgbq9Rx_jx6BFmG6Y8uA7Vrma0f=
OX3kCTD30k0PCUGeBX_bnglN5GWCZdGABxKDOjvt_bA%3D%40proton.me" target=3D"_blan=
k" rel=3D"noreferrer nofollow noopener">https://groups.google.com/d/msgid/b=
itcoindev/YX1Q8oL5phYHC8fM_m4aHakglTjz1RYlv8k7tGgbq9Rx_jx6BFmG6Y8uA7Vrma0fO=
X3kCTD30k0PCUGeBX_bnglN5GWCZdGABxKDOjvt_bA%3D%40proton.me</a>.<br>

        </blockquote><br>
    </div>

<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/4wCyWdzfJTskjdcX3WSpbV53KAhAc_CwqS-65RAA9cD1lcttvdFgG4LPY1U8YRlc=
JrPJMAc_aR_d4uLiUxMypdxmoMAhN5WDlCByp1mWHnM%3D%40proton.me?utm_medium=3Dema=
il&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoindev/4wCyWd=
zfJTskjdcX3WSpbV53KAhAc_CwqS-65RAA9cD1lcttvdFgG4LPY1U8YRlcJrPJMAc_aR_d4uLiU=
xMypdxmoMAhN5WDlCByp1mWHnM%3D%40proton.me</a>.<br />

-----------------------5da4cd42e798bcfc4b1e2cb62bb0b6da--
-----------------------7359e0b8461b9366496a00df1ae9812f--
-----------------------de041f8d3fac70083a019e520307bbeb
Content-Type: application/pgp-keys; filename="publickey - conduition@proton.me - 0x474891AD.asc"; name="publickey - conduition@proton.me - 0x474891AD.asc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="publickey - conduition@proton.me - 0x474891AD.asc"; name="publickey - conduition@proton.me - 0x474891AD.asc"

LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgp4ak1FWkRub0tSWUpLd1lCQkFI
YVJ3OEJBUWRBcnBZYWFjZDgwcXdocmNaQW9VbW9NSHNWS21iZWlPZUEKcFhXbk1ybFdPZkxOSzJO
dmJtUjFhWFJwYjI1QWNISnZkRzl1TG0xbElEeGpiMjVrZFdsMGFXOXVRSEJ5CmIzUnZiaTV0WlQ3
Q2pBUVFGZ29BUGdXQ1pEbm9LUVFMQ1FjSUNaQjRLV3p0aFBhenhRTVZDQW9FRmdBQwpBUUlaQVFL
YkF3SWVBUlloQkVkSWthMENNdHJMZGcxM2EzZ3BiTzJFOXJQRkFBQTZhQUVBM1RmNHdqSVoKYnox
K0diS0h4K09WQytNUXlVdi84RStoWUpjTE5QZnA0NEFBLzNiak5OTXN4WHdJTGZEM0xManNVVWFo
CitBV2JyblVjVUFqQ2R1d3hUT01LempnRVpEbm9LUklLS3dZQkJBR1hWUUVGQVFFSFFDSXYxZW5J
MU5MbAo3Zm55RzlVWk1wQ3ZsdG5vc0JrTmhQUVZxT3BXL3RKSkF3RUlCOEo0QkJnV0NBQXFCWUpr
T2VncENaQjQKS1d6dGhQYXp4UUtiREJZaEJFZElrYTBDTXRyTGRnMTNhM2dwYk8yRTlyUEZBQUFR
TFFEL2NCR2kwUDdwCkZTTkl2N1B6OVpkeUNVQjhzTy90dWZkV3NjQkNZK2ZMYTV3QkFNK0hTL3Jp
S014RGt0TkhLakRGc2EvUgpEVDFxUGNBYXZCaXc2dDZ4Ti9jRgo9Y3d5eAotLS0tLUVORCBQR1Ag
UFVCTElDIEtFWSBCTE9DSy0tLS0tCg==
-----------------------de041f8d3fac70083a019e520307bbeb--

--------90797aa7ec662f091cb1e5e00eda6a4faf92cd16f8c025d9a4feae5f0ea6cd9f
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wrsEARYKAG0FgmiXpygJkHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp
b25zLm9wZW5wZ3Bqcy5vcmf+WHNBR5gQnX6Rg2ZcvupTy+N91X+QZ//SUcrM
X9hsEhYhBEdIka0CMtrLdg13a3gpbO2E9rPFAAC32wEAj5nqESaRW84FvCkO
ovc8jD3L3NQJbO4ht2b/i11WFUYBAMsVBcEWtxqhI5wzdOl566OJ5ex6UDcd
A3LIMQjTVdMD
=7kXW
-----END PGP SIGNATURE-----


--------90797aa7ec662f091cb1e5e00eda6a4faf92cd16f8c025d9a4feae5f0ea6cd9f--