Post-Quantum Proof of Life: How to Prove You Control a Bitcoin Key Without Moving a Satoshi

A construction for proving continued control of any Bitcoin private key — including the P2PK outputs attributed to Satoshi Nakamoto — using a zero-knowledge proof of discrete-log knowledge bound to a three-family post-quantum attestation. No coins move. No private key is revealed. No fork is required. The proof is permanently anchored to the Bitcoin blockchain it's proving ownership on.

The Problem: 1.1 Million BTC with Exposed Public Keys

The earliest Bitcoin transactions used Pay-to-Public-Key (P2PK) outputs. Unlike the Pay-to-Public-Key-Hash (P2PKH) format that later became standard, P2PK outputs expose the full public key directly on the blockchain. This includes approximately 1.1 million BTC attributed to the Satoshi-era mining period — outputs whose public keys have been sitting on the Bitcoin blockchain, in the clear, since 2009.

Today, those exposed public keys are protected by the computational difficulty of the Elliptic Curve Discrete Logarithm Problem (ECDLP) on secp256k1. No classical computer can derive the private key from the public key in any feasible amount of time. This changes with quantum computers. Shor's algorithm solves ECDLP in polynomial time on a sufficiently large quantum computer, which means every P2PK output with an exposed public key becomes spendable by an adversary who builds or acquires a cryptographically-relevant quantum computer.

The timeline is debated. Estimates range from 2030 to 2040. But the question isn't when quantum computers arrive — it's what happens to 1.1 million BTC when they do.

The Current Proposals and Why They All Require Forks

The Bitcoin community has proposed several approaches to protecting P2PK outputs:

1. UTXO Freeze

Freeze all P2PK outputs and require owners to prove knowledge of the private key via a new post-quantum transaction type before spending. This requires a consensus change — a soft or hard fork — to introduce the freeze mechanism and the new transaction format. It also creates a governance crisis: who decides which UTXOs to freeze, for how long, and what happens to UTXOs whose owners cannot prove knowledge in time?

2. Migration Transaction

Require P2PK holders to move their coins to a P2PKH or Taproot address before a deadline. The act of spending a P2PK output reveals the public key in the spending transaction — but for P2PK outputs, the public key is already revealed. The real problem is that the spending transaction itself uses ECDSA, which a quantum computer can forge. A migration transaction today is quantum-safe only if it uses a post-quantum signature — which Bitcoin doesn't currently support in consensus.

3. Script-Layer Post-Quantum Signatures (QSB, BINOHASH)

Excellent recent work by Heilman, Linus, and Levy has demonstrated that post-quantum signatures can be verified inside Bitcoin script without a soft fork, using existing opcodes. These constructions protect the UTXO's spendability against script-layer signature forgery by a quantum adversary. They are works of cryptographic engineering that we deeply respect and consider complementary to our work.

However, they require moving the coins. The holder must create a new transaction that locks the UTXO under a QSB or BINOHASH script. For the Satoshi outputs, this means Satoshi — or whoever controls those keys — must actively transact. The mere act of transacting with 1.1 million BTC would be the most significant event in Bitcoin's history, with unpredictable market, legal, and social consequences.

The Construction: Zero-Knowledge Proof of Life

We propose a construction that uses H33-74 — the 74-byte post-quantum attestation primitive — to solve this problem. The construction has five steps.

"I know sk such that:
  (a) pk = sk · G  on secp256k1
  (b) binding = SHA3-256(pk || pk_pq || nonce)
  (c) nonce is fresh (not reused from any prior proof)"

content = SHA3-256(π || pk_classical || pk_pq)
H33-74 = Mint(PostQuantumMigration, content, timestamp)
Sign(H33-74, sk_mldsa, sk_falcon, sk_slhdsa) → (R, σ)

What the Verifier Gets

Any third party who wants to verify the proof of life needs:

1. The H33-74 attestation (74 bytes, retrievable from the primitive store)
2. The STARK proof π (retrievable from the ephemeral signature store)
3. The classical public key pk (already on-chain in the P2PK output)
4. The post-quantum public key pk_pq (embedded in the attestation payload)
5. The Bitcoin anchor transaction (on-chain, verifiable by any full node)

The verifier checks:

1. The STARK proof verifies — the prover knows the discrete log of pk
2. The binding commitment matches — the proof is bound to the specific pk_pq
3. The H33-74 attestation verifies under all three PQ families
4. The Bitcoin anchor matches the signing message

If all four checks pass, the verifier has cryptographic proof that:

What This Proves and What It Doesn't

We are precise about this distinction because precision matters in cryptography. The construction proves key control, not identity. It proves binding, not intent. It proves the proof was created at a specific time, not that the prover is alive at a later time. Each proof is a snapshot of key control at a specific moment.

Why a Simple Signature Doesn't Work

The obvious approach — "just sign a message with Satoshi's key" — fails in two ways.

The zero-knowledge approach solves both problems. The STARK proof reveals nothing about sk — not to a classical adversary, not to a quantum adversary, not even to a verifier who checks the proof a million times. And the binding to the PQ public key is inside the proof statement itself, so forging the binding requires forging the STARK proof, which requires breaking SHA3-256 collision resistance.

The Hard Part: secp256k1 Scalar Multiplication Inside a STARK

We will be honest about what's hard.

The STARK proof must verify the statement pk = sk · G on the secp256k1 elliptic curve. This means expressing the elliptic curve group operation — point addition and scalar multiplication over a 256-bit prime field — as an algebraic constraint system that the STARK prover can evaluate.

The challenge is that secp256k1's base field (a 256-bit prime) is not the native field of the STARK proof system. The STARK operates over its own field (typically a 64-bit or 128-bit Goldilocks or BN254 field). Performing 256-bit field arithmetic inside the STARK requires non-native field emulation — representing each 256-bit value as multiple limbs in the STARK's native field and proving the correctness of every limb operation.

This is expensive. StarkWare has demonstrated ECDSA signature verification inside STARKs — their work proves it's feasible. But the proof generation time for a single secp256k1 scalar multiplication is measured in seconds, not milliseconds, on current hardware.

For a proof-of-life construction, this is acceptable. You are not generating proofs at 1.7 million per second. You are generating one proof, once, to prove you control a specific key. If it takes 30 seconds to generate the proof, that's fine. The proof itself is verified in milliseconds.

Why H33-74 Is the Right Anchor

The STARK proof alone proves key knowledge. But it doesn't provide:

• Post-quantum signing. The proof is post-quantum secure (STARK soundness relies on hash collision resistance), but it isn't signed under post-quantum keys. H33-74 adds three-family PQ signatures over the proof commitment.
• Permanent timestamping. The proof exists in a moment. H33-74 anchors it to Bitcoin, giving it a permanent, immutable, independently verifiable timestamp.
• Compact representation. The STARK proof itself may be kilobytes. H33-74 compresses the commitment to 74 bytes persistent (32 on-chain + 42 off-chain). The full proof is retrievable on demand.
• Computation type separation. The PostQuantumMigration (0x12) computation type in H33-74's registry distinguishes this proof from every other type of attestation. A biometric attestation can't be replayed as a proof-of-life. Domain separation is cryptographic, not policy.

Applications Beyond Satoshi

The construction isn't limited to Satoshi's coins. Any holder of any P2PK output can use it. More broadly, any holder of any Bitcoin UTXO whose public key is known (whether from a P2PK output, a spent P2PKH transaction, or a Taproot output) can generate a proof of life that binds their classical key to a post-quantum identity.

Estate planning

A Bitcoin holder wants to prove to their estate lawyer that they control specific UTXOs without revealing the private key and without creating a spending transaction. The proof-of-life construction generates a cryptographic record that the holder controlled the key at a specific time, bound to a PQ key set that the estate can use for future verification.

Proof of reserves

An exchange or custodian wants to prove control of customer deposits without moving them. The proof-of-life construction proves key control for each UTXO, and the H33-74 Merkle aggregation batches all proofs under a single 74-byte root attestation.

Key migration signaling

A P2PK holder wants to signal to the Bitcoin network: "I'm still here, I control this key, and here's my post-quantum public key for when you're ready to accept PQ signatures in consensus." The proof-of-life construction creates that signal without requiring any consensus change to process it. The signal lives on-chain as an OP_RETURN or Taproot tweak. When Bitcoin eventually adds PQ signature support in consensus, the migration path is already cryptographically established.

Dead man's switch (inverted proof of life)

A holder publishes a proof of life at regular intervals — say, once per year. If the interval passes without a new proof, a pre-authorized PQ key set (held by an estate executor, a multisig quorum, or a timelock contract) becomes the presumptive controller. The absence of a proof of life is itself a signal.

What Needs to Be Built

The construction is architecturally sound. Here is what needs to be built to make it production-ready:

1. STARK circuit for secp256k1 discrete log proof of knowledge. The constraint system for pk = sk · G over the secp256k1 curve, with non-native field arithmetic, in H33's STARK proof system. This is the hardest engineering task. Estimated: 6-12 weeks for a single-developer cryptographic engineer.
2. Binding protocol. The formal specification of how the STARK proof, the classical public key, and the PQ public key are committed into the H33-74 content digest. This is a design task, not an engineering task. Estimated: 1 week.
3. New computation type. Register PostQuantumMigration (0x12) in the H33-74 computation type registry. This is a one-line code change.
4. Verification logic. Extend the h33-74-verifier to handle the new computation type, including STARK proof verification and the secp256k1 binding check. Estimated: 2-3 weeks.
5. Security analysis. Formal analysis of the binding protocol's security properties, particularly the interaction between the STARK proof's zero-knowledge property and the H33-74 attestation's three-family signature. Estimated: 4-6 weeks for a peer review cycle.

Total estimated timeline: 3-4 months from start to audited production deployment.

What This Does for Bitcoin

If this construction is built and deployed, every P2PK holder on the Bitcoin network gains the ability to:

• Prove they control their key without moving coins
• Bind their classical key to a post-quantum identity
• Anchor that binding permanently to the Bitcoin blockchain
• Do all of this without any consensus change, any new opcode, or any modification to any full node

For the 1.1 million BTC in Satoshi-era P2PK outputs, this means: if the key holder is still alive and still controls the keys, they can prove it — cryptographically, permanently, post-quantum securely — without triggering the market event that moving those coins would cause.

For the broader Bitcoin community, this means: the post-quantum migration path for existing UTXOs doesn't have to start with a fork. It can start with a proof. The proof establishes the PQ binding. The fork, if and when it comes, can honor bindings that were cryptographically established before the fork existed.

The Cryptographic Properties

We state the security properties of the construction explicitly, because informal security claims in applied cryptography are worse than no claims at all.

Zero-knowledge

The STARK proof reveals no information about sk beyond the truth of the statement pk = sk · G. This holds against classical and quantum adversaries. The proof transcript is simulatable — a simulator with access to only the public key can produce transcripts indistinguishable from real proofs. This is the standard zero-knowledge property of interactive proofs, instantiated non-interactively via the Fiat-Shamir heuristic applied to the STARK protocol.

Soundness

A prover who does not know sk cannot produce a valid STARK proof except with negligible probability. The soundness of the STARK relies on the collision resistance of SHA3-256, which Grover's algorithm reduces from 2¹²⁸ to 2^85.3 collision resistance — still well above any practical attack threshold. No algebraic shortcut exists because the STARK's soundness is hash-based, not group-based.

Binding

The proof commits to a specific post-quantum public key pk_pq inside the STARK statement. Changing the PQ key after proof generation requires producing a new valid STARK proof — which requires knowledge of sk. An adversary who intercepts the proof cannot rebind it to a different PQ key without breaking the STARK's soundness.

Post-quantum attestation

The H33-74 attestation is signed under ML-DSA-65 (Module-LWE), FALCON-512 (NTRU), and SLH-DSA-SHA2-128f (hash-based). Forging the attestation requires simultaneously breaking all three mathematical families. The STARK proof provides post-quantum security for the key knowledge claim. The H33-74 provides post-quantum security for the attestation claim. Together they constitute a post-quantum secure proof-of-life.

Non-transferability

The proof demonstrates that the prover knew sk at the time the proof was generated. It does not prove that the prover still knows sk at any later time. If the prover transfers sk to another party after generating the proof, the proof remains valid but the new holder could generate their own proof. This is a feature, not a bug — it reflects the reality that key control is a point-in-time property, not a permanent one. Repeated proofs at intervals (proof-of-life heartbeats) establish ongoing control.

Composability

The H33-74 primitive-referencing-primitive construction (described in the white paper, Section 10.5) allows a proof-of-life attestation to reference previous attestations. A holder who published a proof-of-life in 2026 can publish a new one in 2027 that references the 2026 attestation, creating a verifiable chain of continued control. This chain can be Merkle-aggregated under a single 74-byte root for compact verification.

Open Questions

We publish this as a proposal, not a finished product. The following questions are genuinely open and we invite the Bitcoin and post-quantum cryptography communities to weigh in:

1. Is the STARK proving cost for secp256k1 scalar multiplication acceptable? Current estimates suggest 10-60 seconds for proof generation on commodity hardware. Is this acceptable for a one-time proof of life? We believe it is, but the community should decide.
2. Should the binding be renewable? If a holder proves life in 2026, should they be able to update the binding to a new PQ key set in 2028 without a new STARK proof? The H33-74 construction supports this via the algorithm flags byte, but the security implications of key rotation in a binding protocol need analysis.
3. How should the Bitcoin network treat proof-of-life attestations? They're standard OP_RETURN or Taproot outputs today. If Bitcoin adds PQ signature support in consensus, should previously-anchored bindings receive any special treatment?
4. What is the relationship between proof of life and UTXO freezing proposals? A holder who has published a proof of life arguably has a stronger claim to a frozen UTXO than a holder who hasn't. Should governance proposals consider proof-of-life attestations as evidence of continued control?

We don't have answers to all of these questions. We have a construction that makes them answerable. The construction is technically feasible, the components exist (STARK provers, H33-74, Bitcoin anchoring), and the missing piece — the secp256k1 STARK circuit — is engineering, not research.

The H33-74 white paper provides the full specification of the attestation primitive. The construction described here would become Section 10.9 or an addendum if the community considers it worth pursuing.

We welcome review, criticism, and collaboration.

Eric Beans, CEO, H33.ai, Inc. — support@h33.ai