From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 (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 From: "'conduition' via Bitcoin Development Mailing List" Cc: Nagaev Boris , Bitcoin Development Mailing List Subject: Re: [bitcoindev] Re: Against Allowing Quantum Recovery of Bitcoin Message-ID: <4wCyWdzfJTskjdcX3WSpbV53KAhAc_CwqS-65RAA9cD1lcttvdFgG4LPY1U8YRlcJrPJMAc_aR_d4uLiUxMypdxmoMAhN5WDlCByp1mWHnM=@proton.me> In-Reply-To: References: <0FMBd3qAkpUT93zRc-SV_W7J3IA9uVjVQf5MEDkGXUoyFG_iS8jgLqhs5Pzw5T5zIZ9dL79KSS24ZlYLWOejrALx0Waa6L_oACBkNGnlWlI=@proton.me> <1_SQdVeoXT3nPyNf-k-kcrcUunu8EwV788dGA3u054NlldCDZAROTMJPgMOFJ5Amf3mEu_E9xkZXouCOavpewxfwWt8KlMm74-ySRVWL5A0=@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 Reply-To: conduition Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -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 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 = wrote: >=20 > > Hi Conduition, > >=20 > > On Mon, Jul 28, 2025 at 9:24=E2=80=AFPM conduition 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 wrote: > > >=20 > > > > Hey Conduition, > > > >=20 > > > > On Mon, Jul 28, 2025 at 6:38=E2=80=AFPM conduition 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 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 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 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 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 > > > > > > > > > > > - (For UTXOs whose pubkeys are still secret) I know= a public key such that hash160(pubkey) =3D=3D > > > > > > > > > > > =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 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 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
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=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 earliest=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. 

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.

We can=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. 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.

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.

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

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.

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. 

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 witnesses=E2= =80=8B that will be used to spend the UTXO? 

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".

Then we could get away with a 68 byte comm= itment made of two hashes and a u32: (utxo, witness_hash)=E2= =80=8B. We no longer need to publish the TXID in the commitment, because witness_hash=E2=80=8B indirectly commits to it. You'= d compute the witness hash by simply concatenating and hashing all the witn= ess data for each input in consensus order.

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.


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

On Mo= n, Jul 28, 2025 at 9:24=E2=80=AFPM conduition <conduition@proton.me> wrote:
Hi Boris,

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





- array of MACs in the order of EC operations in the witness s= cript

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.

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".

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.
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).
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.
To confirm, when va= lidating a commitment that contains multiple MACs, the validator would need= to assert that every MAC is the earliest valid MAC, right? If even = one pubkey was exposed and committed earlier, it'd render the whole reveal = TX invalid.

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.

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.

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.

Best,
Boris


On Monday, July 28th, 2025 at 5:07 PM, Nagaev Boris <bnagaev@gmail.com> wrote:
Hey Conduition,

On Mon, Jul 28, 2025 at 6:= 38=E2=80=AFPM conduition <conduition@proton.me&g= t; wrote:
Hey Boris,

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.

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 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!
<= /div>
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.

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.

I understand :)<= /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>
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.
=
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. We can't verify commitments for reveal TXs which are never published. Which is fine - validators just care whether the sender knew a valid pa= rent xpriv before the reveal TX was published.

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.
Now that= I think about it, we safely can omit the bip32 key paths from the HMAC com= mitment. They serve no purpose there.

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.
Coins whose pri= vate key is not a child of BIP32. One important instance is MuSig2 coins.

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.

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 X =3D H(L, A)= *A + H(L, B)*B then a QC cannot practically compute a valid key set = L =3D [A, B]. So you could make a commit/reveal scheme for MuS= ig keys by committing to (and then revealing) the key set L. N= odes 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 attacker. No secret key sharing is needed for this.

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.

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.

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.
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.

Some xpubs may have too many coins to swee= p in a single transaction.

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.

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.

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.

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.

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?


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>
- UTXO
- TXID
- array of MACs in the order= of EC operations in the witness script
This is also = more space efficient, because UTXO and TXID will be the same, only the MAC = part is different.

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.
<= div style=3D"font-family:Arial,sans-serif;font-size:14px">
=
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) allowing QCs to steal from pubkeys exposed off-chai= n, or (2) destroying the coins of paper/brain wallet hodlers (or anyone else who didn= 't use BIP32).

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.

Best,
Boris
regards,
conduition
On Friday, July 25th, 2025 at 7:17 PM, Nagaev Boris <bnagaev@gmail.com> wrote:
Hi Conduition,

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.

Switching back to coin recove= ry, there are a few challenges. I have thoughts on how to solve some of the= m.

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= .

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.

Maybe taproo= t addresses should have a special approach, because they have a key path sp= end which is unique among all address types.

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.

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.

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.

Best,
Boris

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

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.

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.

So the protocol becomes:

The commit_tx includes:

1. UTXO
2. TXID
3. MAC(TXID, key=3Dbip32_xpriv_and_keypaths)

The reveal transa= ction must attach the bip32_= xpriv_and_keypaths so= validators can check the MAC.

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?

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.
<= br>
regards= ,
conduitio= n


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

Let's consider this scheme:

The co= mmit_tx includes:
  1. UTXO
  2. TXID
  3. MAC(TXID, key=3D= pubkey)
The reveal transaction is just a normal Bitcoin transactio= n.

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.

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.

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.

Best,
Boris


On S= unday, July 20, 2025 at 2:48:22=E2=80=AFPM UTC-3 conduition wrote:
Hi Or,

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?

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.

Yes, that's my question. There is= a big difference between this and a double-spend attack.
=
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. 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.

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.

Unless i'm mistaken there, I'd say this property makes Lifted Fawke= sCoin a non-starter.

Restrictive FawkesCoin 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. You're right that this would be sim= pler to implement than zk-STARKs, so maybe I spoke too soon.

regards,
conduition

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


On Tuesday, July 15, 2025 at 4= :57:23=E2=80=AFPM UTC+3 conduition wrote:
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:

  • (For UTXOs whose pubkeys are exposed) I know a BIP39 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 ke= y such that hash160(pubkey) =3D=3D <hash>

=
From Or's paper, section 2.5:

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

Spending Derived UTXOs: To spend a derived UTXO,= the user signs it with a seed-lifted signature (see Section 2= .3).

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 hash160(pubkey) =3D=3D <hash> 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.=

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 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.

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:

After the = commitment has been posted, the spender has a limited time to post a reveal= of the commitment to the blockchain. If they fail to do so, the min= er can post the proof of ownershipto claim the entire UTXO, making sp= am attempts costly

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:

The= fee paid for including tx is split equally between the miner who included tx and the miner who included (H(tx))
<= /blockquote>
(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.)


The tab= le on p. 11 here (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:
3D"Screenshot

= You=E2=80=99re right that Lifted Spending (Section 2.2 & 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= .
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>

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?
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.
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.
The "Restrictive Fawk= esCoin" protocol would seem to fix this problem though.

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 16 pages long. I don't expect anyone could push= that much protocol complexity into consensus in the next decade.

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 comprehend al= l the rules and parameters included in the final FawkesCoin-driven protocol= , let alon= e a world where we can all agree on them. We need somet= hing simpler, more closely aligned with existing consensus rules, that can = be implemented and slotted into existing BIPs and UX neatly.

=
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.
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).

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?

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= .

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.

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.

Thanks again for the kind words!
I don't share the same sentiment = regarding the conclusion:
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.

Best,
Or
<= br>


regards,
= conduition



=

On Sunday, July 13th, 2025 at 9:49 AM, Or Sattath <sat...@gmail.com> wrote:
Hi,

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: https://eprint.iacr.org/2023/362 (our work was peer= reviewed and presented here: https://www.qsmc.org/pqcsm-workshop-2023).

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 (https://dl.acm.org/doi/abs/10.1145/31339= 56.3133997) as the underlying primitive that enables signature lifting.=

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 https://jbonneau.com/doc/BM14-SPW-fawkescoin.pdf 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.

Best,
Or

On Sunday, March 16, 2025 at 5:22:16=E2=80=AFPM UTC+2 Jameson Lopp wro= te:
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.

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.

Several Scenari= os
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.
1. Quantum computing never materializes, never becomes a threat, and thus= everything discussed in this essay is moot.
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.
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.
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.

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

To Freeze or not to Freeze?
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?
"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."
- Hunter Beast

On the ot= her hand:

"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."
- Pieter Wuille

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 out of reach of everyone.

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, = an inviolable property of Bitcoin will be violated one way or another.<= br>
Fundamental Properties at Risk
5 years ag= o I attempted to comprehensively categorize all of Bitcoin's fundamental pr= operties that give it value. https://nakamoto.com/what-are-the-key-properties-of-bitcoin/
=
The particular properties in play with regard to this issue seem to be:=

Censorship Resistance - No one should have the power to prev= ent others from using their bitcoin or interacting with the network.
Forward Compatibility - changing the rules such that certain valid = transactions become invalid could undermine confidence in the protocol.
=
Conservatism - Users should not be expected to be highly respons= ive to system issues.

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

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

Your keys, only your coins.

A quantum 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.
=
This is the principle behind the motto vires in numeris - 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.

Who is at Ri= sk?
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 https://bitinfocharts.= com/top-100-richest-bitcoin-addresses.html

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.

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.

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

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.

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.

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.

Allowing a quantu= m computer to access lost funds doesn't make those users any worse off than= they were before, however it would have a negative impact upon ever= yone who is currently holding bitcoin.

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.

Allowing quantum recovery of bitcoin is tantamount to = wealth redistribution. 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.

Is Quantum Recovery= Good for Anyone?

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.

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.

For example:

* Investors= earn BTC by trading for other currencies.
* Merchants earn BTC by tradi= ng for goods and services.
* Miners earn BTC by trading thermodynamic se= curity.
* Quantum miners don't trade anything, they are vampires feeding= upon the system.

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.

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.

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>
Downsides to Allowing Quantum Recovery
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.

= Historical Precedent
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.

Violation of Property RightsAllowing 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.
=
Erosion of Trust in Bitcoin
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.

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.

Unf= air Advantage
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.

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.
Economic Disruption
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.
Moral Responsibility
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.

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

1. self-enriching & likely ma= licious
2. harm prevention & not necessarily malicious

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.

Incentives Drive Security
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.

Steel Manning
Clearly this is a complex and contro= versial topic, thus it's worth thinking through the opposing arguments.
=
Protecting Property Rights
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!

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.

A= s such, I think the "protecting property rights" argument is a wash.
Quantum Computers Won't Attack Bitcoin
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.

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.

Quantum Attackers Would Only St= eal Small Amounts
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.

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.

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.

= The 21 Million Coin Supply Should be in Circulation=
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.

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!

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.

Self-Sovereignty and Persona= l 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 shie= ld users from their own negligence undermines the principle that you, and n= ot a third party, are accountable for your assets.

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.

Code = is Law
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.

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.

= Technological Evolution as a Feature, Not a Bug
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.
Market Signals Drive Security
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.

Centralized Blacklisti= ng Power
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.
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.

Fairness in Competition
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.

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.
Economic Resilience
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.

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.

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.

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.

Practicality & Neutrality of Non-Interven= tion
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.

Ph= ilosophical Purity
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.

Bitcoin's DAO Moment
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.

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.

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

Incentives Matter
We can wax philosophi= cal until the cows come home, but what are the actual incentives for existi= ng Bitcoin holders regarding this decision?

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

If tru= e, the corollary is:

"Quantum recovered = coins only make everyone else's coins worth less. Think of it as a theft fr= om everyone." - Jameson Lopp

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?
* It's not good for the actual owners of those coins. It disincentivizes o= wners from upgrading until perhaps it's too late.
* 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.

Forkin= g Game Theory
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?

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.

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 / 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.=

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.

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>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.

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.

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, 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.=

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.

In S= ummary
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.

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.

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

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

--
You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+...@googlegroups= .com.

--
You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+...@googlegroups= .com.

--
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@googl= egroups.com.
To view this discussion visit https://groups.google.com/= d/msgid/bitcoindev/c56b179f-2753-4f1c-80a4-14969e737d37n%40googlegroups.com= .



--
Best regards,
Boris Nagaev



--
Best regards,
Boris Nagaev



--
Best regards,
Boris Nagaev

--
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://grou= ps.google.com/d/msgid/bitcoindev/CAFC_Vt7a1O9vCdycRtUmTAQyL%3DifZAZt3Wzx-YB= TQ1cKyJq55w%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/b= itcoindev/YX1Q8oL5phYHC8fM_m4aHakglTjz1RYlv8k7tGgbq9Rx_jx6BFmG6Y8uA7Vrma0fO= X3kCTD30k0PCUGeBX_bnglN5GWCZdGABxKDOjvt_bA%3D%40proton.me.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/4wCyWd= zfJTskjdcX3WSpbV53KAhAc_CwqS-65RAA9cD1lcttvdFgG4LPY1U8YRlcJrPJMAc_aR_d4uLiU= xMypdxmoMAhN5WDlCByp1mWHnM%3D%40proton.me.
-----------------------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--