Bitcoin Output Types and Address Formats: Evolution and Quantum Risk

From P2PK outputs to Taproot and P2MR: how locking conditions, address encodings and quantum exposure have evolved — what is exposed long-term, what is exposed only when spent, and how far quantum-resistance preparations have come

1 What an address actually is

The Bitcoin white paper describes “a chain of digital signatures”^[1]; at the protocol level there is no “account” or “address” object. Every bitcoin is locked in a transaction output whose spending condition is written in that output's locking script (scriptPubKey); to spend it, one must supply data that satisfies the script, usually a digital signature. An address encodes a locking script as a checksummed string that people can copy, so that the payer's wallet can reconstruct the correct locking script (Figure 1). Strictly speaking, not every “address” encodes a single fixed locking script: a Silent Payments (BIP352) “sp1…” address is a set of off-chain payment instructions containing two public keys, from which the payer derives a different on-chain P2TR output for each payment^[2]. This report therefore distinguishes four layers: output type, locking condition, address encoding, and wallet or payment protocol.

Figure 1 From private key to address. The public key is derived from the private key by elliptic-curve multiplication; recovering the private key from the public key is the elliptic-curve discrete logarithm problem (ECDLP), which is infeasible on classical computers. The public key can be placed in the locking script directly or hashed first; the script is then encoded as an address.

Discussing address formats therefore means discussing two things: the type of locking script (whether it locks to a public key, a public-key hash, a script hash or a witness program) and the encoding (Base58Check, Bech32 or Bech32m). The former determines functionality and security; the latter determines what the address looks like and how well input errors are detected. Table 1 summarises the main types.

Table 1 Main Bitcoin output types and address formats

“Mainnet prefix” refers to the start of Bitcoin mainnet addresses; testnet equivalents start with m/n, 2 and tb1. P2PK and bare multisig have no widely adopted standard address encoding. Note that “bc1p” only signals witness version 1: P2TR uses a 32-byte witness program and P2A only 2 bytes — both start with bc1p, but P2A is not Taproot. “Specification / number” gives BIP assignment dates; “Deployment / activation” gives consensus activation or software deployment dates.

2 Seventeen years of evolution: what each generation solved

2.1 Genesis era (2009): P2PK and P2PKH

Bitcoin v0.1, released in January 2009, already supported two output types. P2PK writes the full public key into the locking script; most early mining rewards used it, and it has no widely used address encoding. P2PKH stores only the HASH160 of the public key on-chain (SHA-256 followed by RIPEMD-160, yielding 20 bytes) and encodes it with Base58Check as an address starting with “1”. Base58 drops easily confused characters such as 0, O, I and l and appends a 4-byte double-SHA-256 checksum, so a mistyped character is almost always caught by the wallet. A side effect of P2PKH is that the public key does not appear on-chain until the output is spent — not a quantum consideration at the time, but an important safety margin today.

Early wallets used 65-byte “uncompressed” public keys; Bitcoin 0.6.0 (2012-03-30) switched to 33-byte “compressed” keys by default^[3]. The compressed and uncompressed public keys of the same private key produce two different P2PKH addresses — a common reason why balances seem to “disappear” when old private keys are imported. SegWit v0 later required, at the level of default relay and mining policy, that P2WPKH/P2WSH use only 33-byte compressed keys; this is a policy rule, not a consensus validity requirement of BIP141^[4].

2.2 Multisig and P2SH (2011–2012): addresses starting with “3”

In October 2011, Gavin Andresen used BIP11 to define “M-of-N multisig” as a standard transaction^[5]. Such “bare multisig” (Pay-to-Multisig, P2MS) requires the payer to write all public keys into the output, making transactions large, putting the fee burden on the payer and offering no compact address. Andresen therefore also proposed BIP12 (a new opcode, OP_EVAL) and BIP13 (a new address format)^[6,7]. OP_EVAL was abandoned over implementation complexity and security concerns and superseded by BIP16 (P2SH)^[8]; Luke Dashjr's competing BIP17 was not adopted^[9].

The core idea of P2SH is “pay to the hash of a script”: the payer simply pays to a 20-byte script hash, and the receiver supplies the full redeem script when spending. The size, fee and privacy burden of complex scripts thus shifts from payer to receiver, and multisig wallets finally get short addresses. BIP16 specifies that the new rules apply from block timestamp 2012-04-01 00:00 UTC^[8]; BIP13 addresses start with “3”.

2.3 HD wallets and derivation paths (from 2012): the wallet layer of address formats

BIP32, assigned in February 2012, defines Hierarchical Deterministic (HD) wallets: a single seed can deterministically derive a vast tree of keys^[10]. A series of wallet-layer standards then used the purpose field of the derivation path to distinguish address types: BIP44 for P2PKH (“1”), BIP49 for nested SegWit (“3”), BIP84 for “bc1q” and BIP86 for single-key “bc1p”^[11–14]. These standards do not change consensus rules, but they determine which addresses users actually see in their wallets. Note that an extended public key (xpub) reveals the public key of that node and allows derivation of all non-hardened child public keys below it^[10]; leaking an account-level xpub can therefore expose the public keys behind many addresses at once, which in a quantum context also counts as exposure^[15].

2.4 Segregated Witness (2015–2017): “bc1q” and Bech32

Problems addressed: first, transaction malleability — third parties could alter signature data and thereby change the transaction ID, which hindered protocols such as the Lightning Network that rely on unconfirmed transaction IDs; second, block capacity; third, versioning for future script upgrades. BIP141, assigned on 2015-12-21, moves signatures and other “witness” data out of the transaction ID computation — eliminating txid changes caused by third-party modification of signatures on SegWit inputs and thus resolving the main malleability problem that constrained layer-two protocols — and introduces capacity rules measured in “block weight”^[16]; BIP143 defines a new signature-hash algorithm^[4]. The new output types are P2WPKH (20-byte witness program) and P2WSH (32-byte witness program). P2WSH uses a 32-byte hash because the 160-bit hash of P2SH is no longer considered safe against collision attacks costing about 2⁸⁰ operations^[16].

Address format: BIP142 initially kept Base58^[17] but was superseded by BIP173 Bech32, designed by Pieter Wuille and Greg Maxwell^[18]. Bech32 uses the human-readable prefix bc, a single case, encodes more compactly in QR codes and, being based on a BCH error-detecting code, guarantees detection of up to four character substitutions. For compatibility with wallets that could not yet pay to bc1 addresses, the witness program can also be wrapped in P2SH, producing nested SegWit addresses starting with “3”.

Activation: SegWit used BIP9 version-bits activation, with a start time of 2016-11-15 and a threshold of 95% of blocks^[16,19], which it failed to reach for many months. In 2017, BIP148, a User-Activated Soft Fork (UASF)^[20], and BIP91, a Miner-Activated Soft Fork (MASF) lowering the threshold to 80%^[21], appeared in turn. BIP91 locked in on 2017-07-21^[22]; SegWit then reached its 95% threshold at block 479,707 on 2017-08-08, entered the locked-in state from block 479,808 on 2017-08-09^[23], and activated on 2017-08-24 at block 481,824^[24]. On the wallet side, Bitcoin Core 0.16.0 (2018-02-26) added full SegWit support with nested addresses by default^[25]; from 0.20.0 (2020-06-03) bech32 addresses became the default^[26].

2.5 Taproot (2018–2021): “bc1p” and Bech32m

Problem addressed: in P2SH/P2WSH, complex spending conditions (multisig, timelocks, Lightning channels) are hidden by a hash when the output is created, but spending usually requires revealing the full redeem or witness script — exposing conditions that were never used and increasing transaction size. In January 2018, Greg Maxwell proposed the Taproot idea on the developer mailing list^[27]: combine a public key and a script tree into a single output public key. In most cases the parties cooperate and spend via the “key path” with a single signature, so outsiders cannot tell whether complex conditions exist; when the key path cannot or is chosen not to be used (for example, when the parties fail to agree), the output is spent via the “script path”, revealing only the branch actually executed.

The design is implemented by three BIPs, all assigned on 2020-01-19: BIP340 defines Schnorr signatures (their linear structure provides a foundation for key-aggregation protocols and enables batch verification; BIP340 itself does not define a key-aggregation protocol), BIP341 defines Taproot outputs (witness version 1, 32-byte x-only output public key), and BIP342 defines Tapscript^[28–30]. Meanwhile, an unexpected weakness was found in Bech32: when the final character is “p”, inserting or deleting any number of “q” characters immediately before it does not invalidate the checksum. BIP350 therefore defined Bech32m, which changes only a single constant, for witness version 1 and higher^[31]; “bc1p” addresses use this encoding, and Bitcoin Core has used Bech32m for version 1+ addresses since release 22.0^[32].

Activation: Taproot used a modified version-bits mechanism called “Speedy Trial”: the start-time parameter was 2021-04-24, with actual signal counting beginning at the first 2,016-block retarget period thereafter; the threshold was 90%. The threshold was reached at block 687,285 on 2021-06-12 and the deployment entered the locked-in state from block 687,456 on 2021-06-13^[23,33]; following the preset minimum activation height, Taproot activated on 2021-11-14 at block 709,632^[29,34].

2.6 Other recent formats

• Silent Payments (BIP352, assigned 2023-03-09): the receiver publishes a reusable address starting with “sp1”, and the payer derives a fresh P2TR output for each payment. Under the protocol's threat model, an on-chain observer cannot link these payments to the same Silent Payments address from the outputs alone (side channels such as wallet behaviour and input clustering may still leak linkage). It is a wallet-layer protocol requiring no consensus change^[2].
• P2A anchor outputs: P2A outputs could be created under standard rules ever since SegWit activated; Bitcoin Core 28.0 (2024-10-02) made spending P2A inputs standard relay policy^[35], and the design was later documented in BIP433 (assigned 2025-12-08, informational draft)^[36]. P2A is a keyless witness-version-1 output whose locking script is fixed as OP_1 <0x4e73> and whose mainnet address is always bc1pfeessrawgf; anyone can spend it with an empty witness, and it is mainly used for Child Pays for Parent (CPFP) fee bumping. It also shows that “bc1p” does not mean Taproot: bc1p only indicates witness version 1; P2TR requires a 32-byte witness program, whereas P2A has only 2 bytes^[36].

2.7 Quantum-resistance proposals (2024 to date)

BIP360 / P2MR. The first draft was submitted on 2024-09-27 under the name “P2QRH” (Pay to Quantum Resistant Hash) and assigned a number on 2024-12-18; it was renamed P2TSH in September 2025 and Pay-to-Merkle-Root (P2MR) in February 2026^[15]. The current version is essentially “Taproot without the key path”: the output commits only to the script-tree root, uses witness version 2, and its addresses start with “bc1z”. The authors state explicitly that it resists only long-exposure attacks; resisting short-exposure attacks in the mempool would require separately introducing post-quantum signatures^[15].

BIP361. Proposed by Jameson Lopp and co-authors and assigned on 2026-02-11, it is an informational draft^[37]. It envisages two phases after some post-quantum output type has been deployed: in Phase A (about 160,000 blocks, roughly three years, after activation), creating new outputs that send funds to quantum-vulnerable addresses or output types would be disallowed; in Phase B (two years later), spends using Elliptic Curve Digital Signature Algorithm (ECDSA) or Schnorr signatures would be restricted, with funds recoverable only through a quantum-safe “rescue protocol”. It explicitly depends on a “TBD post-quantum signature BIP”; as of 2026-09-26, the BIP repository index contained no post-quantum signature scheme with an assigned number.

Hourglass. A different approach to P2PK outputs: rather than freezing them, it rate-limits them. Version 2 allows at most one P2PK spend per block, with a net amount of no more than 1 BTC, to prevent a quantum attacker from dumping large amounts of early coins at once. The proposal has not been assigned a BIP number^[38]. The BIP361 authors argue that because P2PK holders cannot prove any “knowledge a quantum attacker would not have”, a rescue protocol is hard to design for such outputs, and they therefore support handling P2PK with Hourglass^[37].

Table 2 summarises the milestones of these proposals; Figure 2 presents them as a timeline.

Table 2 Main address-related proposals: proposal, numbering and activation (2011–2017)

Table 2 (continued) (2017–2026)

“BIP assigned” is taken from the Assigned header field of each document in the bitcoin/bips repository (per BIP 3); “Status” reflects the repository as of 2026-09-26. “Threshold reached” means version-bits signalling hit the activation threshold at a given block; “locked in” means the state became LOCKED_IN at the start of the next retarget period.

Figure 2 Timeline of Bitcoin address-related proposals and deployments (2009–2026). Above the axis: proposals and BIP number assignment dates; below: software releases and consensus activation dates.

3 Quantum risk: what is exposed long-term and what only when spent

3.1 Two quantum algorithms, two kinds of risk

Shor's algorithm solves discrete logarithms in polynomial time^[39], so a sufficiently large fault-tolerant quantum computer could recover private keys from public keys. Bitcoin's ECDSA and Schnorr signatures both rest on the discrete-logarithm problem on the secp256k1 curve and are equally affected. According to 2026 resource estimates, solving the 256-bit elliptic-curve discrete logarithm requires fewer than 1,200 logical qubits and 90 million Toffoli gates (or fewer than 1,450 logical qubits and 70 million Toffoli gates); these are theoretical estimates published in PRX Quantum, and a large engineering gap remains to current hardware^[40]. Different estimates trade space against time: a July 2026 preprint reduces the logical qubits needed for 256-bit prime-field curves to 835, at the cost of about 2^30.9 (≈2 billion) Toffoli gates^[41]; a September 2026 preprint gives a secp256k1 circuit with about 1,450 logical qubits and 40 million Toffoli gates and, under its assumed fault-tolerant “Walking Cat” trapped-ion architecture, estimates that one attempt needs 19,397 physical qubits and about 25.7 days, with a per-attempt success probability of about 63% — an end-to-end resource estimate, not a demonstration on existing hardware^[42]. There is therefore no architecture-independent “size of the quantum computer needed to break Bitcoin”; logical qubit count, non-Clifford gate count, error-correction overhead and runtime must be reported together.

Grover's algorithm provides only a quadratic speedup for unstructured search^[43]. For hash functions such as SHA-256 and RIPEMD-160 it roughly square-roots the cost of preimage attacks; a 160-bit hash would in theory still require about 2⁸⁰ sequential quantum operations, far beyond foreseeable hardware. Proof-of-work mining likewise gains only a quadratic speedup and is hard to parallelise. Under current resource assumptions, quantum mining is a weaker and more distant risk than signature key recovery, but if quantum miners gained an advantage it could still cause fork instability and mining centralisation^[44]. In current risk rankings, Shor-based recovery of signature keys is therefore generally regarded as a more direct threat than hash preimage attacks or quantum mining; Grover's algorithm still erodes the security margin of hash functions, but only quadratically rather than exponentially.

3.2 Long exposure versus short exposure

BIP360 distinguishes two kinds of attack^[15]. Long-exposure attacks target public keys already revealed on-chain; the attacker can spend days or months computing. The BIP360 threat model holds that such attacks are likely to become practical before short-exposure attacks because the attacker has a much longer computation window. Short-exposure attacks happen after you initiate a spend: while the transaction waits in the mempool its public key is visible, and the attacker must recover the private key before confirmation and get a conflicting spend confirmed first (for example through a more favourable fee and transaction propagation), which requires a faster quantum computer. For P2PK and P2TR, whose public keys are already on-chain, spending creates no additional exposure. Table 3 summarises the resulting risk profile by output type.

Table 3 Exposure of each output type to quantum attacks

“Long-exposure attack” refers to attacks on public keys visible on-chain for a long time, giving the attacker ample time; “short-exposure attack” refers to recovering the private key from a public key in the mempool between broadcast and confirmation (terminology per BIP360). “No additional exposure” means the public key was already public when the output was created, so spending reveals nothing new. Amounts are Erhardt's 2023 data as cited in Chaincode Labs (May 2025).

Several points are easily misunderstood:

• With respect to Shor-based long-term public-key exposure, P2TR is more exposed than a P2WPKH output whose key has not been revealed. For privacy and efficiency, Taproot places the output public key directly on-chain, which exposes every unspent P2TR output to long-exposure attacks; even if the owner only intends to use the script path, an attacker who recovers the private key of the output public key can spend directly via the key path^[15].
• “Hash-based addresses are safe” holds only under one condition: the public key controlling the Unspent Transaction Output (UTXO) has never been revealed. The danger of address reuse is that a public key revealed by a past spend continues to endanger UTXOs that still exist at, or later arrive at, the same address; merely receiving multiple payments without ever spending does not reveal the public key on-chain. Off-chain actions such as sharing an xpub or wallet descriptor with third parties, or signing messages, can also reveal the public key early^[15].
• Spending cannot avoid classical signatures. Current outputs controlled by secp256k1 keys all rely on ECDSA or Schnorr signatures when spent; P2PKH, P2WPKH and script-hash outputs reveal their public keys for the first time when spent, while the public keys of P2PK and P2TR are already on-chain. None of these outputs can therefore resist short-exposure attacks (P2SH/P2WSH could in principle commit to scripts without signature checks, but this is not common practice). A real solution requires post-quantum signatures, such as the signature standards FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) published by the U.S. National Institute of Standards and Technology (NIST) in 2024^[45]; how to implement them in Bitcoin at acceptable transaction sizes remains an open question.
• Keyless outputs fall outside this risk model (for example P2A), because they never relied on signature protection in the first place: anyone can spend them.

3.3 Scale of exposure

A May 2025 Chaincode Labs report brings together two datasets with different sources and dates. First, Project Eleven data as of mid-January 2025: about 6.26 million BTC (≈30% of supply) sit in addresses whose public keys are already exposed on-chain. Second, Mark Erhardt's classification based on 2023 on-chain data: P2PK outputs lock about 1.72 million BTC — only about 0.025% of UTXOs by count but about 8.7% of value, mostly early mining rewards from the Satoshi era — while P2TR outputs make up about 32.5% of UTXOs by count but lock only about 147,000 BTC^[44] (Figure 3). BIP361 cites more than 34% of bitcoin having revealed public keys as of 2026-03-01^[37]. These figures differ in method and date and cannot be added or directly compared, but all indicate that the problem involves millions of BTC.

Figure 3 Bitcoin with public keys already exposed on-chain. P2PK and P2TR figures are Erhardt's 2023 data; the total is Project Eleven's data as of mid-January 2025; all as cited in Chaincode Labs (May 2025). The three figures refer to different dates and cannot be added.

4 Conclusion

Each change in Bitcoin's address formats has re-balanced fees, privacy, error tolerance and upgradability: P2SH shifted complexity to the receiver, SegWit resolved the main transaction-malleability problem constraining layer-two protocols and introduced witness versions, and Taproot used Schnorr signatures and script trees to gain privacy and efficiency. Quantum computing makes a previously overlooked dimension — when the public key appears on-chain — critical. On the single criterion of whether the public keys of unspent funds are exposed long-term, Taproot narrows the quantum safety margin relative to P2WPKH: P2TR reveals its output public key when the output is created, whereas an unspent P2WPKH output whose key has never been revealed remains protected by a hash commitment. This is precisely why BIP360 chose to remove Taproot's key path.

Milestones worth watching include whether BIP360 attracts enough review and implementation support to enter activation discussions; whether a post-quantum signature BIP is assigned a number, providing the precondition for a BIP361-style migration; and how the community handles the roughly 1.72 million BTC in P2PK outputs — leave them, rate-limit them, freeze them or something else — which is more a question of governance and mechanism design than of cryptography.

References

[1] Nakamoto, S. Bitcoin: A Peer-to-Peer Electronic Cash System. 2008. https://bitcoin.org/bitcoin.pdf

[2] josibake, Somsen, R. & Falbesoner, S. BIP 352: Silent Payments. Assigned 2023-03-09. bitcoin/bips snapshot 02bebeb (2026-09-25). https://github.com/bitcoin/bips/blob/02bebeb5ef53dc21a52d5706c6b4c17b6af6c1cc/bip-0352.mediawiki

[3] Bitcoin Core. Release notes 0.6.0 (released 2012-03-30). https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.6.0.md

[4] Lau, J. & Wuille, P. BIP 143: Transaction Signature Verification for Version 0 Witness Program. Assigned 2016-01-03. bitcoin/bips snapshot 02bebeb (2026-09-25). https://github.com/bitcoin/bips/blob/02bebeb5ef53dc21a52d5706c6b4c17b6af6c1cc/bip-0143.mediawiki

[5] Andresen, G. BIP 11: M-of-N Standard Transactions. Assigned 2011-10-18. bitcoin/bips snapshot 02bebeb (2026-09-25). https://github.com/bitcoin/bips/blob/02bebeb5ef53dc21a52d5706c6b4c17b6af6c1cc/bip-0011.mediawiki

[6] Andresen, G. BIP 12: OP_EVAL. Assigned 2011-10-18. bitcoin/bips snapshot 02bebeb (2026-09-25). https://github.com/bitcoin/bips/blob/02bebeb5ef53dc21a52d5706c6b4c17b6af6c1cc/bip-0012.mediawiki

[7] Andresen, G. BIP 13: Address Format for pay-to-script-hash. Assigned 2011-10-18. bitcoin/bips snapshot 02bebeb (2026-09-25). https://github.com/bitcoin/bips/blob/02bebeb5ef53dc21a52d5706c6b4c17b6af6c1cc/bip-0013.mediawiki

[8] Andresen, G. BIP 16: Pay to Script Hash. Assigned 2012-01-03. bitcoin/bips snapshot 02bebeb (2026-09-25). https://github.com/bitcoin/bips/blob/02bebeb5ef53dc21a52d5706c6b4c17b6af6c1cc/bip-0016.mediawiki

[9] Dashjr, L. BIP 17: OP_CHECKHASHVERIFY (CHV). Assigned 2012-01-18. bitcoin/bips snapshot 02bebeb (2026-09-25). https://github.com/bitcoin/bips/blob/02bebeb5ef53dc21a52d5706c6b4c17b6af6c1cc/bip-0017.mediawiki

[10] Wuille, P. BIP 32: Hierarchical Deterministic Wallets. Assigned 2012-02-11. bitcoin/bips snapshot 02bebeb (2026-09-25). https://github.com/bitcoin/bips/blob/02bebeb5ef53dc21a52d5706c6b4c17b6af6c1cc/bip-0032.mediawiki

[11] Palatinus, M. & Rusnak, P. BIP 44: Multi-Account Hierarchy for Deterministic Wallets. Assigned 2014-04-24. bitcoin/bips snapshot 02bebeb (2026-09-25). https://github.com/bitcoin/bips/blob/02bebeb5ef53dc21a52d5706c6b4c17b6af6c1cc/bip-0044.mediawiki

[12] Weigl, D. BIP 49: Derivation scheme for P2WPKH-nested-in-P2SH based accounts. Assigned 2016-05-19. bitcoin/bips snapshot 02bebeb (2026-09-25). https://github.com/bitcoin/bips/blob/02bebeb5ef53dc21a52d5706c6b4c17b6af6c1cc/bip-0049.mediawiki

[13] Rusnak, P. BIP 84: Derivation scheme for P2WPKH based accounts. Assigned 2017-12-28. bitcoin/bips snapshot 02bebeb (2026-09-25). https://github.com/bitcoin/bips/blob/02bebeb5ef53dc21a52d5706c6b4c17b6af6c1cc/bip-0084.mediawiki

[14] Chow, A. BIP 86: Key Derivation for Single Key P2TR Outputs. Assigned 2021-06-22. bitcoin/bips snapshot 02bebeb (2026-09-25). https://github.com/bitcoin/bips/blob/02bebeb5ef53dc21a52d5706c6b4c17b6af6c1cc/bip-0086.mediawiki

[15] Beast, H., Heilman, E. & Foxen Duke, I. BIP 360: Pay-to-Merkle-Root (P2MR). Assigned 2024-12-18. bitcoin/bips snapshot 02bebeb (2026-09-25). https://github.com/bitcoin/bips/blob/02bebeb5ef53dc21a52d5706c6b4c17b6af6c1cc/bip-0360.mediawiki

[16] Lombrozo, E., Lau, J. & Wuille, P. BIP 141: Segregated Witness (Consensus layer). Assigned 2015-12-21. bitcoin/bips snapshot 02bebeb (2026-09-25). https://github.com/bitcoin/bips/blob/02bebeb5ef53dc21a52d5706c6b4c17b6af6c1cc/bip-0141.mediawiki

[17] Lau, J. BIP 142: Address Format for Segregated Witness. Assigned 2015-12-24. bitcoin/bips snapshot 02bebeb (2026-09-25). https://github.com/bitcoin/bips/blob/02bebeb5ef53dc21a52d5706c6b4c17b6af6c1cc/bip-0142.mediawiki

[18] Wuille, P. & Maxwell, G. BIP 173: Base32 address format for native v0-16 witness outputs. Assigned 2017-03-20. bitcoin/bips snapshot 02bebeb (2026-09-25). https://github.com/bitcoin/bips/blob/02bebeb5ef53dc21a52d5706c6b4c17b6af6c1cc/bip-0173.mediawiki

[19] Wuille, P., Todd, P., Maxwell, G. & Russell, R. BIP 9: Version bits with timeout and delay. Assigned 2015-10-04. bitcoin/bips snapshot 02bebeb (2026-09-25). https://github.com/bitcoin/bips/blob/02bebeb5ef53dc21a52d5706c6b4c17b6af6c1cc/bip-0009.mediawiki

[20] Fry, S. BIP 148: Mandatory activation of segwit deployment. Assigned 2017-03-12. bitcoin/bips snapshot 02bebeb (2026-09-25). https://github.com/bitcoin/bips/blob/02bebeb5ef53dc21a52d5706c6b4c17b6af6c1cc/bip-0148.mediawiki

[21] Hilliard, J. BIP 91: Reduced threshold Segwit MASF. Assigned 2017-05-22. bitcoin/bips snapshot 02bebeb (2026-09-25). https://github.com/bitcoin/bips/blob/02bebeb5ef53dc21a52d5706c6b4c17b6af6c1cc/bip-0091.mediawiki

[22] CoinDesk. BIP 91 locks in: what this means for Bitcoin and why it's not scaled yet. 21 Jul 2017. https://www.coindesk.com/markets/2017/07/21/bip-91-locks-in-what-this-means-for-bitcoin-and-why-its-not-scaled-yet

[23] mempool.space. Block data (timestamps of heights 479,707, 479,808, 481,824, 687,285, 687,456 and 709,632), accessed 2026-10-04. https://mempool.space/

[24] Bitcoin Core v31.1. src/kernel/chainparams.cpp (mainnet SegwitHeight = 481824). https://github.com/bitcoin/bitcoin/blob/v31.1/src/kernel/chainparams.cpp

[25] Bitcoin Core. Release notes 0.16.0 (released 2018-02-26). https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.16.0.md

[26] Bitcoin Core. Release notes 0.20.0 (released 2020-06-03). https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.20.0.md

[27] Maxwell, G. Taproot: Privacy preserving switchable scripting. bitcoin-dev mailing list, Jan 2018. https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015614.html

[28] Wuille, P., Nick, J. & Ruffing, T. BIP 340: Schnorr Signatures for secp256k1. Assigned 2020-01-19. bitcoin/bips snapshot 02bebeb (2026-09-25). https://github.com/bitcoin/bips/blob/02bebeb5ef53dc21a52d5706c6b4c17b6af6c1cc/bip-0340.mediawiki

[29] Wuille, P., Nick, J. & Towns, A. BIP 341: Taproot: SegWit version 1 spending rules. Assigned 2020-01-19. bitcoin/bips snapshot 02bebeb (2026-09-25). https://github.com/bitcoin/bips/blob/02bebeb5ef53dc21a52d5706c6b4c17b6af6c1cc/bip-0341.mediawiki

[30] Wuille, P., Nick, J. & Towns, A. BIP 342: Validation of Taproot Scripts. Assigned 2020-01-19. bitcoin/bips snapshot 02bebeb (2026-09-25). https://github.com/bitcoin/bips/blob/02bebeb5ef53dc21a52d5706c6b4c17b6af6c1cc/bip-0342.mediawiki

[31] Wuille, P. BIP 350: Bech32m format for v1+ witness addresses. Assigned 2020-12-16. bitcoin/bips snapshot 02bebeb (2026-09-25). https://github.com/bitcoin/bips/blob/02bebeb5ef53dc21a52d5706c6b4c17b6af6c1cc/bip-0350.mediawiki

[32] Bitcoin Core. Release notes 22.0 (released 2021-09-13). https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-22.0.md

[33] Bitcoin Optech. Newsletter #153: taproot locked in. 16 Jun 2021. https://bitcoinops.org/en/newsletters/2021/06/16/

[34] Bitcoin Core. Release notes 0.21.1 (released 2021-05-01). https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.21.1.md

[35] Bitcoin Core. Release notes 28.0 (released 2024-10-02). https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-28.0.md

[36] Sanders, G. BIP 433: Pay to Anchor (P2A). Assigned 2025-12-08. bitcoin/bips snapshot 02bebeb (2026-09-25). https://github.com/bitcoin/bips/blob/02bebeb5ef53dc21a52d5706c6b4c17b6af6c1cc/bip-0433.mediawiki

[37] Lopp, J. et al. BIP 361: Post Quantum Migration and Legacy Signature Sunset. Assigned 2026-02-11. bitcoin/bips snapshot 02bebeb (2026-09-25). https://github.com/bitcoin/bips/blob/02bebeb5ef53dc21a52d5706c6b4c17b6af6c1cc/bip-0361.mediawiki

[38] Beast, H. & Casey, M. Hourglass V2 Update. Delving Bitcoin, 10 Feb 2026. https://delvingbitcoin.org/t/hourglass-v2-update/2246

[39] Shor, P. W. Polynomial-time algorithms for prime factorization and discrete logarithms on a quantum computer. SIAM J. Comput. 26, 1484–1509 (1997). https://doi.org/10.1137/S0097539795293172

[40] Babbush, R. et al. Securing elliptic curve cryptocurrencies against quantum vulnerabilities: resource estimates and mitigations. PRX Quantum 7, 031001 (2026). https://doi.org/10.1103/j3xf-bw18

[41] Luo, H. et al. Quantum algorithm for elliptic curve discrete logarithms with space-efficient point addition. arXiv:2607.13816 (2026), preprint. https://arxiv.org/abs/2607.13816

[42] Häner, T. et al. Computing 256-bit elliptic curve discrete logarithms in 26 days on a fault-tolerant trapped-ion quantum computer with 20,000 qubits. arXiv:2609.05625 (2026), preprint. https://arxiv.org/abs/2609.05625

[43] Grover, L. K. A fast quantum mechanical algorithm for database search. Proc. 28th ACM STOC, 212–219 (1996). https://doi.org/10.1145/237814.237866

[44] Milton, A. & Shikhelman, C. Bitcoin and Quantum Computing: Current Status and Future Directions. Chaincode Labs, May 2025 (the 6.26 million BTC figure is cited from Project Eleven [PE25]; the P2PK and P2TR figures from Erhardt [Erh23]). https://chaincode.com/bitcoin-post-quantum.pdf

[45] NIST. FIPS 204: Module-Lattice-Based Digital Signature Standard; FIPS 205: Stateless Hash-Based Digital Signature Standard. Aug 2024. https://csrc.nist.gov/pubs/fips/204/final