Post-quantum migration: two-phase destination commitment

[bnavf]

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 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:
- 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,
Bnavf

[BattleDog]

It's a clever mitigation, but you're buying that safety with a new opcode and a bunch of consensus complexity. If you can make the inclusion check minimal and non-footgunny, it's worth discussing seriously.

If it turns into "every spend carries a backpack full of proofs", the mailing list will eat it alive.

[Donneski]

The incentive angle is what actually stands out to me. Phase 1 works socially but Phase 2 depends on long-term willingness to carry commitment proofs which Bitcoin is usually hostile to unless the benefit is immediate.

That said, this might make more sense as a legacy-key hygiene tool first with post-quantum safety as a secondary win.

[bnavf]

Thanks for the feedback!
Yes, you’re absolutely right about the “backpack,” but I want to emphasize that these two-phase transactions are not proposed as the primary method—only as a mechanism for extracting funds from very old addresses that were not moved to new post-quantum addresses during the migration phase.

Right now, some migration schemes being discussed would effectively consign bitcoins on old addresses to oblivion: “if you didn’t move during the migration window, you lose everything.”
The community won’t accept that approach, and it risks a chain split.