Introduction

Cryptography is Bitcoin’s foundation. Not metaphorically—literally. Without collision-resistant hashing, the blockchain couldn’t link blocks. Without signature schemes, ownership couldn’t be proven. Without hardness assumptions holding, the entire security model collapses.

This chapter unpacks those cryptographic primitives and the assumptions they rest on. It also addresses the elephant in the cryptographic room: quantum computing, and what happens when today’s hardness assumptions don’t hold anymore.

Signature Schemes

ECDSA on secp256k1 secures ownership proofs

Bitcoin transactions prove control of UTXOs via ECDSA signatures over secp256k1. The curve equation is y²=x³+7 over a prime finite field defined by a 256-bit prime number. The curve name “secp256k1” indicates “Standards for Efficient Cryptography,” prime field, 256-bit field size, and the first standardized curve of its type.

Deterministic nonces following RFC 6979 mitigate reuse risks. Earlier implementations used random nonces, which created vulnerabilities—weak randomness could leak private keys through signature math. Bitcoin Core implemented RFC 6979 in 2013 to address this, generating deterministic nonces from the private key and message rather than relying on external randomness sources.

The curve choice balances performance and security. Its long use in Bitcoin and other systems provides a well-studied profile despite limited standardization history compared to NIST curves.

Schnorr signatures (Taproot) enable aggregation and privacy.

Taproot introduced Schnorr-based key-path spending, allowing public keys to aggregate and signatures to combine. This reduces on-chain footprint and makes multisig indistinguishable from single-sig in the key path. Schnorr signatures offer several cryptographic advantages: signature aggregation combining multiple signatures into one constant-size signature regardless of number of signers.

This improves privacy and fee efficiency while laying groundwork for advanced constructions like adaptor signatures. Schnorr signatures support threshold signature schemes with BLS signatures offering efficient multi-signature schemes where verification time is nearly independent of the number of signers.

Still, Schnorr adoption remains gradual. Most Bitcoin transactions still use ECDSA.

Multisig scripts enforce threshold control over outputs.

Native multisig—P2SH, later P2WSH, and Taproot script paths—distributes signing authority, supporting institutional custody and corporate controls. Threshold policies reduce single-key risk. In a (t, n) threshold signature scheme, any combination of t+1 parties can produce a valid signature while subsets of t or fewer cannot.

Taproot can hide complex multisig trees unless exercised, limiting information leakage. By aggregating keys into a single public key, Taproot makes complex policy indistinguishable from single-sig unless a fallback script path is exercised.

Data Model

Double SHA-256 anchors block headers and Merkle leaves.

Blocks and transactions rely on SHA-256 for hashing. Headers are hashed twice to produce proof-of-work targets and chain linking. SHA-256 is a member of the SHA-2 family designed by the NSA in 2001, producing fixed 256-bit hash outputs from variable-length inputs.

Collision and preimage resistance underpin immutability: altering history would require infeasible recomputation of cumulative work. SHA-256’s conservative design and broad analysis make it a stable choice for long-term security. Current cryptanalytic attacks on SHA-256 include pseudo-preimage attacks covering 43 steps with complexity 2^219.9, while full 64-step SHA-256 remains unbroken after 20+ years of academic scrutiny.

Collision resistance critical for immutability and SPV proofs.

Merkle roots rely on collision resistance to ensure unique mapping from transaction sets to root hashes. Light clients depend on this property for Simplified Payment Verification, trusting that a presented Merkle path corresponds to the real block contents validated by full nodes.

If SHA-256 is broken, Merkle tree security fails. The 256-bit output size creates astronomically large output space—2^256 possible values—making random collisions computationally impossible under current understanding.

Merkle roots summarize transaction sets per block

Transactions are hashed into a Merkle tree whose root is stored in the header. This allows light clients to verify inclusion proofs without downloading full blocks, balancing scalability and trust minimization. It also underpins compact block relay and fraud-proof concepts explored in research.

The logarithmic proof size—approximately 20 sibling hashes for one million transactions—makes this verification practical even on mobile devices.

Randomness Foundations

Nonces in PoW act as unpredictable search space for valid blocks.

Proof-of-work relies on miners iterating nonces and extra nonce fields within the coinbase to find hashes below target. This brute-force search provides unpredictable randomness that secures block selection without centralized coordination, preventing precomputation of winning hashes.

Finding a valid hash is computationally expensive but trivial to verify—simply hashing the block header and comparing the result to the target. The difficulty adjustment mechanism ensures Bitcoin maintains approximately 10-minute average block time despite fluctuations in total network hashrate.

Key generation relies on secure randomness to avoid key reuse leaks

No VRF/VDF primitives at protocol level.

ZK Systems Presence

No native SNARK/STARK usage on base layer.

Bitcoin’s base protocol avoids zero-knowledge proof systems to limit complexity. Validation remains fully transparent and deterministic, easing auditability and reducing cryptographic agility risks at the consensus layer.

This is deliberate conservatism. Adding ZK systems would require consensus changes with uncertain security implications.

Emerging rollups and sidechains experiment with validity proofs

Research and external systems explore ZK rollups anchored to Bitcoin, proposing validity proofs for compressed transaction batches. Multiple projects—Bison Labs, Alpen Labs—develop zero-knowledge rollups providing Bitcoin-based ZK computing.

These remain off-protocol experiments. Adopting them would require careful consensus changes and community agreement to balance scalability with simplicity—a politically fraught process given Bitcoin’s conservative governance.

Taproot enables script-path privacy but not zero-knowledge hides

Taproot’s script-path commitments allow hidden spending conditions revealed only when executed. While this offers privacy, it isn’t zero-knowledge. Spending paths are revealed at spend time, keeping validation transparent.

The distinction matters. Taproot improves privacy without sacrificing auditability—a balance that reflects Bitcoin’s design philosophy.

Trusted Setup Considerations

Base layer avoids trusted setups entirely.

Bitcoin’s cryptography relies on primitives without ceremonial setup, reducing systemic trust assumptions. This aligns with the project’s ethos of minimizing external trust anchors and preserving verifiability by any participant.

No trusted setup means no ceremony vulnerability. No single point of failure in parameter generation.

Sidechains/rollups adopting ZK may introduce setup ceremonies.

External systems that peg to Bitcoin but use ZK proofs can require trusted setups. Users interacting with those systems must evaluate the additional trust and upgrade risks, as these setups can become single points of failure if compromised.

NIST has standardized post-quantum cryptography algorithms including lattice-based schemes like ML-DSA and SLH-DSA designed to resist known quantum attacks. However, migrating Bitcoin to PQC algorithms presents several challenges.

User vigilance required when bridging to systems with setup trust.

Bridges and wrapped assets inherit the setup risks of their target environments. Bitcoin holders should weigh convenience against potential dilution of Bitcoin’s trust-minimized properties when moving value into such systems.

Wrapped BTC on Ethereum, for example, introduces custody and bridge trust that doesn’t exist in native Bitcoin holdings.

Curve and Key Assumptions

Security depends on discrete log hardness of secp256k1.

ECDSA and Schnorr both rely on the elliptic curve discrete logarithm problem. Advances in algorithms or quantum computing that threaten ECDLP would undermine signature security. Bitcoin’s reliance on a single curve focuses risk, making monitoring of cryptanalytic research essential.

There’s tension here worth acknowledging—using a single curve simplifies implementation but concentrates cryptographic risk.

Public key reuse increases exposure window to hypothetical attacks.

Mining pools smooth variance by paying participants proportional to submitted shares that prove contributed hashpower. Pool payout schemes—PPS, FPPS, PPLNS—balance variance and pool solvency risk, affecting miner preference but not consensus rules.

Analysis of large Bitcoin mining pools found that a small number of pool entities continuously control most network computing resources. Within individual pools, reward distribution is highly concentrated—in three analyzed pools, fewer than 20 actors received over 50% of all Bitcoin payouts. However, miners can switch pools quickly.

Taproot reduces public key exposure until spend time

Taproot’s key-path design keeps internal keys hidden until a spend occurs, limiting data available for potential future cryptanalysis and improving privacy compared to legacy pay-to-pubkey-hash where hashes are revealed earlier.

More modern address types—P2PKH, P2SH-wrapped SegWit, native SegWit, Taproot—expose public keys only at spend-time, reducing quantum attack feasibility to the 10-minute window between broadcast and confirmation.

Hardness Problem Reliance

Assumes infeasibility of SHA-256 preimage/collision and ECDLP solutions.

Bitcoin’s security budget rests on two main hardness assumptions: SHA-256 resistance and ECDLP over secp256k1. Breaking either would jeopardize block integrity or signature security. Diversification beyond these primitives hasn’t been incorporated to maintain simplicity and compatibility.

SHA-256 possesses three critical security properties: collision resistance (computationally infeasible to find two different inputs producing the same hash), preimage resistance (given a hash output, it’s computationally infeasible to determine the original input), and second-preimage resistance (for a given input, finding another input producing the same hash output is computationally infeasible).

Honest-majority economic assumption complements cryptographic hardness.

Even with strong cryptography, Bitcoin’s integrity requires that most hashpower follows consensus rules. The economic assumption ties miner incentives to network value. Attacks would erode the value of the asset miners earn, aligning behavior with protocol safety.

A 51% attack occurs when an entity controls more than 50% of the network’s mining hashrate and can theoretically reverse recent transactions by mining a private alternative chain and releasing it to overtake the honest chain. Duke University analysis estimates a week-long 51% attack could theoretically be executed for approximately $6 billion at October 2025 prices—less than 1% of Bitcoin’s approximately $600 billion market capitalization.

Fee market incentivizes honest participation over attacks.

As subsidies decline, transaction fees become a larger share of miner revenue. Sustained fees rely on user trust. Attempts to censor or rewrite transactions would degrade that trust and fee revenue, providing economic disincentives to deviate from honest mining.

The picture isn’t entirely clear on whether fee revenue will suffice once subsidies approach zero. This represents a fundamental long-term uncertainty.

Multisig Architectures

Standard 2-of-3 and 3-of-5 protect institutional and shared wallets.

Threshold policies distribute control, mitigating single-key compromise. Institutions adopt 2-of-3 or higher thresholds to meet custody standards, often combining hardware security modules and geographic separation to reduce correlated risk.

Typical enterprise configurations use 3-of-5 or 2-of-3 multisig structures with geographically separated signers to prevent collusion and physical theft. Fireblocks custody uses Multi-Party Computation generating no single private key stored anywhere, enabling faster transactions with 8x speed improvement and 90% fee reduction compared to multi-sig alternatives.

Taproot hides multisig topology via key aggregation.

By aggregating keys into a single public key, Taproot makes complex policy indistinguishable from single-sig unless a fallback script path is exercised. This reduces information leakage and fee cost while retaining policy flexibility off-chain.

The privacy benefits are substantial. External observers can’t distinguish between single-sig and complex multi-party control just by examining the blockchain.

Federation multisig (11-of-15 Liquid) governs peg operations.

Federated sidechains like Liquid use multisig quorums to manage two-way pegs. While improving speed and features, they introduce federation trust. Users must rely on signers’ honesty and operational security, a different model from Bitcoin’s trust-minimized base layer.

Liquid sidechain’s federated model requires 11-of-15 multisig signatures to authorize Bitcoin peg-ins and peg-outs. Federation member collusion could freeze funds or authorize invalid pegs—a centralization point that doesn’t exist in base-layer Bitcoin.

Upgradeability and Quantum Readiness

Quantum threats (Shor, Grover) endanger ECDSA and SHA-256 margins.

Large-scale quantum computers running Shor’s algorithm could break ECDSA, while Grover’s algorithm halves hash security levels. Shor’s algorithm can theoretically factor large numbers and solve discrete logarithm problems exponentially faster than classical algorithms. Grover’s algorithm reduces effective security of SHA-256 by roughly half—from 256 bits to 128 bits.

Current estimates place practical quantum attacks beyond near-term horizons, but migration planning remains a topic in research and standards bodies. Quantum threat timelines remain contested. Pessimistic estimates suggest fault-tolerant quantum computers capable of breaking Bitcoin’s ECC could emerge as early as 2028-2030 with sufficient qubit stability.

25% legacy P2PK outputs vulnerable until rotated.

Early pay-to-pubkey outputs expose public keys on-chain, making them immediate targets if quantum attacks become feasible. A proactive rotation campaign would be needed to move funds into post-quantum or at least hashed-key schemes before credible quantum capability emerges.

Chamath Palihapitiya estimated a quantum computer with 8,000 stable logical qubits could crack Bitcoin’s encryption within 24 months. However, IBM and other quantum researchers suggest millions of physical qubits remain necessary for practical attacks, with full fault tolerance potentially not achievable until 2030 or later.

PQC migration faces key-size bloat and consensus coordination hurdles.

Adopting post-quantum cryptography would increase transaction sizes and require network-wide coordination. Any switch must balance security gains with decentralization costs. Soft-forkable approaches and hybrid schemes are under study but remain unadopted to preserve stability.

Some proposed solutions include hybrid signatures combining classical ECDSA with PQC schemes to hedge quantum risk while maintaining backward compatibility. Strategic preparedness for quantum threats prioritizes migrating P2PK funds to modern address types and monitoring quantum hardware development roadmaps.

The “harvest now, decrypt later” strategy heightens urgency—adversaries collecting Bitcoin public keys today could theoretically decrypt them once quantum computers become sufficiently powerful. In practice, this gets messy when balancing immediate usability against long-term quantum risk.

Conclusion

Cryptography isn’t magic. It’s math that we believe is hard. Those beliefs rest on decades of failed attempts to break the primitives Bitcoin uses—SHA-256, secp256k1, ECDSA, and now Schnorr. They’ve held so far. But “so far” isn’t “forever,” and quantum computing represents the most credible long-term threat to Bitcoin’s cryptographic assumptions. Whether the community can coordinate a migration before quantum capability arrives remains an open question. One that matters more with each passing year.