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