Proof of Concept

Post-Quantum Security
for Bitcoin Taproot

A gentle soft-fork upgrade path that brings hardened key spending and SPHINCS+ post-quantum signatures to Bitcoin Taproot.

Learn How It Works View on GitHub →

Get Started in 5 Commands

Set up a quantum-insured wallet in five commands.

bitcoin-cli (regtest)
$ bitcoin-cli createwallet "quantum"
$ bitcoin-cli createsphincskey
$ bitcoin-cli getquantumaddress
$ bitcoin-cli exportqpub
$ bitcoin-cli listsphincskeys

Quantum Insurance for Your Bitcoin

Key-path for everyday spending. Hybrid tapleaf for quantum emergencies.

01

Create Taproot Outputs Today

Add a hidden hybrid tapleaf to your Taproot outputs. OP_CHECKSIG stays enforced before activation, so the construction is safe to deploy now.

Zero on-chain overhead. Your outputs look like ordinary Taproot until the hybrid path is revealed.

02

Spend Normally with Key-Path

Before activation, non-upgraded nodes follow the standard Taproot path and the hybrid leaf remains hidden.

After activation, key-path adds the internal-key annex and still stays leaner than a script-path spend.

! Trigger Event !
Quantum Threat Emerges
03

Activate Soft Fork

Once a credible quantum threat appears, the network activates the companion soft fork to harden key-path spending and enable SPHINCS+ validation.

BIP 368 and BIP 369 must activate together.

04

Redeem via Hybrid Tapleaf

After activation, upgraded nodes can redeem through the hidden hybrid leaf using both Schnorr and SPHINCS+ signatures.

The SPHINCS+ signature lives in the annex and replaces elliptic-curve trust with hash-based security.

Deploy Today, Activate Later

Forward-compatible with current Bitcoin consensus. Create quantum-insured outputs on mainnet today — no soft fork required until a quantum threat emerges.

Forward Compatible

Valid under today's consensus rules. The hybrid construction uses only existing opcodes — no soft fork needed to start protecting your funds.

Invisible On-Chain

Quantum-insured outputs are standard bech32m Taproot. The hybrid leaf is a hash in the script tree — never revealed during normal spending.

Instant Protection

When the soft fork activates, existing outputs are already covered. No migration, no sweeping — SPHINCS+ enforcement kicks in immediately.

Hybrid Script in Action

A single Tapscript enforces both Schnorr and SPHINCS+ verification. Non-upgraded nodes still validate the Schnorr check — security is never weakened during activation.

Tapscript template
1 <sphincs_pk> OP_CHECKSPHINCSVERIFY OP_DROP
2 <schnorr_pk> OP_CHECKSIG
Non-upgraded nodes

OP_NOP4 does nothing. SPHINCS+ pubkey is pushed, NOP4 skipped, OP_DROP removes it. OP_CHECKSIG validates the Schnorr signature. Funds always protected.

Upgraded nodes

Both signatures verified. OP_CHECKSPHINCSVERIFY consumes the SPHINCS+ signature from the annex. OP_CHECKSIG validates Schnorr. An attacker must break both.

Four Companion BIPs

Two consensus-layer BIPs for post-quantum protection, plus two wallet-layer BIPs for key management and signing workflows. BIP 369 requires BIP 368 co-activation.

Consensus Change

BIP 368: Taproot Hardening

  • Requires internal key disclosure in the annex (type byte 0x02)
  • Bans NUMS points to prevent quantum key-path forgery
  • Disables bare-key spending post-activation
  • Co-activation required — BIP 369 cannot activate without BIP 368
  • Mempool policy: script-path spends can't be replaced by key-path
Consensus Change

BIP 369: SPHINCS Signatures

  • New Tapscript opcode (0xB3) for SPHINCS+ signature verification
  • Signatures carried in Taproot annex (type byte 0x04, 4,080 bytes each)
  • Uses NIST FIPS 205 SLH-DSA with custom Bitcoin parameter set
  • Redefines OP_NOP4 — old nodes see a no-op, new nodes enforce verification
  • Hybrid script always requires Schnorr — safe pre-activation

BIP 395: Quantum-Insured Keys

  • Extends BIP 32 with SPHINCS+ key material (qpub 110 bytes, qprv 142 bytes)
  • Watch-only wallets derive all QI addresses from a single qpub
  • SPHINCS+ key derived from master seed — mnemonic-only backup
  • Purpose index 395' with per-account key isolation
  • Base58 prefix: Q1... (mainnet), T4... (testnet)

BIP 377: PSBT Extensions

  • New PSBT fields for SPHINCS+ pubkeys, signatures, and annex data
  • Two-round signing: SPHINCS+ first, build annex, then Schnorr
  • Fields are transport-only — consensus validates the final transaction
  • Annex types 0x02 (key-path) and 0x04 (script-path) mutually exclusive
  • Compatible with existing BIP 174/371 PSBT workflows

Benchmarks

SPHINCS+ signing and verification compared to the Schnorr baseline.

Schnorr Sign
~27 µs baseline

Standard Taproot key-path signing. The performance target for normal wallet operations.

SPHINCS+ Sign
~918 ms 33,600×

Offline wallet operation. Slower, but only used for emergency script-path spending.

Schnorr Verify
~27 µs baseline

Standard Taproot signature verification. The consensus baseline for validation cost.

SPHINCS+ Verify
~1,756 µs 64×

On-chain consensus validation. The cost that matters for block verification.

Schnorr Signature
64 bytes 16 vB

Key-path witness: just a single Schnorr signature. The most efficient Taproot spend.

SPHINCS+ Signature
4,080 bytes 1,020 vB

Carried in the Taproot annex. Script-path witness also includes the Schnorr sig, script, and control block.

Test Coverage

Every consensus rule, wallet operation, and signing path is covered by automated tests across three layers.

56
Consensus tests
BIP 368 + 369
75
Wallet unit tests
key, qextkey, descriptor, DB
37
Functional tests
RPCs, PSBT, activation

168 total tests passing

Design Decisions

Key architectural choices behind the soft-fork design.

Why OP_NOP4 instead of OP_SUCCESSx? +
OP_SUCCESSx triggers an unconditional script success in a pre-execution scan — Schnorr checks would never run on non-upgraded nodes. OP_NOP4 redefinition (the CLTV/CSV precedent) lets existing Schnorr checks execute normally, maintaining security during activation.
Why is sha_annex omitted from the SPHINCS+ sighash? +
SPHINCS+ signatures live in the annex. Including sha_annex in the sighash creates a circular dependency (the signature would hash itself). The annex bit in spend_type is still set (0x03) for domain separation, and Schnorr's sighash still includes sha_annex, locking annex contents.
Why standard FIPS 205 over the smaller experimental variant? +
The standard SLH-DSA algorithms (WOTS+, FORS) are fully NIST-reviewed at the same security level. An experimental variant called W+C_P+FP saves ~670 bytes per signature but has not undergone the same review. It is documented as a drop-in future optimization in the BIP addendum.
Why disable bare-key spending? +
Bare-key outputs can't verify the internal key against the tweak — they would completely undermine the NUMS ban. BIP 341 already recommends against bare keys, wallets don't create them, and BIP 9 activation gives time to migrate.