From: "'bnv' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
To: Giulio Golinelli <golinelli.giulio13@gmail.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: QRAMP addition: Alternative to legacy freeze: “quarantine-mode” legacy spends via two-phase destination commitment
Date: Mon, 19 Jan 2026 23:55:53 +0000 [thread overview]
Message-ID: <2995yQfEoeQ7ZsvOBY7r5lnmL7VaqnD73w2DNYu61z8M9m5X9Q7KfkE2sWQSTIcyaUI7TPin36CIsHH9pyJn5nY95yjEg67774_vvIvX1go=@proton.me> (raw)
In-Reply-To: <28f8d816-cc97-4913-8912-0aa955d3322cn@googlegroups.com>
[-- Attachment #1: Type: text/plain, Size: 5293 bytes --]
Hi Gulio,
Thank you for the feedback!
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.
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!
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 <golinelli.giulio13@gmail.com> wrote:
> Hi Bnav, thank you for sharing your idea.
>
> I’ve 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ì 14 gennaio 2026 alle 08:07:34 UTC+8 bnv ha scritto:
>
>> Hi Everyone,
>>
>> I’d like feedback on a concept that I want to frame explicitly as an *alternative* to “freeze/sunset legacy signatures” in QRAMP (Quantum‑Resistant Address Migration Protocol) or similar migration planning.
>>
>> 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→spend** flow that prevents destination-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 eventual spend outputs (preferably the full output set: amounts + scriptPubKeys) and becomes valid only after ≥K 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’s outputs match the committed template.
>>
>> 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 + ≥K 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 “I can’t safely fee-pay Phase 1” problem.
>>
>> Short design note + diagram (please replace with your links):
>> - Markdown:
>> https://github.com/bnavf/bitcoinqp/blob/main/two_phase_destination_commitment.md
>> - Diagram:
>> https://github.com/bnavf/bitcoinqp/blob/main/two_phase_destination_commitment.svg
>> Questions for the list:
>> 1) Is there an existing proposal that already captures this “quarantine-mode legacy spends” framing?
>> 2) What’s 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?
>>
>> 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/bitcoindev/28f8d816-cc97-4913-8912-0aa955d3322cn%40googlegroups.com.
--
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/2995yQfEoeQ7ZsvOBY7r5lnmL7VaqnD73w2DNYu61z8M9m5X9Q7KfkE2sWQSTIcyaUI7TPin36CIsHH9pyJn5nY95yjEg67774_vvIvX1go%3D%40proton.me.
[-- Attachment #2: Type: text/html, Size: 8668 bytes --]
next prev parent reply other threads:[~2026-01-20 2:33 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-13 2:15 [bitcoindev] " 'bnv' via Bitcoin Development Mailing List
2026-01-18 13:44 ` [bitcoindev] " Giulio Golinelli
2026-01-19 23:55 ` 'bnv' via Bitcoin Development Mailing List [this message]
2026-01-20 2:29 ` Giulio Golinelli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='2995yQfEoeQ7ZsvOBY7r5lnmL7VaqnD73w2DNYu61z8M9m5X9Q7KfkE2sWQSTIcyaUI7TPin36CIsHH9pyJn5nY95yjEg67774_vvIvX1go=@proton.me' \
--to=bitcoindev@googlegroups.com \
--cc=bnavf@proton.me \
--cc=golinelli.giulio13@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox