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