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.

[healthforcure]

https://healthforcure.com/health-and-treatment
The Health and Treatment section focuses on contemporary methods of diagnosing, treating, and preventing a wide range of conditions, from widespread illnesses to rare disorders. Medical concepts and terminology are presented in clear, straightforward language, while preserving scientific precision, so readers can better understand health conditions and available treatment options without confusion.