From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 22 Sep 2026 16:14:33 -0700 Received: from mail-oi1-f190.google.com ([209.85.167.190]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1x99h2-00029C-6d for bitcoindev@gnusha.org; Tue, 22 Sep 2026 16:14:32 -0700 Received: by mail-oi1-f190.google.com with SMTP id 5614622812f47-4b37620eb73sf753979b6e.1 for ; Tue, 22 Sep 2026 16:14:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1790118866; x=1790723666; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:x-original-sender :content-type:mime-version:subject:message-id:to:from:date:from:to :cc:subject:date:message-id:reply-to:content-type; bh=mWGUV3oDdJ5xwQUyDsH5cbjq4HGl6aE+D9bKq1peaS4=; b=W1PMegKDvpsIqcAsGhJT9XLRodt8IV7irouDj2Z1IN0MT2mNlzJJZzHLQT3PEKb/2F tqUzadHyh1Ls/Xsnwp69LokfekFycF0ClLhT9COecrHrX7p59ikJsQaJJGDLURt0OOwz 5SSgFlGPTBVVBL5edfgsSoI6JAb+yymY7YorKddKNa51F8vla5wZUB0Q7b9kaxiIkjEU 3iP5/qvAzh/TtIfSfo0nR6yTZIG3Qn6FYA7EGta3z+cgs7tG1DfU8gnW+jN9ONONl1Jx Zz6wqZj5VVmQTu8QfN2vsoLfhwfKM9JbiNgL/oiTPrhJIES5R+9/CTdbu2zSbCaa4Gy/ N/xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790118866; x=1790723666; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:x-original-sender :content-type:mime-version:subject:message-id:to:from:date :x-beenthere:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to:content-type; bh=mWGUV3oDdJ5xwQUyDsH5cbjq4HGl6aE+D9bKq1peaS4=; b=Wcwt0WsGd90RWMZ1Zak4Sn2RZ5z+3cMxj9KzMmHnic8BfHlMQVGpXBD8Un6Gnm8+y5 5N4toLO6BRHch2N4C+EJnWMcsvAm6XiNh0hQWg+GZ5EQrY+ESeB7tcyos5aNCZFTrIol XOq5nOjcFaiBLdGHGFmaW85h/ZPuqyrxgupUdIgnGuM2H3ot+TSeWxotCXOwO54tf6cU HsE4yWoPq2wwaDA4KPFBfoPM/T1/pNfji0UmjcHbQ7DtVuoLm2zhrsK2CK9opeGJqA8K cbPf39ItqvdQmiicKZte23xgBdevnW2L/yuNFlwwNtgcseCttCI/rK7ejA2UPeIqYEO5 shrA== X-Forwarded-Encrypted: i=1; AKwUvBw/FV3Tr9tES1ASjqCEFZY11m2tLWCO8Sslcz/U4oca6NJaIDZj84887QMtr98RyFZ5GEQZjyVVzwX0@gnusha.org X-Gm-Message-State: AFuF++lWHTJFZJ15jv4rphWWNYxey7Ue96Aen8hqq2qY1nRrEL1gY69I yOqQACbW1JZDPwWy6VuaZvHe1o5tj3cyw8EofvPxZMG+0CJGsNpEAFXf X-Received: by 2002:a05:6871:a011:b0:484:95af:60fb with SMTP id 586e51a60fabf-49089d63a6amr1027272fac.3.1790118865880; Tue, 22 Sep 2026 16:14:25 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ATskLdeMIbgmbStYWWloQ4ukEJUOItjf0/upGXMc+O1B/UAQCQ==" Received: by 2002:a05:6870:2404:b0:479:e31:7dc5 with SMTP id 586e51a60fabf-48574261728ls7823098fac.1.-pod-prod-07-us; Tue, 22 Sep 2026 16:14:21 -0700 (PDT) X-Received: by 2002:a05:6808:17a2:b0:4c4:d8a0:2773 with SMTP id 5614622812f47-4d5b930b034mr980554b6e.32.1790118861240; Tue, 22 Sep 2026 16:14:21 -0700 (PDT) Received: by 2002:a05:690c:23c2:b0:81e:11b4:1172 with SMTP id 00721157ae682-89adb36ef90ms7b3; Tue, 22 Sep 2026 16:13:07 -0700 (PDT) X-Received: by 2002:a05:690c:e288:10b0:873:5ddf:d875 with SMTP id 00721157ae682-8a45b48d251mr4102717b3.64.1790118786306; Tue, 22 Sep 2026 16:13:06 -0700 (PDT) Date: Tue, 22 Sep 2026 16:13:05 -0700 (PDT) From: "'James T' via Bitcoin Development Mailing List" To: Bitcoin Development Mailing List Message-Id: <305ed790-577c-4c94-a92a-1e15c4536b40n@googlegroups.com> Subject: [bitcoindev] QSAVE post-quantum solution for non-migrated coins MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_155774_496263118.1790118785997" X-Original-Sender: tagg.james@googlemail.com X-Original-From: James T Reply-To: James T 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 (-) ------=_Part_155774_496263118.1790118785997 Content-Type: multipart/alternative; boundary="----=_Part_155775_1934671842.1790118785997" ------=_Part_155775_1934671842.1790118785997 Content-Type: text/plain; charset="UTF-8" QSAVE is a post-quantum transition solution that avoids burning coins. I have tried to incorporate the feedback I received on my earlier posts. The proposed solution is laid out in five draft BIPs, with MediaWiki sources at https://www.qsave.org/legal/bip-suite. Earlier posts were: [BIP Proposal] No burn, Quantum Migration Proposal, Quantum Secure Asset Verification & Escrow (QSAVE) 1. bip-qsave-conditional-spending: classifies every spent input and sends spends without a second factor to recovery. 2. bip-qsave-watermarks: pre-cutoff commitments and the registry of accepted second factors. 3. bip-qsave-seed-derivation-factor: a zero-knowledge proof that one seed derives both the spent script and the post-quantum authority. 4. bip-qsave-protective-recovery: the lost-property output and the two ways it is released. 5. bip-qsave-p2mr-zkstark: a zk-STARK spend leaf for BIP 360 P2MR outputs. QD5 is an optional source-matched authority profile using an independently backed-up ML-DSA-87 key. It can be admitted as an automatic-factor route, but it is not required for every coin unless a later consensus deployment marks it mandatory for a defined source class. That marking would send inputs without QD5 or an accepted replacement factor through protective recovery. QSAVE is an alternative to BIP 361 or Hourglass for handling coins left behind in a post-quantum chain migration. It has no sunset or burn; instead, it proposes a lost-property process. The scheme can be implemented in the 'do-nothing' scenario by making white-hat hacking legal where the intent is to protect the coins. I hope a soft fork can be agreed upon that would make transfer to lost-property addresses the only output possible for a non-migrated address after a certain block height. If such a soft fork cannot be agreed upon, we would be in a quantum safari situation, with white-hat hackers competing with black-hat hackers and a great deal of law-enforcement activity, which would be unfortunate. Our proposal is to add a second factor that provides a quantum-resistant proof of ownership. After a certain block height, coins can no longer be spent with their ECC key alone. The script and its signatures are still required as factor one, but a second factor is also needed, such as a proof that the address derives from the wallet seed, or a post-quantum binding record committed before the cutoff height. If the second factor is missing, the coin can only be moved to protective recovery: a lost-property address that allows a longer recovery period. During the recovery period, which might be indefinite for some coins, the policy may direct returns to charities. This is along the lines of the Dormant Assets Act 2022 in the UK; the legal and economic treatment remains outside Bitcoin consensus. The design is intended to provide three things: 1. The existing private key is still required, quantum-derived or not, so nothing happens faster than it would in the do-nothing branch. 2. A missing second factor never burns the coin; there is no sunset. 3. An on-chain asymmetric proof of ownership spends the coin directly with no third party, or an off-chain route can eventually recover it through a lost-property office and an evidentiary procedure. >From the enforcement height (which consensus can switch on at any time), ordinary validation runs first. Each input of a valid transaction is then classified. POST_QUANTUM_NATIVE inputs match an entry in the activated native-path registry and are authorized by that path's own rules. Everything else is UNMIGRATED_TWO_FACTOR_REQUIRED, including unknown and future script types. If any unmigrated input lacks a valid second factor, every spendable output must be a recovery output. A set of decentralized custodians hold recovery outputs, with a backup custodian and a veto controller. This keeps funds decentralized while avoiding capture by an errant actor. Funds held as lost property can earn conservative returns (0.5%) that can be directed toward charitable purposes. Recovery from this state may be automatic if you provide second-factor information. If no on-chain second-factor information is available, you must undertake evidence-based recovery. This way, all coins, including early Satoshi-era coins, can earn money for charity and be reclaimed in perpetuity. Although this is no longer a permissionless process (humans are involved), all the other routes lead to human (usually law enforcement) involvement, so we think this is the better consensus approach. If Bitcoin doesn't resolve this problem, someone else will do it for us, and that is unlikely to be a good outcome. Thanks, James Tagg -- 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/bitcoindev/305ed790-577c-4c94-a92a-1e15c4536b40n%40googlegroups.com. ------=_Part_155775_1934671842.1790118785997 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

QSAVE is a post-quantum transition solution that avoids burning coins. I= have tried to incorporate the feedback I received on my earlier posts. The= proposed solution is laid out in five draft BIPs, with MediaWiki sources a= t https://www.qsave.org/legal/bip-suite.

Earlier posts were: [BIP Proposal] No burn, Quantum Migration Proposal, = Quantum Secure Asset Verification & Escrow (QSAVE)

1. bip-qsave-conditional-spending: classifies every spent input and send= s spends without a second factor to recovery.

2. bip-qsave-watermarks: pre-cutoff commitments and the registry of acce= pted second factors.

3. bip-qsave-seed-derivation-factor: a zero-knowledge proof that one see= d derives both the spent script and the post-quantum authority.

4. bip-qsave-protective-recovery: the lost-property output and the two w= ays it is released.

5. bip-qsave-p2mr-zkstark: a zk-STARK spend leaf for BIP 360 P2MR output= s.

QD5 is an optional source-matched authority profile using an independent= ly backed-up ML-DSA-87 key. It can be admitted as an automatic-factor route= , but it is not required for every coin unless a later consensus deployment= marks it mandatory for a defined source class. That marking would send inp= uts without QD5 or an accepted replacement factor through protective recove= ry.

QSAVE is an alternative to BIP 361 or Hourglass for handling coins left = behind in a post-quantum chain migration. It has no sunset or burn; instead= , it proposes a lost-property process. The scheme can be implemented in the= 'do-nothing' scenario by making white-hat hacking legal where the intent i= s to protect the coins. I hope a soft fork can be agreed upon that would ma= ke transfer to lost-property addresses the only output possible for a non-m= igrated address after a certain block height. If such a soft fork cannot be= agreed upon, we would be in a quantum safari situation, with white-hat hac= kers competing with black-hat hackers and a great deal of law-enforcement a= ctivity, which would be unfortunate.

Our proposal is to add a second factor that provides a quantum-resistant= proof of ownership. After a certain block height, coins can no longer be s= pent with their ECC key alone. The script and its signatures are still requ= ired as factor one, but a second factor is also needed, such as a proof tha= t the address derives from the wallet seed, or a post-quantum binding recor= d committed before the cutoff height.

If the second factor is missing, the coin can only be moved to protectiv= e recovery: a lost-property address that allows a longer recovery period. D= uring the recovery period, which might be indefinite for some coins, the po= licy may direct returns to charities. This is along the lines of the Dorman= t Assets Act 2022 in the UK; the legal and economic treatment remains outsi= de Bitcoin consensus.

The design is intended to provide three things:

1. The existing private key is still required, quantum-derived or not, s= o nothing happens faster than it would in the do-nothing branch.

2. A missing second factor never burns the coin; there is no sunset.

3. An on-chain asymmetric proof of ownership spends the coin directly wi= th no third party, or an off-chain route can eventually recover it through = a lost-property office and an evidentiary procedure.

From the enforcement height (which consensus can switch on at any time),= ordinary validation runs first. Each input of a valid transaction is then = classified. POST_QUANTUM_NATIVE inputs match an entry in the activated nati= ve-path registry and are authorized by that path's own rules. Everything el= se is UNMIGRATED_TWO_FACTOR_REQUIRED, including unknown and future script t= ypes. If any unmigrated input lacks a valid second factor, every spendable = output must be a recovery output. A set of decentralized custodians hold re= covery outputs, with a backup custodian and a veto controller. This keeps f= unds decentralized while avoiding capture by an errant actor. Funds held as= lost property can earn conservative returns (0.5%) that can be directed to= ward charitable purposes.

Recovery from this state may be automatic if you provide second-factor i= nformation. If no on-chain second-factor information is available, you must= undertake evidence-based recovery. This way, all coins, including early Sa= toshi-era coins, can earn money for charity and be reclaimed in perpetuity.= Although this is no longer a permissionless process (humans are involved),= all the other routes lead to human (usually law enforcement) involvement, = so we think this is the better consensus approach. If Bitcoin doesn't resol= ve this problem, someone else will do it for us, and that is unlikely to be= a good outcome.=C2=A0

Thanks,

James Tagg

--
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/bitcoind= ev/305ed790-577c-4c94-a92a-1e15c4536b40n%40googlegroups.com.
------=_Part_155775_1934671842.1790118785997-- ------=_Part_155774_496263118.1790118785997--