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.

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