From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 13 Jan 2026 16:07:41 -0800 Received: from mail-qt1-f185.google.com ([209.85.160.185]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vfoQG-0000B0-Do for bitcoindev@gnusha.org; Tue, 13 Jan 2026 16:07:40 -0800 Received: by mail-qt1-f185.google.com with SMTP id d75a77b69052e-4f1f42515ffsf231623061cf.0 for ; Tue, 13 Jan 2026 16:07:40 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1768349254; cv=pass; d=google.com; s=arc-20240605; b=JflzpuFVTJWyGPAHyCIFm6iyrzW7vJLdkEcDr6lN45P4wBapY+LHSIIZTn6Lqch5Xi JHcCrGJA6gnJRo1vySkEl99WKopVIcyM9V2T307JLXd5SOP+cs3ZuwYX2Vxdup5eb16z IUJay0XhANagkrLw3/8HrrklBbkN2uF4kbQf/I0R2ZCh2k1jISsP7W4zXFtwklc+PpSX QNavzd14yVPZEbwiBpy2p0P4j5wfZ9qEN8kQ/Cq835DPeWxPSPONS5kcHAevmxWebwux xFPmAO3sseS1yhKvkgp9Evfbfi9ZaXfmhbQpP8kymgxbrdvoV+rfhg1ErS1xVbf53Wi6 yfhg== 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 :message-id:subject:from:to:date:dkim-signature; bh=jkK1R3WCltMFBFxwC1GQzG1iYNhSqyqMrZkoyHqYf+U=; fh=VzDeiBL6d4DOnQldPVds1RAijdLunHDlYMMg7klqA3g=; b=HlOZqNGAHRQAGLrooSfg/ToX1NVxAoJ62mNPYrChHiKII8GkhQTBEnft58kZmn+pdw dvR3jaR42cPCYeeCNc+TAfDpEXvxUqp6uxpOHCcaLIzwxjcgVEAripYnCTmj7A+jmEUr LL64wvXVM+DfNwuGRdqQoO4992DEzCp5SFiT2mZsNof98A0QbSJbdxThw/V41s+Frjcg 8DQsFlH6DXqD2eWNlp3l3ukECtWq/SkGrJ0uu9NFtmP6iIUW0IDKG1I68DpVxX+0kqAD sRJDcK6yyNwkU6S5xJxe8/p1muh/TKbs6qEL97Dm9k9ikwWQ8kyCGFZFuUWR3sZzJxNM lgyw==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=gvcI+nU4; spf=pass (google.com: domain of bnavf@proton.me designates 79.135.106.101 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=1768349254; x=1768954054; 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:message-id:subject:from:to:date:from:to:cc:subject:date :message-id:reply-to; bh=jkK1R3WCltMFBFxwC1GQzG1iYNhSqyqMrZkoyHqYf+U=; b=Vl6gFrw5U8I0sc2gJMG2WxIwW+hyoxpy72w+quPqKSADZI87UUPSO7iynMJvoBM8n2 dJvatqP7efC0Wx7Mkr1p+a9pfwad5jIbr9e5G9K4PYTCcBnwzbhOundI0+Nro7dyUxOg /M0gd3279GlDSe3vJezOOVP51Ym7PGFpMMgTfAXCKH8NTJ3Ao1/BJkLKzoNDahKAzkN2 0Jwj/jEACcaAXTwxgKbbo8PUTy8HRxZuIafcysaV18VZReJkj6A1dXGexYJu+oBmoOgt aTeoqnisqGKlWOqvqFcpK2DO0Ms8rtBKhT/XxpPZi80TLWsd/dLww8Po7f88DwWNj//0 Nx/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768349254; x=1768954054; 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:message-id:subject:from:to:date:x-beenthere :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=jkK1R3WCltMFBFxwC1GQzG1iYNhSqyqMrZkoyHqYf+U=; b=Pcv0KgBdt2WpEs/+3xKgj74WoQWBKevcoxt+NpzlE3SOf1jFUn0+/X1aik0AnC4xLh 7yReqdCAEKpzaoHdyX8mUPMUuiXlhW/fF6VyFBKFZw1y0GGrG8ZHiEymMpoaDRVoytmY Oh99freGgqanpUbnahdob6qpJUHEhnljjaaRdmx2mmi8GiYkEdHVYecY8j88OjVIY1yy 2P+RLTKMZgkvimw1INtBLm4hh8zv4WDJE90d60FeP5UVK/flQO70Z3Hs3gNRgSky1PmH eGPDFDG9fuF9ltP0Gh4Ut1pwdawD60t66r86t3JD2+Pt5TE57EM2fKPDUcyXegt8YTF3 K7Yg== X-Forwarded-Encrypted: i=2; AJvYcCXpzUB543F8/4SqF4lfE+rSdLYLCLlEH7YSK4TyfZ1GoyX+Avq+lrnvLo64BeQWfTnMlE28bRHDia5H@gnusha.org X-Gm-Message-State: AOJu0YzIyczLOHBG1oCyeaYe2hlIzmhJcAT4Q/0P+0M7W58t7fHCPvLG S12UA0bRZzwNkdGPygseViJSKKxhn8b65VKSQO6L9byNcyUUfmC/v+tX X-Received: by 2002:a05:622a:259a:b0:501:3e36:1529 with SMTP id d75a77b69052e-5014a9cd789mr1582201cf.80.1768349253843; Tue, 13 Jan 2026 16:07:33 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+FBFoBEQttZM9HK2+z2oJ/M2M+gEbhzUaaK6w9sTSRt1A==" Received: by 2002:ac8:5e0a:0:b0:4ee:217f:a9d9 with SMTP id d75a77b69052e-4ffa70d5428ls134530881cf.0.-pod-prod-03-us; Tue, 13 Jan 2026 16:07:27 -0800 (PST) X-Received: by 2002:a05:620a:190e:b0:8b2:d648:493f with SMTP id af79cd13be357-8c5318176aemr34244085a.77.1768349247569; Tue, 13 Jan 2026 16:07:27 -0800 (PST) Received: by 2002:a05:6504:2396:b0:2d1:a602:e60f with SMTP id a1c4a302cd1d6-2d87ea71186msc7a; Mon, 12 Jan 2026 18:16:04 -0800 (PST) X-Received: by 2002:a05:6512:3d2a:b0:59b:82f1:116e with SMTP id 2adb3069b0e04-59b82f11192mr3791841e87.50.1768270562385; Mon, 12 Jan 2026 18:16:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1768270562; cv=none; d=google.com; s=arc-20240605; b=Ht8pkIiOO/Rx/rPynj4lw47ovxKqAMnXCjGe8pyZhBgY32zDuL8tgYrNNao0JsckU7 rDQfwrmwJHqnrwyBBFnpcOjtT56o9oNkBcd3Zjo73eQtzPPqhjCM0wTA6toYV6v5SGss E4OJAVcXWA9UpPMD0M1L/mnJXyVRgz1OgfeexPa+P10/+sHwgJM7Lxr/V1urjULuTq/D sBZ2tx6yWHHV5Iw9bzuNL6q5K6FT4f853CMEEnn3GPO1APAvU4nWa0C3KBmr+fQX+1QX Jfublh5bWVTCQkungJdueFhLkHfhohABRgjhygZC4M4XJEZbIJ/zaYnTc9vdXaFXxoJp yQWQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=mime-version:feedback-id:message-id:subject:from:to:date :dkim-signature; bh=3IGIiQ8G65QGakJ73RmyoKp+j666OuSJ7G0yU/zirGA=; fh=lhFSo2W/mHC0QoJ9oNg3A35n0DTltt3CQl1/0RggJlk=; b=ZPJr1pHuHtQEwP12X9SAsHwmuBkez9j/WVwKOls2VgwhgxH8G8LYvRCbr+xFVzKDpf IlhmDuKbmK09fmoPp3H49vjgD22wI0ExyoUrqqbc1Yd1ZG1WvaNVRVdhDtlzw7foTw+K 5gkRdWmz1DHvWBRn2HO31TMUDk4rWvrITZNkqBg5IcOovL1GzEwPQqiAcxrMzcnVKwFX Tcgfvp3F7q2a6IN9rBFKVhwoX0DI9C/24pRBna79MvB/jKkE9MkncN9g9obPSWMeXS/m fdXBIuuywM8GJtDm5rDY040JN+bmj7rEF0ZvKnWW6j4nQ2ne/k5/cjYhsNPny+zqYyIB bLjg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=gvcI+nU4; spf=pass (google.com: domain of bnavf@proton.me designates 79.135.106.101 as permitted sender) smtp.mailfrom=bnavf@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-106101.protonmail.ch (mail-106101.protonmail.ch. [79.135.106.101]) by gmr-mx.google.com with ESMTPS id 38308e7fff4ca-38319fff95asi2063821fa.1.2026.01.12.18.16.02 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Jan 2026 18:16:02 -0800 (PST) Received-SPF: pass (google.com: domain of bnavf@proton.me designates 79.135.106.101 as permitted sender) client-ip=79.135.106.101; Date: Tue, 13 Jan 2026 02:15:58 +0000 To: "bitcoindev@googlegroups.com" From: "'bnv' via Bitcoin Development Mailing List" Subject: =?UTF-8?Q?=5Bbitcoindev=5D_QRAMP_addition=3A_Alternative_to_legacy_f?= =?UTF-8?Q?reeze=3A_=E2=80=9Cquarantine=2Dmode=E2=80=9D_legacy_spends_via_two=2Dphase_des?= =?UTF-8?Q?tination_commitment?= Message-ID: Feedback-ID: 176017630:user:proton X-Pm-Message-ID: beca59f059d022cf49c5cd142d731b3959e11262 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1=_cixFc16L1qLQCZNrPothJqOFAPfmM98lnxjFE5yhtx4" 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=gvcI+nU4; spf=pass (google.com: domain of bnavf@proton.me designates 79.135.106.101 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=_cixFc16L1qLQCZNrPothJqOFAPfmM98lnxjFE5yhtx4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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_commitme= nt.md - Diagram: https://github.com/bnavf/bitcoinqp/blob/main/two_phase_destination_commitme= nt.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 --=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/= e2NtSyWxHaZUUHSKA4XYAr8etu7yfXwUTy6gRm456-wWa0UDz_DfoZ9W6ACIVtbMIRjL26yFRCu= 0iKr5wWfNf0xITLT7EiB-uPYqt2C1e28%3D%40proton.me. --b1=_cixFc16L1qLQCZNrPothJqOFAPfmM98lnxjFE5yhtx4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 
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/m=
ain/two_phase_destination_commitment.md
- Diagram: https://github.com/bnavf/bitcoinqp/blob/m=
ain/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/bitcoindev/e2NtSy= WxHaZUUHSKA4XYAr8etu7yfXwUTy6gRm456-wWa0UDz_DfoZ9W6ACIVtbMIRjL26yFRCu0iKr5w= WfNf0xITLT7EiB-uPYqt2C1e28%3D%40proton.me.
--b1=_cixFc16L1qLQCZNrPothJqOFAPfmM98lnxjFE5yhtx4--