diff --git a/.typos.toml b/.typos.toml index 15d831fa1e..8ff6f5309d 100644 --- a/.typos.toml +++ b/.typos.toml @@ -15,6 +15,8 @@ extend-ignore-re = [ "ser.*", "prefix.*", "value: .*", + "pqNTRUsign", + "Strnad", ] [default.extend-words] diff --git a/README.mediawiki b/README.mediawiki index 56bed4e076..daf3248d0c 100644 --- a/README.mediawiki +++ b/README.mediawiki @@ -1169,6 +1169,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Matt Corallo, Bastien Teinturier | Standard | Draft +|- +| [[bip-0360.mediawiki|360]] +| Consensus (soft fork) +| Pay to Quantum Resistant Hash +| Hunter Beast +| Standard +| Draft |- style="background-color: #cfffcf" | [[bip-0370.mediawiki|370]] | Applications diff --git a/bip-0360.mediawiki b/bip-0360.mediawiki new file mode 100644 index 0000000000..001664ffb3 --- /dev/null +++ b/bip-0360.mediawiki @@ -0,0 +1,738 @@ +
+  BIP: 360
+  Title: Pay to Quantum Resistant Hash
+  Layer: Consensus (soft fork)
+  Author: Hunter Beast 
+  Comments-Summary: No comments yet.
+  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0360
+  Status: Draft
+  Type: Standards Track
+  Created: 2024-12-18
+  License: BSD-3-Clause
+
+ + +== Introduction == + +=== Abstract === + +This document proposes the introduction of a new output type using signatures based on Post-Quantum Cryptography (PQC). +This approach for adding a post-quantum secure output type does not require a hard fork or block size increase. + +=== Copyright === + +This document is licensed under the 3-clause BSD license. + +=== Motivation === + +The primary threat to Bitcoin from Cryptoanalytically-Relevant Quantum Computers (CRQCs) +A Cryptoanalytically-Relevant Quantum Computer is an ''object'' which is only loosely defined by ''characteristics'' in quantum physics as of today. It could be understood in the context of this BIP and in bitcoin that it's a ''hardware-agnostic'' computer supposed to have the architecture to keep ''coherent'' a sufficient number of logical qubits to be able to run the Shor algorithm in an efficient fashion. +is their potential to break the cryptographic assumptions of Elliptic Curve Cryptography (ECC), which secures Bitcoin's signatures and Taproot +commitments. Specifically, [https://arxiv.org/pdf/quant-ph/0301141 Shor's algorithm] enables a CRQC to solve the +Discrete Logarithm Problem (DLP) exponentially faster than classical methodsShor's algorithm is +believed to need 10^8 operations to break a 256-bit elliptic curve public key., allowing the derivation of +private keys from public keys-- a process referred to here as quantum key decryption. +Meaning, deriving private keys from public keys via Shor's algorithm +Importantly, simply doubling the public +key length (e.g., using a hypothetical secp512k1 curve) would only make deriving the private key twice as hard, +offering insufficient protection. The computational complexity of this attack is further explored in +[https://pubs.aip.org/avs/aqs/article/4/1/013801/2835275/The-impact-of-hardware-specifications-on-reaching ''The impact of hardware specifications on reaching quantum advantage in the fault-tolerant regime'']. + +This proposal aims to mitigate these risks by introducing a Pay to Quantum Resistant Hash (P2QRH) output type that +relies on PQC signature algorithms. By adopting PQC, Bitcoin can enhance its quantum +resistance without requiring a hard fork or block size increase. + +The vulnerability of existing Bitcoin addressesA vulnerable Bitcoin address is any +''scriptPubKey'' type that exposes an elliptic curve public key as ''raw bytes'' in a ''block'', making it susceptible +to private key derivation through Shor's algorithm. This includes P2PK outputs and any script that contains an +unprotected public key. is detailed in +[https://web.archive.org/web/20240715101040/https://www2.deloitte.com/nl/nl/pages/innovatie/artikelen/quantum-computers-and-the-bitcoin-blockchain.html this Deloitte report]. +The report estimates that in 2020 approximately 25% of the Bitcoin supply is held within addresses vulnerable to +quantum attack. As of the time of writing, that number is now closer to 20%. Independently, Bitcoin developer Pieter +Wuille [https://web.archive.org/web/20220531184542/https://twitter.com/pwuille/status/1108085284862713856 reasons] even more addresses might be vulnerable, representing +5M to 10M bitcoin. + +Ordinarily, when a transaction is signed, the public key is explicitly stated in the input script. This means that the +public key is exposed on the blockchain when the transaction is spent, making it vulnerable to quantum attack until +it's mined. One way to mitigate this is to submit the transaction directly to a mining pool, bypassing the mempool. +This process is known as an out-of-band transaction or a private mempool. In this case, the mining pool must be trusted +not to reveal the transaction public key to attackers. The problem with this approach is that it requires a trusted +third party, which the P2QRH proposal aims to avoid. It also doesn't account for block reorg attacks, which would +reveal public keys in blocks that were once mined but are now orphaned and must be mined again. Additionally, +it depends on the mining pool whether they reveal their block template to either the public or to miners. + +Not having public keys exposed on-chain is an important step for quantum security. Otherwise, funds would need to be +spent to new addresses on a regular basis in order to prevent the possibility of a "long-exposure CRQC attack" recovering +the key behind high-value addresses. A long-exposure quantum attack can be considered one performed with chain data, such +as that from a used address or one encoded in a spend script. This is likely to be more common early on, as early +quantum computers must be run for longer in order to overcome errors caused by noise. A "short-exposure quantum attack" +would be one performed on keys in the mempool, which is seen as much more difficult given the block time, and so it +requires more sophisticated CRQCs. +In the paper +[https://arxiv.org/pdf/2306.08585 How to compute a 256-bit elliptic curve private key with only 50 million Toffoli gates] +the authors estimate that a CRQC with 28 million superconducting physical qubits would take 8.3 seconds to calculate a +256-bit key, while a CRQC with 6.9 million physical qubits would take 58 seconds. This implies that a CRQC with 4x as +many qubits would be roughly 7 times faster. + + +As the value being sent increases, so too should the fee in order to commit the transaction to the chain as soon as +possible. Once the transaction is mined, it makes useless the public key revealed by spending a UTXO, so long as it is +never reused. + +It is proposed to implement a Pay to Quantum Resistant Hash (P2QRH) output type that relies on a PQC signature +algorithm. This new output type protects transactions submitted to the mempool and helps preserve the free market by +preventing the need for private, out-of-band mempool transactions. + +The following table is intended to inform the average Bitcoin user whether their bitcoin is vulnerable to a long-exposure +quantum attack: + +{| class="wikitable" +|+ Output types vulnerable to long-exposure attacks on unspent addresses +|- +! Type !! Vulnerable !! Prefix !! Example +|- +| P2PK || Yes || Varies || 2103203b768951584fe9af6d9d9e6ff26a5f76e453212f19ba163774182ab8057f3eac +|- +| P2PKH || No¹ || 1 || 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa +|- +| P2MS || Yes || Varies || 52410496ec45f878b62c46c4be8e336dff7cc58df9b502178cc240e... +|- +| P2SH || No¹ || 3 || 3FkhZo7sGNue153xhgqPBcUaBsYvJW6tTx +|- +| P2WPKH || No¹ || bc1q || bc1qsnh5ktku9ztqeqfr89yrqjd05eh58nah884mku +|- +| P2WSH || No¹ || bc1q || bc1qvhu3557twysq2ldn6dut6rmaj3qk04p60h9l79wk4lzgy0ca8mfsnffz65 +|- +| P2TR || Yes || bc1p || bc1p92aslsnseq786wxfk3ekra90ds9ku47qttupfjsqmmj4z82xdq4q3rr58u +|- +| P2QRH || No || bc1r || bc1r8rt68aze8tek87cnz4ndnvfzk6tk93jv39n4lmpu5a4yw453rcpszsft3z +|} + +¹ Funds in P2PKH, P2SH, P2WPKH, and P2WSH outputs become vulnerable to long-exposure quantum attacks when their input script is revealed. An address is no longer safe against long-exposure quantum attacks after funds from it have been spent. + +It should be noted that Taproot outputs are vulnerable in that they encode a 32-byte x-only public key, from which a +full public key can be reconstructed. + +If a CRQC recovers an extended public key (xpub), including its chain code, it can derive all non-hardened child public +keys by guessing or iterating through child indexes, as allowed by BIP-32's non-hardened derivation. With Shor's +algorithm, the CRQC could then compute the corresponding non-hardened child private keys directly from those public keys, +without needing the extended private key (xprv) or an exposed child private key. Hardened child keys remain secure since +they cannot be derived from the xpub alone. However, if the xprv is exposed, then all child private keys--both hardened +and non-hardened--become vulnerable. Thus, in a quantum context, the xpub alone is sufficient to expose all non-hardened +child private keys. + +==== Long Exposure and Short Exposure Quantum Attacks ==== + +A Long Exposure Quantum Attack is an attack in which the public key has been exposed on the blockchain for an extended +period of time, giving an attacker ample opportunity to break the cryptography. This affects: + +* P2PK outputs (Satoshi's coins, CPU miners, starts with 04) +* Reused addresses (any type, except P2QRH) +* Taproot addresses (starts with bc1p) +* Extended public keys, commonly known as "xpubs" +* Wallet descriptors + +A Short Exposure Quantum Attack is an attack that must be executed quickly while a transaction is still in the mempool, +before it is mined into a block. This affects: + +* Any transaction in the mempool (except for P2QRH) + +Short-exposure attacks require much larger, more expensive CRQCs since they must be executed within the short window +before a transaction is mined. Long-exposure attacks can be executed over a longer timeframe since the public key remains +exposed on the blockchain indefinitely. + +Coinbase outputs to P2PK keys go as far as block 200,000, so there are, at the time of writing, 1,723,848 coins that +are vulnerable from the first epoch in P2PK outputs alone. The majority of these have a block reward of 50 coins each, +and there are roughly 34,000 distinct P2PK scripts that are vulnerable. These coins can be considered +"Satoshi's Shield." Any addresses with a balance of less than the original block subsidy of 50 coins can be considered +cryptoeconomically incentive incompatible to capture until all of these are mined, and these addresses serve to provide +time to transition Bitcoin to implement post-quantum security. + +It's for the above reason that, for those who wish to be prepared for quantum emergency, it is recommended that no more +than 50 bitcoin are kept under a single, distinct, unused Native SegWit (P2WPKH, "bc1q") address at a time. This is +assuming that the attacker is financially motivated instead of, for example, a nation state looking to break confidence +in Bitcoin. Independently, this assumes that other vulnerable targets such as central banks have upgraded their +cryptography by this time. + +The Commercial National Security Algorithm Suite (CNSA) 2.0 has a timeline for software and networking equipment to be +upgraded by 2030, with browsers and operating systems fully upgraded by 2033. According to NIST IR 8547, Elliptic Curve +Cryptography is planned to be disallowed within the US federal government after 2035. An exception is made for hybrid +cryptography, which is the use of ECC and post-quantum algorithms together. + +Although the main threat posed by CRQCs is to the signatures used in Bitcoin, a smaller threat is to Bitcoin's hash +algorithms. In particular, while a CRQC could use [https://en.wikipedia.org/wiki/Grover's_algorithm Grover's algorithm] +to gain a quadratic speedup on brute-force attacks on the hash functions used in Bitcoin, a significantly more powerful +CRQC is needed for these attacks to meaningfully impact Bitcoin. For instance, a preimage attack on +HASH160 Used by P2PKH, P2SH, and P2WPKH addresses, though not P2WSH because it uses 256-bit hashes. +using Grover's algorithm would require at least 10^24 quantum operations. As for Grover's application to mining, see +[https://quantumcomputing.stackexchange.com/a/12847 Sam Jaques' post on this]. + +=== Rationale === + +This is the first in a series of BIPs under a QuBit soft fork. A qubit is a fundamental unit of quantum computing, and +the capital B refers to Bitcoin. The name QuBit also rhymes to some extent with SegWit. + +It is proposed to use SegWit version 3. This results in addresses that start with bc1r, which could be a useful way to +remember that these are quantum (r)esistant addresses. This is referencing the lookup table under +[https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#bech32 BIP-173]. + +P2QRH is meant to be implemented on top of P2TR, combining the security of classical Schnorr signatures along with +post-quantum cryptography. This is a form of hybrid cryptography such that no regression in security is presented +should a vulnerability exist in one of the signature algorithms used. One key distinction between P2QRH and P2TR +however is that P2QRH will encode a hash of the public key. This is a significant deviation from how Taproot works by +itself, but it is necessary to avoid exposing public keys on-chain where they are vulnerable to attack. + +P2QRH uses a 32-byte HASH256 (specifically SHA-256 twice-over) of the public key to reduce the size of new outputs and +also to increase security by not having the public key available on-chain. While HASH256 uses double SHA-256 like +Bitcoin's Proof of Work, this does not meaningfully increase quantum resistance compared to single SHA-256, as both +provide approximately 2^128 security against Grover's algorithm. The practical impact of quantum attacks on SHA-256 +remains theoretical since quantum circuits for SHA-256 are still theoretical, but using the same hash function as +Proof of Work maintains consistency with Bitcoin's existing security model. This hash serves as a minimal cryptographic +commitment to a public key in the style of a +[https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#user-content-Witness_program BIP-141 witness program]. +Because it goes into the scriptPubKey, it does not receive a witness or attestation discount. + +Post-quantum public keys are generally larger than those used by ECC, depending on the security level. +Originally BIP-360 proposed NIST Level V, 256-bit security, but this was changed to NIST Level I, 128-bit security +due to concerns over the size of the public keys, the time it would take to verify signatures, and being generally +deemed "overkill". + +Support for FALCON signatures will be introduced first, with the intention of adding other post-quantum +algorithms as they are approved. By way of comparison, FALCON signatures are roughly 20x larger than Schnorr signatures. +FALCON has recently been approved by NIST. NIST approval streamlines implementations through establishing +consensus in the scientific and developer community. This means, to maintain present transaction throughput, an +increase in the witness discount will likely be desired in a QuBit soft fork. That will be specified in a future QuBit +BIP. + +An increase in the witness discount must not be taken lightly. It must be resistant to applications that might take +advantage of this discount (e.g., storage of arbitrary data as seen with "inscriptions") without a corresponding +increase in economic activity. An increase in the witness discount would not only impact node runners but those with +inscriptions would also have the scarcity of their non-monetary assets affected. The only way to prevent these effects +while also increasing the discount is to have a completely separate witness--a "quantum witness." Because it is meant +only for public keys and signatures, we call this section of the transaction the attestation. + +Additionally, it should be noted, whether an output with a P2QRH spend script corresponds to a PQC signature is not +known until the output is spent. + +While it might be seen as a maintenance burden for Bitcoin ecosystem devs to go from a single cryptosystem +implementation to three additional distinct PQC cryptosystems--and it most certainly is--the ramifications of a chain +broken through extrinsic factors should provide sufficient motivation. An increase in software maintenance everywhere +signatures are used should be seen as an acceptable compromise for maintained integrity of Bitcoin transfers during a +regime of quantum advantage. + +The inclusion of these three cryptosystems: SPHINCS+, CRYSTALS-Dilithium, and FALCON have various advocates +within the community due to their varying security assumptions. Hash-based cryptosystems are more conservative, +time-tested, and well-reviewed. Lattice cryptography is relatively new and introduces novel security assumptions to +Bitcoin, but their signatures are smaller and might be considered by some to be an adequate alternative to hash-based +signatures. + +The reason multiple cryptosystems are included is in the interest of supporting hybrid cryptography, especially for +high value outputs, such as cold wallets used by exchanges. To improve the viability of the activation client and +adoption by wallets and libraries, a library akin to libsecp256k1 will be developed. This library, libbitcoinpqc, +will support the new PQC cryptosystems and can be used as a reference for other language-native implementations. + +In the distant future, following the implementation of the P2QRH output type in a QuBit soft fork, there will likely +be a need for Pay to Quantum Secure (P2QS) addresses. A distinction is made between cryptography that's merely resistant +to quantum attack, and cryptography that's secured by specialized quantum hardware. P2QRH is resistant to quantum +attack, while P2QS is quantum secure. These will require specialized quantum hardware for signing, while still +[https://quantum-journal.org/papers/q-2023-01-19-901/ using public keys that are verifiable via classical means]. + +While P2QRH lacks features like signature aggregation for smaller transactions, it offers a pragmatic first step +toward quantum resistance. Future BIPs can add enhancements like P2QS, signature aggregation, and possibly full +BIP-32 compatibility once tested and viable. Until quantum cryptography hardware and advanced schemes are widespread, +P2QRH provides meaningful protection against quantum threats without delaying deployment for a perfect solution. + +Additional follow-on BIPs will be needed to implement P2QS, signature aggregation, and full BIP-32 compatibility +(if possible) BIP-32 relies on elliptic curve operations to derive keys from xpubs to support +watch-only wallets, which PQC schemes may not support.. However, until specialized quantum cryptography hardware +is widespread and signature aggregation schemes are thoroughly vetted, P2QRH addresses should be an adequate +intermediate solution that provides meaningful protection against quantum threats. + +== Specification == + +We define the signature scheme and transaction structure as follows. + +=== Descriptor Format === + +To integrate P2QRH into existing wallet software and scripts, we introduce a new output descriptor function +qrh(). This function represents a P2QRH output, similar to how wpkh() and tr() +are used for P2WPKH and P2TR outputs, respectively. + +The qrh() function takes a threshold value and multiple key specifications grouped by key type. The format is: + + qrh(threshold, keytype(0x01, [hash1, hash2, ...]), keytype(0x02, [hash1, hash2, ...]), ...) + +Where: + +* threshold is an integer specifying the minimum number of signatures required +* keytype is the hex value representing the key type (0x01 for secp256k1, 0x02 for FALCON-512, 0x04 for CRYSTALS-Dilithium Level I, 0x08 for SPHINCS+-128s) +* [hash1, hash2, ...] is an array of HASH256 hashes of public keys for the corresponding algorithm type + +For example: + + qrh(3, keytype(0x01, hash256(secp256k1_pubkey1), hash256(secp256k1_pubkey2), hash256(secp256k1_pubkey3), secp256k1_pubkey4_hash, secp256k1_pubkey5_hash), + keytype(0x02, hash256(falcon_pubkey1), hash256(falcon_pubkey2), hash256(falcon_pubkey3), falcon_pubkey4_hash, falcon_pubkey5_hash), + keytype(0x04, hash256(dilithium_pubkey1), hash256(dilithium_pubkey2), hash256(dilithium_pubkey3), dilithium_pubkey4_hash, dilithium_pubkey5_hash), + keytype(0x08, hash256(sphincs_pubkey1), hash256(sphincs_pubkey2), hash256(sphincs_pubkey3), sphincs_pubkey4_hash, sphincs_pubkey5_hash)) + +This represents a 3-of-5 multisig for each key type, with a total of 20 keys: 5 keys per type (3 full public keys and 2 +hashes) across 4 different key types. + +Internally, the descriptor computes the HASH256 of the concatenated HASH256 of all the quantum-resistant public keys, +with the threshold and key type bitmask prepended. For each key in the descriptor: + +- If it is already a hash (indicated in the descriptor), it is used directly +- If it is a public key, HASH256 is applied to it first + +This approach ensures that all items in the vector are HASH256 values, whether they originated from raw public keys or +were provided as hashes. During spending, this allows for selective disclosure of public keys, where some keys can +remain hidden (represented only by their hashes) while others are fully revealed with their corresponding public keys. +This flexibility is particularly valuable in multisig schemes where not all keys need to be revealed to satisfy the +threshold requirement. At a minimum, there should be two different key types in a P2QRH output: one key that makes use +of classical cryptography, and one that makes use of a PQC algorithm chosen within the wallet. + +Also, it's important to note that order of keys and hashes in the descriptor matters and is based on the original +public key values, in addition to the key type. Additionally, qrh() does not compile to script, but instead, describes +what's needed to compute the scriptPubKey hash commitment and also to reveal the attestation needed to spend the +output. + +=== Address Format === + +P2QRH uses SegWit version 3 outputs, resulting in addresses that start with bc1r, following +[https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#bech32 BIP-173]. Bech32 encoding maps version 3 to the +prefix r. + +Example P2QRH address: + +bc1r... (32-byte Bech32m-encoded HASH256 of the HASH256 of the public keys) + +=== ScriptPubKey === + +The scriptPubKey for a P2QRH output is: + + OP_PUSHNUM_3 OP_PUSHBYTES_32 + +Where: + +* OP_PUSHNUM_3 (0x03) indicates SegWit version 3. +* is the 32-byte HASH256 of the commitment, as defined in the Hash Commitment section below. + +==== Key Type Bitmask ==== + +The key type bitmask is a 1-byte value that indicates the type of key used in the commitment. It is encoded as follows: + +* 0x01 - Key type 0 - secp256k1 +* 0x02 - Key type 1 - FALCON-512 +* 0x04 - Key type 2 - CRYSTALS-Dilithium Level I +* 0x08 - Key type 3 - SPHINCS+-128s +* 0x10 - Unused +* 0x20 - Unused +* 0x40 - Unused +* 0x80 - Reserved for if additional key types are added in the future + +Example key type bitmask using all supported key types: + + 0x01 | 0x02 | 0x04 | 0x08 = 0x0F + +==== Hash Commitment ==== + +If there is only a single public key, the hash is computed as the HASH256 of the public key. + +In order to support multiple keys, as in the context of multisig or singlesig hybrid cryptography, the hash is +computed as a commitment to a vector of public key hashes: + +1. Sort the public keys first by key type, then by public key value +2. For each sorted public key, compute its HASH256 +3. Concatenate all the public key hashes in sorted order +4. Prepend key type bitmask and threshold to the concatenated hashes +5. Compute the HASH256 of the result + +For example with 4 public keys: + + // First sort the public keys + sorted_pubkeys = sort_by_key_type_and_value([pubkey1, pubkey2, pubkey3, pubkey4]) + + // Then compute hashes of sorted keys + h1 = HASH256(sorted_pubkeys[0]) + h2 = HASH256(sorted_pubkeys[1]) + h3 = HASH256(sorted_pubkeys[2]) + h4 = HASH256(sorted_pubkeys[3]) + + // Concatenate all hashes + concatenated = h1 || h2 || h3 || h4 + + commitment = key_type_bitmask || threshold || concatenated + + hash = HASH256(commitment) + +With sort_by_key_type_and_value defined as: + + def sort_by_key_type_and_value(pubkeys): + return sorted(pubkeys, key=lambda x: (x.key_type, x.public_key)) + +When spending, if a public key hash is provided in the attestation with an empty signature, that hash will be used +directly in the vector computation rather than hashing the full public key. This allows unused public keys to be +excluded from the transaction while still proving they were part of the original commitment. + +The vector construction creates an efficient cryptographic commitment to multiple public keys while enabling +selective disclosure. + +A threshold is provided to indicate the number of signatures required to spend the output. This is used in the +cryptographic commitment in the hash computation and revealed in the attestation when spent. + +Only a single 32-byte X-only secp256k1 public key can be provided as key type 0. There are a few reasons for this: + +1. It maintains Taproot compatibility by removing ambiguity which key is representative of the Taptree. +2. It prevents abuse of public keys to store arbitrary data once quantum computing is ubiquitous. +3. When a secp256k1 key is specified in the key type bitmask, how many keys it commits to is unambiguous. +4. If multiple keys need to be committed to, they must be aggregated, which saves on transaction size. + +This design maintains compatibility for [https://github.com/bitcoin/bips/blob/master/bip-0114.mediawiki BIP-114] +Taproot Merkelized Alternative Script Tree (MAST) merkle root in the commitment, which makes P2QRH a +quantum-resistant version of Taproot transactions. The TapScript itself must however be provided in the witness, +as no script execution is allowed in the attestation. + +In a multisig context, aside from secp256k1 keys, the number of keys provided in the attestation is variable and +must meet the threshold as committed to in the hash computation and revealed in the attestation. + +When the address is generated, all public keys must be known in advance, and they must be sorted, first by key +type, then by public key value, so as to be deterministic. + +The key count does not need to be provided for PQC keys because the key type bitmask and threshold are sufficient +to validate a multisig transaction. + +In a singlesig context, multiple PQC keys can be provided, but the key type bitmask and threshold must still also +be provided to be consistent with the multisig semantics. The threshold will be set as 0x01, and the key type +bitmask will indicate how many keys of each type are present. + +=== Transaction Serialization === + +Following BIP-141, a new transaction serialization format is introduced to include an attestation field after the witness field: + + [nVersion][marker][flag][txins][txouts][witness][attestation][nLockTime] + +* marker: 0x00 (same as SegWit) +* flag: +** 0x02 (indicates the presence of attestation data only) +** 0x03 (indicates the presence of both witness and attestation data) +* attestation: Contains the quantum-resistant public keys and signatures. + +=== Quantum Transaction ID (qtxid) === + +The transaction ID is computed as the HASH256 of the serialized transaction, including the attestation and witness +(if a witness is present). When decoded, this is called the qtxid, which will differ from the txid and wtxid if an +attestation is present. + +=== Attestation Structure === + +The attestation field consists of: + +* key_type_bitmask: A [https://learnmeabitcoin.com/technical/general/compact-size/ compact size] value indicating which key types are present. +* threshold: A compact size value indicating the number of signatures required to spend the output. +* num_pubkeys: The number of public keys (compact size). + +For each public key: + +* key_type: The key type (compact size). Only one bit is used to indicate the key type. +* pubkey_length: compact size length of the public key (compact size). +* pubkey: The public key bytes. + +Then: + +* num_signatures: The number of signatures (compact size). + +For each signature: + +* signature_length: compact size length of the signature. +* signature: The signature bytes. + +This structure repeats for each input, in order, for flexibility in supporting multisig schemes and various +quantum-resistant algorithms. + +For each input, a separate attestation field is used. To know how many attestation fields are present, implementations +must count the number of inputs present in the transaction. + +==== Attestation Parsing Example ==== + +Signing for a single input using both secp256k1 Schnorr and FALCON-512: + +Number of public keys: + + [key_type_bitmask]: 0x03 + [threshold]: 0x01 + [num_pubkeys]: 0x02 + +Pubkey 1: + [key_type]: 0x01 + [pubkey_length]: 0x20 (32 bytes) + [pubkey]: public_key_secp256k1 + +Pubkey 2: + [key_type]: 0x02 + [pubkey_length]: 0x0701 (1793 bytes) + [pubkey]: public_key_falcon_512 + +Number of signatures: + + [num_signatures]: 0x02 + +Signature 1: + [signature_length]: 0x40 (64 bytes) + [signature]: signature_secp256k1 + +Signature 2: + [signature_length]: 0x0500 (1280 bytes) + [signature]: signature_falcon_512 + +Note: This contrasts with multisig inputs, where the attestation structure repeats for each public key and signature. + +=== Signature Algorithms === + +The specific quantum-resistant signature algorithm used cannot be inferred from the length of the public key due to +collisions in length between algorithms. Instead, when each key is revealed in the attestation, the key type bitmask +indicates which algorithm was used. + +Supported PQC algorithms and their NIST Level I parameters: + +* '''secp256k1 - BIP-340 - Schnorr + X-Only''' +** Key Type 0 +** Public Key Length: 32 bytes +** Signature Length: 64 bytes +** Total Size: 96 bytes +** Cycles to sign: 42,000 (EdDSA) +** Cycles to verify: 130,000 (EdDSA) +* '''FN-DSA-512 - FIPS 206 - FALCON-512:''' +** Key Type 1 +** Public Key Length: 897 bytes +** Signature Length: 667 bytes +** Total Size: 1,564 bytes +** Cycles to sign: 1,009,764 +** Cycles to verify: 81,036 +* '''ML-DSA-44 - FIPS 204 - CRYSTALS-Dilithium Level I:''' +** Key Type 2 +** Public Key Length: 1,312 bytes +** Signature Length: 2,420 bytes +** Total Size: 3,732 bytes +** Cycles to sign: 333,013 +** Cycles to verify: 118,412 +* '''SLH-DSA-SHAKE-128s - FIPS 205 - SPHINCS+-128s:''' +** Key Type 3 +** Public Key Length: 32 bytes +** Signature Length: 7,856 bytes +** Total Size: 7,888 bytes +** Cycles to sign: 4,682,570,992 +** Cycles to verify: 4,764,084 + +Implementations must recognize the supported algorithms and validate accordingly. + +A bitmask is used to indicate the algorithm used for each public key and signature pair. The bitmask enumerates based on +the key type as indicated above. This is used in the cryptographic commitment in the hash computation and +revealed in the attestation for each public key when spent. + +=== Script Validation === + +To spend a P2QRH output, the following conditions must be met: + +1. The scriptPubKey must be of the form: + +OP_PUSHNUM_3 <32-byte hash> + +2. The attestation must include: + +* The quantum-resistant public key(s) whose HASH256 concatenated and hashed again matches the in +the scriptPubKey. + +* Valid signatures corresponding to the public key(s) and the transaction data. + +* The key type bitmask and threshold must match the commitment in the scriptPubKey. + +3. For multi-signature schemes, all required public keys and signatures must be provided for that input within the +attestation. Public keys that are not needed or available can be selectively disclosed by including their hash in the +attestation accompanied with an empty signature by providing a 0x00 signature length byte. This works so long as +enough keys to meet the threshold are provided. + +==== Sighash Calculation ==== + +The sighash for P2QRH outputs follows the same procedure as defined in [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP-341] for Taproot transactions: + +* '''Signature Message:''' A single-SHA256 of a tagged hash with the tag "TapSighash", containing transaction data. +* '''Tagged Hash:''' Computed as H(tag || tag || data) where H is SHA256 and tag is the SHA256 of the tag name. +* '''Key Data:''' In addition to transaction data, the sighash includes the spent output's scriptPubKey. +* '''Extension Fields:''' Specific data is included or excluded from the sighash based on the sighash flag. + +This signature hash construction ensures transaction malleability is prevented while providing flexibility through +different sighash types (DEFAULT, ALL, NONE, SINGLE, and ANYONECANPAY variants). The exact computation follows the +procedure specified in BIP-341 to maintain compatibility with Taproot signatures. + +If a sighash flag other than DEFAULT is needed, it can be placed in the transaction witness. In this case, it will be +the only field in the witness. + +==== Signature Verification ==== + +Signature verification is as follows: + +1. Extract the from the scriptPubKey. + +2. For each input: + +* Compute hashed_pubkeys as specified in the Hash Computation section. + +* Compare the resulting hash to . If they do not match, the script fails. + +3. Verify each signature against the corresponding public key and the sighash. + +4. Ensure that the signature algorithm used matches the expected lengths for NIST Level I security, and is supported by +the implementation. + +=== Compatibility with BIP-141 === + +By adhering to the SegWit transaction structure and versioning, P2QRH outputs are compatible with existing transaction +processing rules. Nodes that do not recognize SegWit version 3 will treat these outputs as anyone-can-spend but, per +[https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP-141], will not relay or mine such transactions. + +=== Usage Considerations === + +==== Transaction Size and Fees ==== + +Quantum-resistant signatures are significantly larger than traditional signatures, increasing transaction size and the +fees required. Users and wallet developers should be aware of this and plan accordingly. + +For example, for CRYSTALS-Dilithium Level I, a single public key is 1,312 bytes, and a signature is 2,420 bytes, resulting in a substantial increase over current +ECDSA or Schnorr signatures. + +==== Performance Impact ==== + +Verification of quantum-resistant signatures will be computationally more intensive, and any attestation discount will +also increase storage requirements. Node operators should consider the potential impact on resource usage in the long +term. Developers may need to optimize signature verification implementations, especially by implementing caching for +key generation. + +==== Algorithm Selection ==== + +Introducing three quantum-resistant algorithms to the Bitcoin ecosystem provides users with the option to select an +appropriate algorithm for their use case, generally based on the amount of value they wish to secure. Developers can +choose to implement support for multiple algorithms in wallets and on nodes to offer quantum-resistant options. + +==== Backward Compatibility ==== + +Older wallets and nodes that have not been made compatible with SegWit version 3 and P2QRH will not recognize these +outputs. Users should ensure they are using updated wallets and nodes to use P2QRH addresses and validate transactions +using P2QRH outputs. + +== Security == + +{| class="wikitable" +|+ Candidate quantum-resistant signature algorithms ordered by largest to smallest NIST Level V signature size +|- +! Signature Algorithm !! Year First Introduced !! Signature Size !! Public Key Size !! Cryptographic Assumptions +|- +| [https://en.wikipedia.org/wiki/Lamport_signature Lamport signature] || 1977 || 8,192 bytes || 16,384 bytes || +Hash-based cryptography +|- +| [https://eprint.iacr.org/2011/191.pdf Winternitz signature] || 1982 || 2,368 bytesWinternitz +signatures are much smaller than Lamport signatures due to efficient chunking, but computation is much higher, +especially with high values for w. Winternitz values are for w of 4. It's worth noting that Winternitz signatures can +only safely be used one time per public key. If addresses are reused, private key information might be leaked, allowing +attackers to spend future outputs assigned to the same address. || 2,368 bytes || Hash-based cryptography +|- +| [https://sphincs.org/data/sphincs+-r3.1-specification.pdf SPHINCS+ Rd. 3.1 (FIPS 205 - SLH-DSA)] || 2015 || 29,792 +bytes || 64 bytes || Hash-based cryptography +|- +| [https://eprint.iacr.org/2011/484.pdf XMSS]XMSS, which is based on Winternitz, uses a value of 108 +for its most compact signature size, with only a 4.6x (2.34/0.51) increase in verification time. Signing and key +generation are not considered a significant factor because they are not distributed throughout the entire Bitcoin +network, which take place only inside of wallets one time. || 2011 || 15,384 bytes || 13,568 bytes || +Hash-based cryptography (Winternitz OTS) +|- +| [https://pq-crystals.org/dilithium/ CRYSTALS-Dilithium (FIPS 204 - ML-DSA)] || 2017 || 4,595 bytes || 2,592 bytes || +Lattice cryptography +|- +| [https://eprint.iacr.org/2014/457.pdf pqNTRUsign] || 2016 || 1,814 bytes || 1,927 bytes || Lattice cryptography (NTRU) +|- +| [https://falcon-sign.info FALCON (FIPS 206 - FN-DSA)] || 2017 || 1,280 bytes || 1,793 bytes || Lattice cryptography +(NTRU) +|- +| [https://eprint.iacr.org/2022/1155.pdf HAWK] || 2022 || 1,261 bytes || 2,329 bytes || Lattice cryptography +|- +| [https://sqisign.org SQIsign] || 2023 || 335 bytes || 128 bytes || Supersingular Elliptic Curve Isogeny +|- +| [https://eprint.iacr.org/2024/760.pdf SQIsign2D-West] || 2024 || 294 bytes || 130 bytes || Supersingular Elliptic +Curve Isogeny +|- +| [https://eprint.iacr.org/2023/436.pdf SQIsignHD] || 2023 || 109 bytes (NIST Level I) || Not provided || +Supersingular Elliptic Curve Isogeny +|} + +As shown, supersingular elliptic curve quaternion isogeny signature algorithms represent the state of the art in +post-quantum cryptography, beyond lattice cryptography alone, especially when key and signature length are major +constraints. This makes inclusion of SQIsign attractive, however its performance is roughly 100,000 times slower than ECC, +which is prohibitive in blockchain contexts. Meanwhile, SPHINCS+ and CRYSTALS-Dilithium signatures are already approved +and have achieved broader community consensus. FALCON signatures are also NIST approved. + +In comparison, the size of currently used signature algorithms are: + +* ECDSA: 70-72 bytes +* Schnorr: 64 bytes + +In comparison to inception date, secp256k1 [https://www.secg.org/SEC1-Ver-1.0.pdf was originally specified in 2000]. + +One consideration for choosing an algorithm is its maturity. secp256k1 was already 8 years old by the time it was +chosen as Bitcoin's curve. Isogeny cryptography when it was first introduced was broken over a weekend. + +Signature verification speed as it compares to Schnorr or ECDSA isn't seen as high a consideration as signature size +due to block space being the primary fee constraint. As a P2QRH implementation materializes, a benchmark will be added +for performance comparison. + +An additional consideration is security level. Longer signature sizes provide more security. NIST has standardized five +security levels for post-quantum cryptography. NIST security level I provides security equivalent to 128-bit keys, and +security level V provides 256-bit security. + +== Test Vectors and Reference Code == + +TBD + +== Related Work == + +It is worth noting by way of comparison that +[https://ethresear.ch/t/how-to-hard-fork-to-save-most-users-funds-in-a-quantum-emergency/18901 Vitalik Buterin's +proposed solution] in an Ethereum quantum emergency is quite different from the approach in this BIP. His plan involves +a hard fork of the chain, reverting all blocks after a sufficient amount of theft, and using STARKs based on BIP-32 +seeds to act as the authoritative secret when signing. These measures are deemed far too heavy-handed for Bitcoin. + +== References == + +* [https://groups.google.com/g/bitcoindev/c/Aee8xKuIC2s/m/cu6xej1mBQAJ Mailing list discussion] +* [https://delvingbitcoin.org/t/proposing-a-p2qrh-bip-towards-a-quantum-resistant-soft-fork/956?u=cryptoquick Delving Bitcoin discussion] +* [https://bitcoinops.org/en/newsletters/2024/06/14/ Bitcoin Optech newsletter] +* [https://bitcoinops.org/en/podcast/2024/06/18/#draft-bip-for-quantum-safe-address-format Bitcoin Optech discussion transcript] + +== Footnotes == + + + +== Changelog == + +To help implementors understand updates to this BIP, we keep a list of substantial changes. + +* 2025-03-18 - Correct inconsistencies in commitment and attestation structure. Switch from merkle tree commitment to sorted vector hash commitment. Update descriptor format. +* 2025-03-12 - Add verification times for each algorithm. 256 -> 128 (NIST V -> NIST I). Add key type bitmask. Clarify multisig semantics. +* 2025-02-23 - More points of clarification from review. Update dead link. +* 2025-01-20 - Remove SQIsign from consideration due to significant performance concerns. Refactor language from long-range attack to long-exposure so as to not be confused with the language around block re-org attacks. +* 2024-12-18 - Assigned BIP number. +* 2024-12-13 - Update to use merkle tree for attestation commitment. Update LR & SR quantum attack scenarios. +* 2024-12-01 - Add details on attestation structure and parsing. +* 2024-10-21 - Replace XMSS with CRYSTALS-Dilithium due to NIST approval and size constraints. +* 2024-09-30 - Refactor the ECC vs PoW section. Swap quitness for attestation. +* 2024-09-29 - Update section on PoW to include partial-preimage. +* 2024-09-28 - Add Winternitz, XMSS signatures, and security assumption types to PQC table. Omit NIST Level I table. Add spend script specification. Add revealed public key scenario table. +* 2024-09-27 - Initial draft proposal + +== Acknowledgements == + +This document is inspired by [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP-341], which introduced +the design of the P2TR (Taproot) output type using Schnorr signatures. + +Much gratitude to my co-founder, Kyle Crews for proofreading and editing, to David Croisant, who suggested the name +"QuBit", and Guy Swann for pointing out the earlier name for the attestation, "quitness", was imperfect. Thank you as +well to those who took the time to review and contribute, including Jeff Bride, Adam Borcany, Antoine Riard, Pierre-Luc +Dallaire-Demers, Ethan Heilman, Jon Atack, Jameson Lopp, Murchandamus, and Vojtěch Strnad.