From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 18 Jan 2026 05:57:12 -0800 Received: from mail-oa1-f59.google.com ([209.85.160.59]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vhTHD-0007KV-9B for bitcoindev@gnusha.org; Sun, 18 Jan 2026 05:57:11 -0800 Received: by mail-oa1-f59.google.com with SMTP id 586e51a60fabf-4042e22be4bsf8526033fac.1 for ; Sun, 18 Jan 2026 05:57:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1768744625; x=1769349425; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=1tysk5eKR7egeQozopMhkuzLDlPMPtAPkyOh9RhRZH0=; b=iMfaS0zp9Y7Ae4ZpvVgNoiIphUrJtsrNwfBFbLBVCxbs679XmWe9y+UZX+DJUBZK1d FM5oTliBjl4aRt9Hf8FmJGRKNzFztMlBxltTs10zkZb52XF90aV6mz7AR0BJFKSIfzOR x1ceVfVWpX4aFBSnkzB+28TLaT4q28+eNcP8bRN+EwW58tTukWS193zNT2110F/CGTe5 36bM7krvcK0AEb0LTQQ/+bPGG+sAb2k4QT7vx8miw1+Rnog+lTSZGnfQYL8hZhEaUw5b qQK3f76Q7GJcjo2PndX68aNMOdnW0crIDihwuYTMNBGrzBaFJGKW2I1A+fS37WU2t6gR Hy5w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768744625; x=1769349425; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=1tysk5eKR7egeQozopMhkuzLDlPMPtAPkyOh9RhRZH0=; b=ey9a7j4gOWTnGtD6Gb0YSyi2iceJFML1uc6QSiwa1aZSjELdAiASMukxO7keVvVqq7 LZ2eEu+L88TAj//PKpakVzMgQfVPgaxYgWbWYru+Mqk/CT9KrLnm+s9+wiCJd+IsNEkZ NB6l7odIC8tV12M5UOpeCU+K3zD/N19p9Wn+p7S3lhnGWKJwA+VWWaAQ7p8oAFphW1OF hYF7EYX6FHVbR/xb4YFzyOrQ37dwgDzE4Ul2HaVFwKBV5cbLAaseI7yKh+ACkkG+TuIi +EB4JMH/MtadqyQ234ff1TD/zQsmYXT5QwQnXqja1k6tJrnGoy61+6xFhWrlyjsJZA21 yDrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768744625; x=1769349425; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=1tysk5eKR7egeQozopMhkuzLDlPMPtAPkyOh9RhRZH0=; b=E+3E1Zk8dL/ayvGjoV3NXoz746Tep4LG454DOdx3NLoJYIF1uJRPuR/sLqt9xxOBdb EgLM6/KsJfJJ19Rqo7zPnnAUkhebPJ8ahLI5pL/blZ2wzGaTnnTN1pTIySA8Yd91x02C RdJ1XGqsuHmERKGspN0kI5BynRbqJHLCvkIHciQ+VD8vzp9FVM+3GXSc1Z8sFeozlz78 oIQKs2J1wUylhWHwbVNHZf8PdfIAk6kidCbcWWdDP8Gr6L26BQ+knHkiNT4TsIu7q02+ fvtR8Z0dzmOEcQ/hvVe6zCdad/PylJFJaWEOTtyN9rh07mWne4sJ7GIHNXjFUxpFYxib ylVQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCVkNPO1GVK1LrkZkPluGU+yVeJwfCgMWAMOTxAoI8rDfvbhB4Ux9etrn5NL+ytaxiEPTEiFmbFeOnWd@gnusha.org X-Gm-Message-State: AOJu0YyaBMyt6Os70wVZ4bvZ1oCbS6uTUq44JJ8tScmYbmI1F+t6Qbs9 iwcU/6ma9DYiBiZTbmoZ2ySwTM0BAiA91oaE4JBgdZRzQK43yd8/sbGx X-Received: by 2002:a05:6870:c215:b0:3e8:9537:f84c with SMTP id 586e51a60fabf-4044c489fdemr4558135fac.46.1768744624637; Sun, 18 Jan 2026 05:57:04 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+G5kxCtepXeGWj5wprtVD2hiSAyOAVk7u6GWrsytZ++/Q==" Received: by 2002:a05:6870:420c:b0:3e8:4817:7a50 with SMTP id 586e51a60fabf-4042850176bls2526410fac.0.-pod-prod-05-us; Sun, 18 Jan 2026 05:56:59 -0800 (PST) X-Received: by 2002:a05:6808:448a:b0:45c:916b:ef9c with SMTP id 5614622812f47-45c9d78a867mr3110391b6e.29.1768744619203; Sun, 18 Jan 2026 05:56:59 -0800 (PST) Received: by 2002:a05:690c:e3ce:b0:786:8d90:70d8 with SMTP id 00721157ae682-793c7d804b2ms7b3; Sun, 18 Jan 2026 05:45:01 -0800 (PST) X-Received: by 2002:a05:690c:fd5:b0:78c:6771:77bb with SMTP id 00721157ae682-793c66c70ddmr61421187b3.14.1768743900600; Sun, 18 Jan 2026 05:45:00 -0800 (PST) Date: Sun, 18 Jan 2026 05:44:59 -0800 (PST) From: Giulio Golinelli To: Bitcoin Development Mailing List Message-Id: <28f8d816-cc97-4913-8912-0aa955d3322cn@googlegroups.com> In-Reply-To: References: Subject: =?UTF-8?Q?=5Bbitcoindev=5D_Re=3A_QRAMP_addition=3A_Alternative_to_lega?= =?UTF-8?Q?cy_freeze=3A_=E2=80=9Cquarantine=2Dmode=E2=80=9D_legacy_spends_via_two=2Dphase?= =?UTF-8?Q?_destination_commitment?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_130680_493910294.1768743899920" X-Original-Sender: golinelli.giulio13@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_130680_493910294.1768743899920 Content-Type: multipart/alternative; boundary="----=_Part_130681_12853199.1768743899920" ------=_Part_130681_12853199.1768743899920 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Bnav, thank you for sharing your idea. I=E2=80=99ve reviewed the markdown document, and while I can see how it cou= ld=20 address the *destination-substitution hijack* problem, I think a much=20 larger issue still remains: *unspent UTXOs*. In your protocol, Phase 2 (the transaction phase) still requires the=20 spender to produce a classical ECDSA signature. This inevitably reveals the= =20 public key and puts the corresponding private key at risk. A sufficiently capable quantum attacker would likely not need to race a=20 live transaction during mining or while it sits in the mempool. Instead,=20 they could recover private keys from already-revealed public keys offline= =20 and then sweep all remaining unspent UTXOs associated with those keys at=20 his leisure. >From a technological standpoint, this kind of offline key-recovery attack= =20 against exposed public keys is likely to become feasible earlier than a=20 real-time transaction hijack scenario. That said, assuming a=20 quantum-resistant commitment scheme and the necessary protocol mechanics=20 (to be defined and evaluated), I can see how the construction would work=20 for its intended, narrower 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 scritto= : > Hi Everyone, > > I=E2=80=99d like feedback on a concept that I want to frame explicitly as= an *alternative* to =E2=80=9Cfreeze/sunset legacy signatures=E2=80=9D in Q= RAMP (Quantum=E2=80=91Resistant Address Migration Protocol) or similar migr= ation planning. > > Instead of making legacy ECDSA spends invalid after a cutoff, we could pl= ace 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 de= stination-substitution even if the legacy private key can be derived quickl= y after pubkey reveal. > > High-level: > 1) **Commit phase (on-chain):** publish a commitment that binds the event= ual 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 present= s (a) proof that a matching commitment was mined and is mature, and (b) the= spend=E2=80=99s outputs match the committed template. > > Key feasibility constraint: this must be **consensus-enforced without his= torical tx lookups** (pruned nodes / no txindex). So the spend likely needs= to carry an SPV-style inclusion proof for the commit (txid + merkle branch= to a block header + =E2=89=A5K depth rule). > > A critical UX point is **fee sponsorship**: a receiver/exchange/service c= an publish the commit tx and pay fees, while the legacy holder authorizes t= he 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_destin= ation_commitment.md > - Diagram: https://github.com/bnavf/bitcoinqp/blob/main/two_phase_destina= tion_commitment.svg > > Questions for the list: > 1) Is there an existing proposal that already captures this =E2=80=9Cquar= antine-mode legacy spends=E2=80=9D framing? > 2) What=E2=80=99s the most reasonable way to do commitment inclusion/matu= rity proofs without creating an indexer-dependent consensus rule? > 3) Is binding the *full output set* sufficient to rule out practical dest= ination-substitution variants? > > Thanks for any critique or pointers. > Best, > Bnav > > --=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/= 28f8d816-cc97-4913-8912-0aa955d3322cn%40googlegroups.com. ------=_Part_130681_12853199.1768743899920 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

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= your protocol, Phase 2 (the transaction phase) still requires the spender = to produce a classical ECDSA signature. This inevitably reveals the public = key and puts the corresponding private key at risk.
A sufficiently cap= able quantum attacker would likely not need to race a live transaction duri= ng mining or while it sits in the mempool. Instead, they could recover priv= ate keys from already-revealed public keys offline and then sweep all remai= ning unspent UTXOs associated with those keys at his leisure.
From a t= echnological standpoint, this kind of offline key-recovery attack against e= xposed public keys is likely to become feasible earlier than a real-time tr= ansaction hijack scenario. That said, assuming a quantum-resistant commitme= nt scheme and the necessary protocol mechanics (to be defined and evaluated= ), I can see how the construction would work for its intended, narrower pur= pose.

Let me know if you agree/disagree,
Giulio

Il giorno mercoled=C3= =AC 14 gennaio 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/bn=
avf/bitcoinqp/blob/main/two_phase_destination_commitment.md
- Diagram: https://github.com/b=
navf/bitcoinqp/blob/main/two_phase_destination_commitment.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 &= 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/28f8d816-cc97-4913-8912-0aa955d3322cn%40googlegroups.com.
------=_Part_130681_12853199.1768743899920-- ------=_Part_130680_493910294.1768743899920--