Post-Quantum Bitcoin Threads
May 7 - June 3: the conversation fragments into concrete proposals
WHAT MOVED
Six distinct threads ran in parallel rather than circling one proposal. Each tackles a different layer of the same problem - what happens if quantum (or any new) attack on Bitcoin keys becomes feasible:
- QCAP - an on-chain alarm that trips before main-chain keys are at risk.
- Lattice signatures - candidate replacement signature scheme family (Dilithium, Falcon).
- WOTS+Lamport - chained one-time signature attempt, since pivoted.
- P2WOTS - a Bitcoin-native one-time signature output type, with a live signet demo.
- SPHINCS+ HD wallet - hash-based fallback path baked into BIP-32/44 derivation.
- ECDSA.fail - the measurement layer: how close to feasible is the attack today?
QCAP
qatkk - cross-curve quantum canary
LATTICES
nkaretnikov / ion_minus - NIST selected algorithms
WOTS+LAMPORT
opus-lux - chained one-time keys, then pivoted
P2WOTS
opus-lux - txid-anchored UTXOs, live signet
SPHINCS+
conduition - hash-based wallet fallback
ECDSA.FAIL
Eigen Labs - quantum circuit-cost leaderboard
QCAP - Quantum Canary Alert
qatkk, Delving Bitcoin, 2026-05-11
THE IDEA
A "canary in a coal mine" address inside Bitcoin itself. Every Bitcoin key rests on a math problem (ECDLP) defined on the 256-bit secp256k1 curve. QCAP picks a secret scalar small enough to also live on the weaker NIST secp192r1 (192-bit) curve, then publishes both derived public keys - one on each curve - and funds the Bitcoin one. Smaller curve = easier to attack. If anyone ever breaks the discrete log on the 192-bit curve they recover the same scalar, sweep the canary funds, and the world sees the spend on-chain as a real-money alarm that ECDLP attacks now exist, well before the main chain is in danger.
MULTI-PARTY SETUP
To make sure no founder secretly holds the key, n people each generate a piece and only the sum is funded. An
OP_RETURN inside the funding transaction points to IPFS-hosted proofs that every step was honest, so anyone can audit the construction. A working proof-of-concept already sits on testnet (tx ebfcee0b...4a628c).OBJECTIONS
- AdamISZ: the multi-party step should use a FROST-style distributed key generation - simple addition lets a participant subtract their own share to learn the others. And it is genuinely unknown whether a small secret on a big curve is as easy to break as a small curve.
- garlonicon: prefer purpose-designed smaller curves, and stack 128 / 192 / 255-bit canaries so the network gets a progressive warning rather than one all-or-nothing trip.
Lattice-based Signatures
nkaretnikov, Delving Bitcoin, 2026-05-21
THE PITCH
Most of today's leading post-quantum signatures are built on lattices - high-dimensional grids whose hard problems do not collapse under any known quantum algorithm. Three of NIST's first four standardised PQC algorithms are lattice-based (ML-KEM, ML-DSA, FN-DSA); among the first selected signatures specifically, two of three are lattice (ML-DSA / Dilithium and FN-DSA / Falcon) and one is hash-based (SLH-DSA / SPHINCS+). They also come with an unusual security property: a mathematical proof that the easiest version of the problem is essentially as hard as the hardest version - so an attacker can't get lucky on weak inputs. RSA and ECDSA don't have an equivalent guarantee.
WHAT'S DEBATED
Practical wallet integration, whether multi-party / threshold signing works as cleanly as it does on Schnorr, and the headline catch: lattice signatures are much bigger than Schnorr's 64 bytes. The thread is a survey, not a BIP draft.
REPLIES NOTE
ion_minus (2026-05-28): the reductions are attractive but "devil is in the details" on implementation - and the on-chain cost of bigger signatures and pubkeys, once they live in every input's witness, is the load-bearing constraint.
Winternitz + Lamport Auth Chains
opus-lux, Delving Bitcoin, 2026-05-22 (later pivoted)
THE STARTING POINT
Hash-based signatures (Lamport, Winternitz) are post-quantum safe because they only rely on hash functions - which quantum computers slow down but cannot break. The catch is they are one-time: reuse a key and you leak the private side. opus-lux's first design tried to soften that by chaining ~50,000 Lamport hash links together, where each link authorises the next fresh Winternitz key. Winternitz was also tuned aggressively (
w=256 instead of the usual 16) to shrink signature size.MURCH'S OBJECTIONS
- State growth: the design needs nodes to remember every "used" key. At 10% adoption that list grows ~5.8 GB/year - worse than the UTXO set itself.
- Inflexibility: locking one Winternitz key per output blocks fee-bumping (RBF) and shared transactions like coinjoin.
- Privacy: every output traces back to a single shared genesis transaction, linking many UTXOs to the same entity.
- PQ escape hatch: leaving a Schnorr key-path spend in the output means a quantum attacker can still steal the funds via the classical path.
PIVOT
opus-lux acknowledged the issues and dropped the Lamport chains and global "used keys" tracking entirely, pivoting to P2WOTS, which uses each spending transaction's unique txid as the per-key anchor instead. That is the next slide.
P2WOTS
opus-lux, Delving Bitcoin, 2026-05-24 (signet demo 2026-06-04)
CORE IDEA
A new output type using lightweight Winternitz one-time signatures directly at the UTXO level. The initial thread targeted SegWit witness version 2, but Murch noted that BIP-360 / P2MR already uses that slot; opus-lux then moved the proposal toward witness version 3. The key insight: every Bitcoin transaction already has a globally unique txid, so the transaction itself becomes the per-key anchor - no shared list of "used" keys, no off-chain chaining. Each address commits to a small Merkle tree of 64 ready-to-use one-time keys; one P2WOTS input contributes about 434 vbytes of witness data (a Schnorr Taproot key-path input contributes ~57.5 vbytes, for the apples-to-apples comparison).
SIGNET DEMO (2026-06-04)
Interactive wallet at
block_opuslux.ar.io; reference implementation at github.com/opus-lux/bitcoin-proposal. Posted just before this Perth BitDevs - early code, expect rough edges.CONCERNS
Murch:
- Key reuse still bites: if a wallet ever signs the same output script twice, the one-time key leaks - and any quantum attacker holding both signatures can derive the private side.
- RBF clashes: replace-by-fee creates a second signature against the same key, triggering exactly that reuse case.
- Witness-version collision: BIP-360 (P2MR) already targets SegWit version 2, so P2WOTS needs a different witness-version slot and coordination before any serious draft.
Hybrid SPHINCS+ / secp256k1
conduition, bitcoindev list, 2026-03-29 (still active reference)
THE IDEA
SPHINCS+ (now standardised by NIST as SLH-DSA) is a post-quantum signature built only from hash functions - no exotic math, and unlike Winternitz it is stateless: every signature is safe to make in isolation. conduition's draft extends BIP32/39/44 wallet derivation so every wallet derives both a Schnorr key and a SPHINCS+ key. The on-chain address is a Taproot output with two spending paths: the usual Schnorr path for daily use, and a SPHINCS+ path as a quantum-safe fallback. Internal name: SSQR (Single-Signer Quantum-Resistant); proposed BIP-44 purpose constant
360.HOW DERIVATION CHANGES
The standard "extended key" structure that hardware wallets and seed phrases produce today (xpriv / xpub) is widened to carry both keys side by side. The proposal defers the most expensive SPHINCS+ computation until the first real derivation step, so most BIP-44 wallets only pay that cost once per account.
WHAT IT TARGETS
Paper wallets and BIP-44-style hot wallets, where users want to know "if Schnorr ever breaks, can I still get my coins out?" The hybrid layout means today's Schnorr UX is unchanged, but a SPHINCS+ escape hatch is baked into every address.
ECDSA.fail and Circuit Costs
Eigen Labs leaderboard + Babbush et al. arXiv 2603.28846
THE CHALLENGE
A quantum attack on a Bitcoin key needs two things: enough qubits (the "memory") and enough Toffoli gates (the costly operations). ECDSA.fail crowdsources the smallest possible quantum circuit to break secp256k1 - so the community has a single, comparable number tracking how close a real attack actually is. The baseline is Litinski's 2023 published circuit; submissions track improvements per model generation.
BABBUSH ET AL. (ARXIV 2603.28846)
2026 whitepaper: 2-3× smaller gate and qubit count than Litinski by optimising the elliptic-curve point-addition circuit.
BABBUSH TRADE-OFF
Two upper-bound points on the same curve: <1,200 logical qubits + <90M Toffolis, or <1,450 logical qubits + <70M Toffolis. "Logical" is the error-corrected count - each one costs thousands of physical qubits in real hardware. Even the friendlier estimate is well beyond today's machines.
SECP256K1 FOLLOW-UP
Schrottenloher (arXiv 2606.02235) gives a comparable secp256k1 circuit: roughly 1.5% more qubits than Babbush and 6.5-10% fewer Toffolis (baseline not pinned to one Babbush trade-off point in the abstract), exploiting secp256k1's pseudo-Mersenne prime structure.
WHY THIS MATTERS
Numbers like these are how the community decides what "cryptographically relevant" quantum computer means. QCAP, P2WOTS and SPHINCS+ all exist because that line keeps moving toward feasibility.