From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 19 Jan 2026 18:33:18 -0800 Received: from mail-oi1-f189.google.com ([209.85.167.189]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vi1YT-0003gk-TN for bitcoindev@gnusha.org; Mon, 19 Jan 2026 18:33:18 -0800 Received: by mail-oi1-f189.google.com with SMTP id 5614622812f47-45c8650ffcasf6217196b6e.1 for ; Mon, 19 Jan 2026 18:33:17 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1768876391; cv=pass; d=google.com; s=arc-20240605; b=K4MJO85sGvPHRKxpWk85aEHP1wodQuEQPZ2qJFtPlb9WkXHCprOw3d2rZJ6dXWSVru 9ABxIcCDrGz9WBsOYLPTBwykjpSrM2JFMWsRxFF7LP3ZUXf6DEQHr8wwMF8WyEQZc+Mo u2rIxnAmJgrv1cUjxX1jZK0/DQfgJ8ntEITIoZbEnKxu9R9SiYVoRGgVV72bRKg8Q1O6 4BKBxMBQSJ1T0sLhHrkYyagUz6tTX87JYux6OTPKV5VLEVuOBKbizSqDSOOJHS7jCEF7 Ib4PKsCgS5RwTD8TxNGRwyBIkvItZfRgiD4EbFddeJgjzlpZ4So1/iRVFxLl9Gx4o15V 0Cbw== 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=tbt8OYipsCOkhZojqW8vluRktkTwvd5DIiHMRrFpRgY=; fh=nrMyP99u9rBBfh2/lsG6EbfmGC3P0VummmO9CxR95sE=; b=AshYlWoflALTd2FZJ8m8JJQtnoA2WQ0RzHR7xCc9yX/ZIotYugtD/a3Tsuas0UQu76 aXVb0MwReTvRo7ZmFNvE6lipFjk4Z4uqOQzvt6ehn6OSIooevTuzC2gfusL3iDlzGtHo Kfe5umlUN7S1EdHLTUnuhAA3omQW+4ZF1V2vsKNDHFYuspCEiWicvoOyoqYLKem8sOlA cQN8fECrS0aeEBpFYnyKzs7AFconR2ScnD4YiMVeV0pvNUSc5yf+nYW4B/hQPuEcYkrg q4yO6+GSRZI/7pMU1XbwH41sBR272hBqVFhHLlGdNCJYUl7wh2mJNJwHpB96F34jmzux z53w==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=MB7R8Z5V; spf=pass (google.com: domain of bnavf@proton.me designates 79.135.106.99 as permitted sender) smtp.mailfrom=bnavf@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=1768876391; x=1769481191; 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=tbt8OYipsCOkhZojqW8vluRktkTwvd5DIiHMRrFpRgY=; b=nUTKJK2sYjzNGbsGz0uc4czK4+tz0rJrQgaudOXYpjA4xnoynhl2LisUouIZUHqqyi f6aY8JuuLoKfogkqmVXhDS8g5yS3KKXOd+U8F9IZ1tc39l6+R50auahZH83K9HYJvJcW 8eKLM2DQRu37L83WI8clTsuf1RR+3JIEm9zpACfBHLRKMGASDsn6HAtagyhEZFNpoWaN np14IAI0vLLudLiEWfMozwaFWTWO1rTxQZllGf5+tU1sMFgw4ygP7S+duh6Mksftgjgk KHzkHdDx4DFj9nNZv4lKcp+95hiE9RAoH5xLulHdLjKbvIqPiZUMvcHvedyjnh51rFBy XSdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768876391; x=1769481191; 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=tbt8OYipsCOkhZojqW8vluRktkTwvd5DIiHMRrFpRgY=; b=VnU6MSQmCPB7gtzXckSGkQTtIz/il2DLRor52/frM7f2BCqrbhE9ns/ERZiaN5P5T+ HATrlJGporsAE9b0inFuDT/u4ukydS2ApKF0t/TOb74UlCxvyIVdpoEP4KoR9uFvP9Mz 0Dt2UOxh4O5Pk+JoEU7TgVOFyvWj/HVwHjro25L1z7FVyNbvz79SOymkLm4rX0a+UDWd HG+x+AWPlcCqEvFDrwHhn8tuvA2mM7mwWsS15Z4ds4t3p/J+wa4bgrnaXAZyZCcL2vSc Q1pjS5fT5zNpSMr0zm6i8S44A7/y48k5Pum1VwnXWklQdUr/0BZl+Dh27nUicwIBAHXx ZiQw== X-Forwarded-Encrypted: i=2; AJvYcCXfIh00clDBCiIk2fhAeZRnKKIppO7mhzyeUGqtNYpzAFTD2lsdhMc6wQMV0XXfruUDxMzKQzwjdsKP@gnusha.org X-Gm-Message-State: AOJu0Yyc4eF43KCtssIurvXrP0GQJ15pq2HFSwSNl4LDPiO36vxlZzsA wqNWQgEs6DFfkhHh9EDNe1cgMQbiRM0Ip5UxcRnzYbX7Wz//pXCVhYlf X-Received: by 2002:a05:6808:2206:b0:45c:9b88:d368 with SMTP id 5614622812f47-45c9d85901bmr4916542b6e.39.1768876391139; Mon, 19 Jan 2026 18:33:11 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+GMeX3Z7BPRlglW8KiGq50/u59ZFz2JLLmPcWYcGC/dFg==" Received: by 2002:a05:6870:a106:b0:3ec:5074:681b with SMTP id 586e51a60fabf-40428a913ffls2492894fac.2.-pod-prod-06-us; Mon, 19 Jan 2026 18:33:06 -0800 (PST) X-Received: by 2002:a05:6808:1815:b0:45c:8bfc:4194 with SMTP id 5614622812f47-45c9d929a03mr6253293b6e.65.1768876386532; Mon, 19 Jan 2026 18:33:06 -0800 (PST) Received: by 2002:a05:6402:208c:10b0:64b:3e1b:1324 with SMTP id 4fb4d7f45d1cf-654d3835cddmsa12; Mon, 19 Jan 2026 15:56:00 -0800 (PST) X-Received: by 2002:a05:6402:270c:b0:64b:6ebf:b65b with SMTP id 4fb4d7f45d1cf-654524cf295mr10340556a12.5.1768866958040; Mon, 19 Jan 2026 15:55:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1768866958; cv=none; d=google.com; s=arc-20240605; b=e+xbQg21IvVss8GzsR/oihgb3fgGe7F6olfXmbC0itJRmMoMQfGWGqyZpO0nYJl8Pw GuHvYl1+TiGjnvgu8JSuCHQ5pQBPw6oaVjMZkUz12Pe6V0HxtLyN+IzqrIaV2tQL4uJB VlhNFR+l02UK1wz3xXxZtB4fFpH6YCC1rKtUBJxj7F+eaMucjvR0P1sf4GM8zOqz7kLK CtUTxctSSBOd3+JJH2vdH/6vGG96giZEqsMGMlgmXqR8QpAbh2c+ACvOkuvHfuoJleCm gPqEBWzbfcJ5m5qaCjFV8HLwbh0aqJmyh43yHWnRkErEnRLg8n2VR5O8LHwrULbYJYkI VjSA== 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=jJzxfasBypMvlHIbbghE9zpFeYgrU4SDOnvPxI2L3dI=; fh=xlGXdwx/AOGpOY1BIwU4GAlWnzM8ndEKiseeCUWJ6As=; b=A0/2U8Ry0yzXBpnVwAgqC0dKkW66kN7qGbHdxCbeVo4ajmwmNDKzt2JKBLA792ErTS JXzL0nGjHr0jrCl5XbewwpxuAHQnJAcwIcb90sNCyg5KrQpxc86gyhNqxaupeOq2ORxv il97zw5jbnFJbRH8i9QJXXT6HKAkFAUTCcBvPHI//w+SJdp3ULPmWJCWhtyJz9+zhK1X Jc1qL/qmz5MTVPZVFpLViIPlkagIs1UNzqdFO/+zWonZON911Quf0k7cWBRa6RwnknyI Ywi8y0hX1OMJoS38B+moaF8V2eKqWudTUAwxW2x7UPOJO5Ye6ohvPA0FWGL3HkRZGasx c9Qw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=MB7R8Z5V; spf=pass (google.com: domain of bnavf@proton.me designates 79.135.106.99 as permitted sender) smtp.mailfrom=bnavf@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-10699.protonmail.ch (mail-10699.protonmail.ch. [79.135.106.99]) by gmr-mx.google.com with ESMTPS id 4fb4d7f45d1cf-654532d768bsi239939a12.7.2026.01.19.15.55.57 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Jan 2026 15:55:58 -0800 (PST) Received-SPF: pass (google.com: domain of bnavf@proton.me designates 79.135.106.99 as permitted sender) client-ip=79.135.106.99; Date: Mon, 19 Jan 2026 23:55:53 +0000 To: Giulio Golinelli From: "'bnv' via Bitcoin Development Mailing List" Cc: Bitcoin Development Mailing List Subject: =?UTF-8?Q?Re=3A_=5Bbitcoindev=5D_Re=3A_QRAMP_addition=3A_Alternative_to_?= =?UTF-8?Q?legacy_freeze=3A_=E2=80=9Cquarantine=2Dmode=E2=80=9D_legacy_spends_via_two=2Dp?= =?UTF-8?Q?hase_destination_commitment?= Message-ID: <2995yQfEoeQ7ZsvOBY7r5lnmL7VaqnD73w2DNYu61z8M9m5X9Q7KfkE2sWQSTIcyaUI7TPin36CIsHH9pyJn5nY95yjEg67774_vvIvX1go=@proton.me> In-Reply-To: <28f8d816-cc97-4913-8912-0aa955d3322cn@googlegroups.com> References: <28f8d816-cc97-4913-8912-0aa955d3322cn@googlegroups.com> Feedback-ID: 176017630:user:proton X-Pm-Message-ID: d534c71a94b2eda1c9a70908c29cb0a56b4db01d MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1=_MBicdJbJ71sIixk0H26Gr8oRmqlMoqzYkNu8FFtL6lY" X-Original-Sender: bnavf@proton.me X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=MB7R8Z5V; spf=pass (google.com: domain of bnavf@proton.me designates 79.135.106.99 as permitted sender) smtp.mailfrom=bnavf@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me X-Original-From: bnv Reply-To: bnv 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 (-) --b1=_MBicdJbJ71sIixk0H26Gr8oRmqlMoqzYkNu8FFtL6lY Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Gulio, Thank you for the feedback! I agree with all what you said but the intention of the proposal not to sec= ure the address from where we are sending funds but to avoid the race betwe= en legitimate sender and a quantum attacker. Of course, the transaction MUST shift ALL coins from old address to a new o= ne and the address MUST not be never used again for receiving any coins. Th= at is very old recommendation which probably was promoted even by Satoshi i= tself! Why I have written that QRAMP addition: I am not happy with QRAMP proposal = to freeze old coins sitting on old addresses. With that addition we retain = possibility to send these coins to new addresses for indefinite time. Thank you! Bnav Sent with [Proton Mail](https://proton.me/mail/home) secure email. On Monday, January 19th, 2026 at 2:57 AM, Giulio Golinelli wrote: > Hi Bnav, thank you for sharing your idea. > > I=E2=80=99ve reviewed the markdown document, and while I can see how it c= ould address the destination-substitution hijack problem, I think a much la= rger issue still remains: unspent UTXOs. > In your protocol, Phase 2 (the transaction phase) still requires the spen= der to produce a classical ECDSA signature. This inevitably reveals the pub= lic key and puts the corresponding private key at risk. > A sufficiently capable quantum attacker would likely not need to race a l= ive transaction during mining or while it sits in the mempool. Instead, the= y could recover private keys from already-revealed public keys offline and = then sweep all remaining unspent UTXOs associated with those keys at his le= isure. > From a technological standpoint, this kind of offline key-recovery attack= against exposed public keys is likely to become feasible earlier than a re= al-time transaction hijack scenario. That said, assuming a quantum-resistan= t commitment scheme and the necessary protocol mechanics (to be defined and= evaluated), I can see how the construction would work for its intended, na= rrower purpose. > > Let me know if you agree/disagree, > Giulio > > Il giorno mercoled=C3=AC 14 gennaio 2026 alle 08:07:34 UTC+8 bnv ha scrit= to: > >> Hi Everyone, >> >> I=E2=80=99d like feedback on a concept that I want to frame explicitly a= s an *alternative* to =E2=80=9Cfreeze/sunset legacy signatures=E2=80=9D in = QRAMP (Quantum=E2=80=91Resistant Address Migration Protocol) or similar mig= ration planning. >> >> Instead of making legacy ECDSA spends invalid after a cutoff, we could p= lace them into a **quarantine mode**: >> - Legacy UTXOs remain spendable after post-quantum (PQ) activation, >> - but only via a **two-phase commit=E2=86=92spend** flow that prevents d= estination-substitution even if the legacy private key can be derived quick= ly after pubkey reveal. >> >> High-level: >> 1) **Commit phase (on-chain):** publish a commitment that binds the even= tual spend outputs (preferably the full output set: amounts + scriptPubKeys= ) and becomes valid only after =E2=89=A5K confirmations. >> 2) **Spend phase (on-chain):** a legacy spend is valid only if it presen= ts (a) proof that a matching commitment was mined and is mature, and (b) th= e spend=E2=80=99s outputs match the committed template. >> >> Key feasibility constraint: this must be **consensus-enforced without hi= storical tx lookups** (pruned nodes / no txindex). So the spend likely need= s to carry an SPV-style inclusion proof for the commit (txid + merkle branc= h to a block header + =E2=89=A5K depth rule). >> >> A critical UX point is **fee sponsorship**: a receiver/exchange/service = can publish the commit tx and pay fees, while the legacy holder authorizes = the commitment off-chain (signature over the commitment hash), avoiding the= =E2=80=9CI can=E2=80=99t safely fee-pay Phase 1=E2=80=9D problem. >> >> Short design note + diagram (please replace with your links): >> - Markdown: >> https://github.com/bnavf/bitcoinqp/blob/main/two_phase_destination_commi= tment.md >> - Diagram: >> https://github.com/bnavf/bitcoinqp/blob/main/two_phase_destination_commi= tment.svg >> Questions for the list: >> 1) Is there an existing proposal that already captures this =E2=80=9Cqua= rantine-mode legacy spends=E2=80=9D framing? >> 2) What=E2=80=99s the most reasonable way to do commitment inclusion/mat= urity proofs without creating an indexer-dependent consensus rule? >> 3) Is binding the *full output set* sufficient to rule out practical des= tination-substitution variants? >> >> Thanks for any critique or pointers. >> Best, >> Bnav > > -- > 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/28f8d816-cc97-4913-8912-0aa955d3322cn%40googlegroups.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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= 2995yQfEoeQ7ZsvOBY7r5lnmL7VaqnD73w2DNYu61z8M9m5X9Q7KfkE2sWQSTIcyaUI7TPin36C= IsHH9pyJn5nY95yjEg67774_vvIvX1go%3D%40proton.me. --b1=_MBicdJbJ71sIixk0H26Gr8oRmqlMoqzYkNu8FFtL6lY Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Gulio,

Thank yo= u for the feedback!

I agree with all what you said but the intention of the propos= al not to secure the address from where we are sending funds but to avoid t= he race between legitimate sender and a quantum attacker.

Of course, the transa= ction MUST shift ALL coins from old address to a new one and the address MU= ST not be never used again for receiving any coins. That is very old recomm= endation which probably was promoted even by Satoshi itself!

Why I have written th= at QRAMP addition: I am not happy with QRAMP proposal to freeze old coins s= itting on old addresses. With that addition we retain possibility to send t= hese coins to new addresses for indefinite time.

Thank you!
Bnav

 

=20
=20
Sent with Proton Mail secure email.

<= div class=3D"protonmail_quote"> On Monday, January 19th, 2026 at 2:57 AM, Giulio Golinelli <goli= nelli.giulio13@gmail.com> wrote:

Hi Bnav, thank you for sharing your idea.

I=E2=80=99ve reviewed the markdown document, and while I can see how it = could address the destination-substitution hijack problem, I think= a much larger issue still remains: unspent UTXOs.
In y= our protocol, Phase 2 (the transaction phase) still requires the spender to= produce a classical ECDSA signature. This inevitably reveals the public ke= y and puts the corresponding private key at risk.
A sufficiently capable= quantum attacker would likely not need to race a live transaction during m= ining or while it sits in the mempool. Instead, they could recover private = keys from already-revealed public keys offline and then sweep all remaining= unspent UTXOs associated with those keys at his leisure.
From a technol= ogical standpoint, this kind of offline key-recovery attack against exposed= public keys is likely to become feasible earlier than a real-time transact= ion hijack scenario. That said, assuming a quantum-resistant commitment sch= eme and the necessary protocol mechanics (to be defined and evaluated), I c= an see how the construction would work for its intended, narrower purpose.<= /p>

Let me know if you agree/disagree,
Giulio

Il giorno mercoled=C3=AC 14 ge= nnaio 2026 alle 08:07:34 UTC+8 bnv ha scritto:
Hi Everyone,

I=E2=80=99d like feedback on a concept that I want to frame explicitly as a=
n *alternative* to =E2=80=9Cfreeze/sunset legacy signatures=E2=80=9D in QRA=
MP (Quantum=E2=80=91Resistant Address Migration Protocol) or similar migrat=
ion planning.

Instead of making legacy ECDSA spends invalid after a cutoff, we could plac=
e them into a **quarantine mode**:
- Legacy UTXOs remain spendable after post-quantum (PQ) activation,
- but only via a **two-phase commit=E2=86=92spend** flow that prevents dest=
ination-substitution even if the legacy private key can be derived quickly =
after pubkey reveal.

High-level:
1) **Commit phase (on-chain):** publish a commitment that binds the eventua=
l spend outputs (preferably the full output set: amounts + scriptPubKeys) a=
nd becomes valid only after =E2=89=A5K confirmations.
2) **Spend phase (on-chain):** a legacy spend is valid only if it presents =
(a) proof that a matching commitment was mined and is mature, and (b) the s=
pend=E2=80=99s outputs match the committed template.

Key feasibility constraint: this must be **consensus-enforced without histo=
rical tx lookups** (pruned nodes / no txindex). So the spend likely needs t=
o carry an SPV-style inclusion proof for the commit (txid + merkle branch t=
o a block header + =E2=89=A5K depth rule).

A critical UX point is **fee sponsorship**: a receiver/exchange/service can=
 publish the commit tx and pay fees, while the legacy holder authorizes the=
 commitment off-chain (signature over the commitment hash), avoiding the =
=E2=80=9CI can=E2=80=99t safely fee-pay Phase 1=E2=80=9D problem.

Short design note + diagram (please replace with your links):
- Markdown: https://github.com/bnavf/bitcoinqp/blob/main/two_phase_destination_commitm=
ent.md
- Diagram: https://github.com/bnavf/bitcoinqp/blob/main/two_phase_destination_commitm=
ent.svg

Questions for the list:
1) Is there an existing proposal that already captures this =E2=80=9Cquaran=
tine-mode legacy spends=E2=80=9D framing?
2) What=E2=80=99s the most reasonable way to do commitment inclusion/maturi=
ty proofs without creating an indexer-dependent consensus rule?
3) Is binding the *full output set* sufficient to rule out practical destin=
ation-substitution variants?

Thanks for any critique or pointers.
Best,
Bnav

--
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/28f8d816-cc97-4913-8912-0aa955d3322cn%40googlegroups.com= .

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/2995yQ= fEoeQ7ZsvOBY7r5lnmL7VaqnD73w2DNYu61z8M9m5X9Q7KfkE2sWQSTIcyaUI7TPin36CIsHH9p= yJn5nY95yjEg67774_vvIvX1go%3D%40proton.me.
--b1=_MBicdJbJ71sIixk0H26Gr8oRmqlMoqzYkNu8FFtL6lY--