From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 19 Jan 2026 18:33:29 -0800 Received: from mail-oo1-f63.google.com ([209.85.161.63]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vi1Ye-0003h6-Rj for bitcoindev@gnusha.org; Mon, 19 Jan 2026 18:33:29 -0800 Received: by mail-oo1-f63.google.com with SMTP id 006d021491bc7-661024254c8sf12605444eaf.2 for ; Mon, 19 Jan 2026 18:33:28 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1768876402; cv=pass; d=google.com; s=arc-20240605; b=TMVrOxAR8Crr6aU4BjGafso/IzQ21gMcjIuU9qYCO1PMWWmCCzSdDcuga1KhyvWGJ7 BpxaZVk870IAdirkoBSvd6HKzNOgsQihl6S56jmxjhdHiqMBnLF0UjxpYr/TX46D3Ilc SbkJHG3yH15PRXCcndOS3mkMqGHm6kUVlEsHzL10naHhqAhV6t+N1Dw5jl/eUMc9lTtX EYvOSHYmXZ/LDgLfZGyIpgGpyDA+/uvwmTWKXKe8S2wOHrdcLwjiMbPLr4GR9WQ1CJMw Dx26uKf6jEIXrupFW/A07LKOpMKXR/Yda60plqV0GVGlEh84kllIkr1BgA8YkIsBQUEu gKyA== 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:mime-version:user-agent:references :in-reply-to:date:cc:to:from:subject:message-id:sender :dkim-signature:dkim-signature; bh=pNjwVmZhpP1jUgkPxVQL9m3CLy9kA/M0zSDbumN8FzI=; fh=3M0uOGG2ik61dXl+TUhsWwD2Hpx9jdIiyufnWcVImqE=; b=TgZw5q97WuainE5VxvGSno7A1JA4GzFQlDkwl5wnIpHODeBACPtwITVV1ZhrAOtl8C b6yA+RPVf/mPdIcL0xotQ4Xkg2ZV82lr72yuoKyJ8xbW3xtEZo9qJr14bFbAYlg4cwKJ UqFaMG4Mqfg/mXOseoAS+oahcI4BzDL/oYXtDw/Pf63d1V4hpX1MKD1QWeeDZTH8He58 y6IEdl6cAGuMdAtvDGXwuJKpsDjTwidzD/65zLuM+QdG4rasb7Md4tiTClUDfzghK80G eLZCWtBmNhJjMyDxNP1er30c4gs19DHDtGIUovh5men02SFh+7Ehds0oPShxdWdgvyca RnQA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=WDauuwh+; spf=pass (google.com: domain of golinelli.giulio13@gmail.com designates 2607:f8b0:4864:20::443 as permitted sender) smtp.mailfrom=golinelli.giulio13@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1768876402; x=1769481202; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:mime-version:user-agent:references:in-reply-to :date:cc:to:from:subject:message-id:sender:from:to:cc:subject:date :message-id:reply-to; bh=pNjwVmZhpP1jUgkPxVQL9m3CLy9kA/M0zSDbumN8FzI=; b=ZPO0ymikOCA1jL2SeSeMstJqSK4JWQOyZJ2fIE/goyyC6nZ/oe9IVt7jafrA+S99fv 4c+HoL+9coppolnP/ofSVHrX6+g3Mk+m0l9g6R+e1fYt2StyEHSOSsfSjSTAvrgY4saD pwP6u2c0qaxQ+Ji/EL01roHRyRI8BaykMxN9dk3O7ZOQN1TrS65W1aMMU6fgaflOux6K IyCntDmnDTCkD3djeAuPjD1LxREopzEqjuwA5tL0jl65uX3xxlYg0DcAMhv9FSxb4qlt Z28j53b+1Rm3TtoH2ynkVkkjEyAnOki4OXQ5lJi/UDBjRXS+b/pIkt0exMTw8ULJ1hny k0MQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768876402; x=1769481202; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:mime-version:user-agent:references:in-reply-to :date:cc:to:from:subject:message-id:from:to:cc:subject:date :message-id:reply-to; bh=pNjwVmZhpP1jUgkPxVQL9m3CLy9kA/M0zSDbumN8FzI=; b=HuUuH0X4Ltib/r6GaGYOxIc5rIHpMq+hdw+j/THBxt/FKUiXHcc9EuFX+uc2q7YAp0 uGZArhWDfhV46w2s1fnk8iq+pZ44J4c5kEBsoZBJGSAYydHCFukPUV852B+CLcRTQ2K1 QKEXbfYzw/wBRnxxEdnZjzEmRLrWBY1LuSrNTb3rs5Ynl0vls+X5zekaXQgA6jC1LPq0 +a8vfaL+UmLHfqAwxu2lIfoUu+5bx/axdtOpyYAd0nO+YE5Yk0APjCjQUHru7kLJoXVh qa+BTLjT12gt8TysO/GWUGY9vE0P9WPIoiA5BIJiYsfzqM2B2d8/T6ztHZRWOWzW4ZzS MMJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768876402; x=1769481202; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:mime-version:user-agent:references:in-reply-to :date:cc:to:from:subject:message-id:x-gm-gg:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=pNjwVmZhpP1jUgkPxVQL9m3CLy9kA/M0zSDbumN8FzI=; b=YcG7PeIEJmC+xiv3IrIzB9fMMy0Me5sIYu+qDHvAVC2yV5UC0GGCprV1MTk4kGYiwO zNGK61WzyWY5kpRqrY5JvxcNDtie52Y31zIOIxZUyF4QHVET6q1nxBn2mYjyEajfHkHe wOwkthNSO4s4Pbt9TrpGr+Z9lPg7gGVeXFAT43NRXeDjIQl/lyn8yeaK75O1Of/w8cZM VM+7gQu6aIQrwCVcwpT7Nf8BedNz0bZivKHKRLLSWLhlogX+XVVoYDUlokWUK9cGhxro pDUkG2HGjnhWTrWbzk2MBA/JLPpQeveoKkoC0KrsFE+doFx+T2clQERbakYPWsIai/jL xC9Q== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCWWDdi4XenBQYVEfu+gJJbah00r+ZMmcqCO7Ny4sWJGdsuYujq8Yo2TsFnkKLKZ5kTbJap7DG9rGiLU@gnusha.org X-Gm-Message-State: AOJu0Yxb3KUMA0xgU16pziSvx1tBMiM/ZteQud1wko8DoEbLcqXTCIlj QL6kk0ua/tQOmbEcmrztovyBZS3R+WKpvJWa5jlVH+nwA2p+amW0yd7Z X-Received: by 2002:a05:6820:220a:b0:65f:a56:7788 with SMTP id 006d021491bc7-661188f38a1mr5652141eaf.26.1768876401682; Mon, 19 Jan 2026 18:33:21 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+Ev9c+90BY9d/DcYBkO7XsYUVPNdx7WltlmJ2GNXC5Zew==" Received: by 2002:a05:6870:420c:b0:3e8:4817:7a50 with SMTP id 586e51a60fabf-4042850176bls3335770fac.0.-pod-prod-05-us; Mon, 19 Jan 2026 18:33:17 -0800 (PST) X-Received: by 2002:a05:6808:1997:b0:450:c776:876f with SMTP id 5614622812f47-45c9d8f8313mr4586035b6e.54.1768876397651; Mon, 19 Jan 2026 18:33:17 -0800 (PST) Received: by 2002:a05:6808:aad:b0:455:f49f:e029 with SMTP id 5614622812f47-45c9eaefe97msb6e; Mon, 19 Jan 2026 18:29:23 -0800 (PST) X-Received: by 2002:a05:6a21:692:b0:334:87c2:445 with SMTP id adf61e73a8af0-38e00c574e5mr12565526637.36.1768876162461; Mon, 19 Jan 2026 18:29:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1768876162; cv=none; d=google.com; s=arc-20240605; b=eNp0gv0e210Nx2De0Y+s0stAPcmueXkGQrBkld7wq7pypqun1V/5zuLApAu0ppX+af 5VEUn5UeJvtQaO/jrpOcSa339JFZQGpVNHZB4IYGA4cbxHObdjW7xWtzxmS52haPvjfg 0B1m3FhhgmAEoLfeZHMn2F+XlbQ0vXYKvmsMhZu6cYmriwi2HLj6+9c+y2t2yh/qiJvU n3d6cDgYnz2M7JRIXfZWIl/Q0qTfnLdWyjnXlp3sdOTxLWeJXfTFl/CxZn47IAGKe223 wyMQ56nttwpjuCseaMJCLzSgcHo1L7nBA1+OpUZA+wGjIMx6G3MbwPt82J+SnnyoKjtE AQAA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=mime-version:user-agent:references:in-reply-to:date:cc:to:from :subject:message-id:dkim-signature; bh=B10TdN51qKO7SZfcAUITr8OmmE7ZNjA+kzFSHWOfanU=; fh=DyyyKOWVQWdPFNeQlTzuRCQ2BwTTTxjolQkCvkfkjmA=; b=Be+0etZ457gyOVZbmvWxjUPtF5NyIcH3+Aq180zkfuhWg9B3hPuXd9DGMV0Oy3L9el 4XEkMNp/rMFrCNMYHuhfbMbpYiX5gE39UPrjoqIyocqYNxQgLIbXEkqQSSoTjFc1OIuB pw93GpaiKqLLpGGTKhixfTCkBPYZnH94OXqVz9vXtDrpgAFWLDJ5EQVHIbxMuyxKuWsG +gLhYDd5qnf8+QWTUkqcVOSJCmrl8hD1arv/M3y6O4E/axlx/JoFHwDGzStVFo4Fmofs kyiV3ND6ktJ6rId1+pihGBa+ZRwDsWFhDwV4FuA9yZDibPoIdu6psS/umMUfyZL9oumE R5uQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=WDauuwh+; spf=pass (google.com: domain of golinelli.giulio13@gmail.com designates 2607:f8b0:4864:20::443 as permitted sender) smtp.mailfrom=golinelli.giulio13@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-pf1-x443.google.com (mail-pf1-x443.google.com. [2607:f8b0:4864:20::443]) by gmr-mx.google.com with ESMTPS id 41be03b00d2f7-c5edf34ca97si287846a12.7.2026.01.19.18.29.22 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 19 Jan 2026 18:29:22 -0800 (PST) Received-SPF: pass (google.com: domain of golinelli.giulio13@gmail.com designates 2607:f8b0:4864:20::443 as permitted sender) client-ip=2607:f8b0:4864:20::443; Received: by mail-pf1-x443.google.com with SMTP id d2e1a72fcca58-81e8a9d521dso2886108b3a.2 for ; Mon, 19 Jan 2026 18:29:22 -0800 (PST) X-Gm-Gg: AY/fxX79xPKxtihIHyaYneHWs4E2g/HOb09l3F+Jxb1ja5N2qGELlRRnUZAhm79AyQa Q4ipup09TLeODA9Hw2KDWslA+KAqVt/xiFenvnJghVgFjwdl3gpBDC6F66ZhWh7yz30FnNZCsTr Bm5T9jCN32mWYGHb2yrPHJfmsuxf3IsDCu80I+85+itM74LsADW3f/qbXKOcBJWW+2BnsaKsU0u +dihDCTSOUBlL5FOCQBJKUUrfMC+IG2bzPaI34iSwike5EpgHwpMtWApco7l+XK+wjYQV6w3YvT GejYEVoRs/qdERTrxvVTQuVwBgASNrVyGklhUSxwlW/RwJbsS98cgzWy9Cb53nfNSVEB2vE5vrP Er2pwz/M7P6bjKHDy8PFiPLao1G08OvBGbuZ/Y1xYuN9TdoaXgfnOmLH3T/t308u80Wf+9RicWN VYYP+WN7mXwN8Xaz3/7IiG6DTXNbY= X-Received: by 2002:a05:6a00:1408:b0:81f:7c24:724b with SMTP id d2e1a72fcca58-81fa1792592mr9888388b3a.21.1768876161862; Mon, 19 Jan 2026 18:29:21 -0800 (PST) Received: from [192.168.1.92] ([154.211.165.131]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-81fa12b5c67sm10317330b3a.69.2026.01.19.18.29.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Jan 2026 18:29:21 -0800 (PST) Message-ID: 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?= From: Giulio Golinelli To: bnv Cc: Bitcoin Development Mailing List Date: Tue, 20 Jan 2026 10:29:19 +0800 In-Reply-To: <2995yQfEoeQ7ZsvOBY7r5lnmL7VaqnD73w2DNYu61z8M9m5X9Q7KfkE2sWQSTIcyaUI7TPin36CIsHH9pyJn5nY95yjEg67774_vvIvX1go=@proton.me> References: <28f8d816-cc97-4913-8912-0aa955d3322cn@googlegroups.com> <2995yQfEoeQ7ZsvOBY7r5lnmL7VaqnD73w2DNYu61z8M9m5X9Q7KfkE2sWQSTIcyaUI7TPin36CIsHH9pyJn5nY95yjEg67774_vvIvX1go=@proton.me> Content-Type: multipart/alternative; boundary="=-CnQhdsltSyWJ7woQxUlK" User-Agent: Evolution 3.52.3-0ubuntu1.1 MIME-Version: 1.0 X-Original-Sender: golinelli.giulio13@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=WDauuwh+; spf=pass (google.com: domain of golinelli.giulio13@gmail.com designates 2607:f8b0:4864:20::443 as permitted sender) smtp.mailfrom=golinelli.giulio13@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.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 (/) --=-CnQhdsltSyWJ7woQxUlK Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sure, sorry if I made those remarks but I just wanted us sure on the same page. I agree with you that suddenly freeze coins of people is not good. Ideally speaking the best would be an automatic conversion of all classic addresses to post-quantum ones at Q-day - without the need of any action from owners. This could be achieved via forced transactions of all unspent funds to the new addresses. Of course this comes with practical limitations (eg private key sharing..). Anyways I am open to explore all possible solutions and if you need help formalizing your solution you can count on me. We can start with an overleaf project. Giulio On Mon, 2026-01-19 at 23:55 +0000, bnv wrote: > Hi Gulio, >=20 > Thank you for the feedback! >=20 > I agree with all what you said but the intention of the proposal not > to secure the address from where we are sending funds but to avoid > the race between legitimate sender and a quantum attacker. >=20 > Of course, the transaction MUST shift ALL coins from old address to a > new one and the address MUST not be never used again for receiving > any coins. That is very old recommendation which probably was > promoted even by Satoshi itself! >=20 > 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. >=20 > Thank you! > Bnav >=20 > =C2=A0 >=20 > =20 > Sent with Proton Mail [1] secure email.=20 >=20 > On Monday, January 19th, 2026 at 2:57 AM, Giulio Golinelli > wrote: >=20 > >=20 > > 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 capable quantum attacker would likely not need to > > race a live transaction during mining 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 technological standpoint, this kind of offline key-recovery > > attack against exposed public keys is likely to become feasible > > earlier than a real-time transaction hijack scenario. That said, > > assuming a quantum-resistant commitment scheme and the necessary > > protocol mechanics (to be defined and evaluated), I can see how the > > construction would work 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, > > >=20 > > > I=E2=80=99d like feedback on a concept that I want to frame explicitl= y as > an *alternative* to =E2=80=9Cfreeze/sunset legacy signatures=E2=80=9D in = QRAMP > (Quantum=E2=80=91Resistant Address Migration Protocol) or similar migrati= on > planning. > > >=20 > > > Instead of making legacy ECDSA spends invalid after a cutoff, we > could place 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 prevent= s > destination-substitution even if the legacy private key can be > derived quickly after pubkey reveal. > > >=20 > > > High-level: > > > 1) **Commit phase (on-chain):** publish a commitment that binds > the eventual 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 > presents (a) proof that a matching commitment was mined and is > mature, and (b) the spend=E2=80=99s outputs match the committed template. > > >=20 > > > Key feasibility constraint: this must be **consensus-enforced > without historical 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). > > >=20 > > > 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. > > >=20 > > > Short design note + diagram (please replace with your links): > > > - Markdown: > https://github.com/bnavf/bitcoinqp/blob/main/two_phase_destination_commit= ment.md > > > - Diagram: > https://github.com/bnavf/bitcoinqp/blob/main/two_phase_destination_commit= ment.svg > > >=20 > > > Questions for the list: > > > 1) Is there an existing proposal that already captures this > =E2=80=9Cquarantine-mode legacy spends=E2=80=9D framing? > > > 2) What=E2=80=99s the most reasonable way to do commitment > inclusion/maturity proofs without creating an indexer-dependent > consensus rule? > > > 3) Is binding the *full output set* sufficient to rule out > practical destination-substitution variants? > > >=20 > > > Thanks for any critique or pointers. > > > Best, > > > Bnav > > >=20 [1] Proton Mail https://proton.me/mail/home --=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/= a0e14a21095db7b3d8efa031c93edd3faa62998f.camel%40gmail.com. --=-CnQhdsltSyWJ7woQxUlK Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sure,= sorry if I made those remarks but I just wanted us sure on the same page.<= /font>

I agree with you that s= uddenly freeze coins of people is not good. Ideally speaking the bes= t would be an automatic conversion of all classic addresses to post-quantum= ones at Q-day - without the need of any action from owners. This could be = achieved via forced transactions of all unspent funds to the new addresses.= Of course this comes with practical limitations (eg private key sharing..)= .

<= /div>
Anyways I am open to = explore all possible solutions and if you need help formalizing your soluti= on you can count on me. We can start with an overleaf project.
=

Giulio

On Mon, 2026-01-19 at 23:55 +0000, bnv wrote:
Hi Gulio,

Thank you for the feedback!

I agree with all what you s= aid but the intention of the proposal not to secure the address from where = we are sending funds but to avoid the race between legitimate sender and a = quantum attacker.

Of course, the transaction MUST shift ALL coins from old address= to a new one and the address MUST not be never used again for receiving an= y coins. That is very old recommendation which probably was promoted even b= y Satoshi itself!

Why I have written that QRAMP addition: I am not happy with QRAM= P 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.
=
T= hank you!
Bnav


Sent with Proton Mail secure email.

On Monday, January 19th, 2026 at 2:57 AM, Giulio Golinel= li <golinelli.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 a= ddress the destination-substitution hijack problem, I think a much= larger issue still remains: unspent UTXOs.
In your pro= tocol, Phase 2 (the transaction phase) still requires the spender to produc= e a classical ECDSA signature. This inevitably reveals the public key and p= uts the corresponding private key at risk.
A sufficiently capable quantu= m attacker would likely not need to race a live transaction during mining o= r while it sits in the mempool. Instead, they could recover private keys fr= om already-revealed public keys offline and then sweep all remaining unspen= t UTXOs associated with those keys at his leisure.
From a technological = standpoint, this kind of offline key-recovery attack against exposed public= keys is likely to become feasible earlier than a real-time transaction hij= ack scenario. That said, assuming a quantum-resistant commitment scheme and= the necessary protocol mechanics (to be defined and evaluated), I can see = how the construction would work for its intended, narrower purpose.

L= et me know if you agree/disagree,
Giulio

<= div dir=3D"auto" class=3D"gmail_attr">Il giorno mercoled=C3=AC 14 gennaio 2= 026 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 &= 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/bitcoi= ndev/a0e14a21095db7b3d8efa031c93edd3faa62998f.camel%40gmail.com.
--=-CnQhdsltSyWJ7woQxUlK--