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 d92cb78669..b8ea337472 100644 --- a/README.mediawiki +++ b/README.mediawiki @@ -1148,6 +1148,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..143dddf857 --- /dev/null +++ b/bip-0360.mediawiki @@ -0,0 +1,623 @@ +
+  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) 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 as quantum key decryption. 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 post-quantum cryptographic (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 addresses is investigated 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://x.com/pwuille/status/1108085284862713856 reasons] +even more might be vulnerable. + +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. + +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-range CRQC attack" recovering +the key behind high-value addresses. A long-range 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-range 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 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-range +quantum attack: + +{| class="wikitable" +|+ Vulnerable output types +|- +! 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-range quantum attacks when their input script is revealed. An address is no longer safe against long-range 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 an extended public key’s (xPub’s) parent private key of is recovered by CRQC, the attacker also recovers +the entire extended private key, whether it uses hardened or unhardened derivation. + +==== Long Range and Short Range Quantum Attacks ==== + +Long Range 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 + +Short Range Quantum Attack is an attack that must be executed quickly while a transaction is still in the mempool, +before it gets mined into a block. This affects: + +* Any transaction in the mempool (except for P2QRH) + +Short-range attacks require much larger, more expensive CRQCs since they must be executed within the short window +before a transaction is mined. Long-range 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 at the time of writing 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 CRQCs could pose a threat 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. 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. To promote user +adoption and general user-friendliness, the most secure variant (NIST Level V, 256-bit security) is proposed, despite +the increase in key length and verification time. + +Support for FALCON signatures will be introduced first, with the intention of adding SQIsign and other post-quantum +algorithms as they are approved. By way of comparison, FALCON signatures are roughly 4x larger than SQIsign signatures +and 20x larger than Schnorr signatures. FALCON is a more conservative approach to applied lattice cryptography than +SQIsign, and its use has recently been approved by NIST. NIST approval streamlines implementations through establishing +consensus in the scientific and developer community. However, even SQIsign signatures are roughly 5x larger than +Schnorr signatures. 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 four 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 four cryptosystems: SPHINCS+, CRYSTALS-Dilithium, FALCON, and SQIsign 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. SQIsign is much smaller; however, it is based on a very novel form of cryptography known as supersingular +elliptic curve quaternion isogeny, and at the time of writing, is not yet approved by NIST or the broader PQC community. + +The inclusion of these four PQC cryptosystems 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 to support the new PQC +cryptosystems. + +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]. +Additional follow-on BIPs will be needed to implement P2QS. However, until specialized quantum cryptography +hardware is widespread, quantum resistant addresses should be an adequate intermediate solution. + +== 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 the HASH256 of the concatenated HASH256 of the quantum-resistant public keys as +its argument. For example: + + qrh(HASH256(HASH256(pubkey1) || HASH256(pubkey2) || ...)) + +This function allows wallets to manage P2QRH addresses and outputs while accommodating multiple public keys of varying +lengths, such as in multisig schemes, while keeping the public keys hidden until the time of spending. At a minimum, +there should be two public keys in a P2QRH output, one that makes use of classical cryptography and one that makes use +of a PQC algorithm chosen within the wallet. + +=== 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 merkle root of a tree of public key hashes, as defined in the +Hash Computation section. + +=== Output Mechanics === + +To prevent storage of arbitrary data using P2QRH (QuBit) outputs, +the witness stack for inputs spending segwit v3 outputs is limited to the fixed-size signatures necessary for spending the +output, and the output must be spendable to be considered valid within node consensus. A fixed signature size will also +be helpful to disambiguate between signature types without an additional version byte, as SQIsign signatures are +substantially smaller than FALCON signatures. Consequently, the correct signature algorithm can be inferred through +byte length. The public key and signature will be pushed separately to the attestation stack. Multiple signatures can +be included in order to support multisig applications, and also for spending multiple inputs. + +Since only valid signatures can be committed to in a SegWit v3 attestation, arbitrary data cannot be added by miners, +as that would affect the consensus of their block. A CRQC operator is economically disincentivized from computing a +spendable public key that matched arbitrary signature data due to the cost of that computation. That is because the +cost of such a computation could prove quite substantial, rather than simply putting the arbitrary data within a +Taproot witness. + +==== Hash Computation ==== + +If there is only a single public key, the hash is computed as the HASH256 of the public key, as if it were a +merkle root. + +In order to support multiple keys, as in the context of multisig or singlesig hybrid cryptography, the hash is +computed as a merkle tree of multiple public key hashes: + +1. For each public key, compute its HASH256 +2. Pair the hashes and compute HASH256 of their concatenation +3. Continue pairing and hashing until reaching a single root hash +4. The final hash is the merkle root + +For example with 4 public keys: + + h1 = HASH256(pubkey1) + h2 = HASH256(pubkey2) + h3 = HASH256(pubkey3) + h4 = HASH256(pubkey4) + + h12 = HASH256(h1 || h2) + h34 = HASH256(h3 || h4) + + root = HASH256(h12 || h34) + +When spending, if a public key hash is provided in the attestation with an empty signature, that hash will be used +directly in the merkle tree computation rather than hashing the full public key. This allows excluding unused public +keys from the transaction while still proving they were part of the original commitment. + +This merkle tree construction creates an efficient cryptographic commitment to multiple public keys while enabling +selective disclosure. + +This allows for inclusion of a Taproot MAST merkle root in the attestation, which makes P2QRH a quantum-resistant +version of Taproot. + +=== 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. + +=== Transaction ID === + +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: + +* num_pubkeys: The number of public keys ([https://learnmeabitcoin.com/technical/general/compact-size/ compact size]). + +For each public key: + +* pubkey_length: compact size length of the public key. +* 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. + +=== Signature Algorithm Identification === + +The specific quantum-resistant signature algorithm used is inferred from the length of the public key. +Implementations must recognize the supported algorithms and validate accordingly. + +Supported PQC algorithms and their NIST Level V parameters: + +* '''SPHINCS+-256f:''' + * Public Key Length: 64 bytes + * Signature Length: 49,856 bytes +* '''CRYSTALS-Dilithium Level 5:''' + * Public Key Length: 2,592 bytes + * Signature Length: 4,595 bytes +* '''FALCON-1024:''' + * Public Key Length: 1,793 bytes + * Signature Length: 1,280 bytes +* '''SQIsign NIST-V:''' + * Public Key Length: 128 bytes + * Signature Length: 335 bytes + +Implementations must reject public keys and signatures that do not match expected lengths for supported algorithms. + +If there a new algorithm is added, and one of the byte sizes overlaps, then an additional byte should be prepended to the +new algorithm's public key length that indicates the specific algorithm used. + +=== 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. + +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 can be excluded by including their hash in the attestation accompanied +with an empty signature. This includes classical Schnorr signatures. + +==== Sighash Calculation ==== + +The sighash for P2QRH outputs follows the same procedure as defined in BIP-0143 for SegWit transactions: + +* '''Hash Prevouts:''' Computed over the previous outputs being spent. +* '''Hash Sequence:''' Computed over the sequence fields. +* '''Hash Outputs:''' Computed over the outputs of the transaction. + +The message to be signed includes these hashes, ensuring transaction malleability is prevented. + +==== 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 V security, and is supported by +the implementation. + +==== Attestation Parsing Example ==== + +Signing for a single input using both FALCON-1024 and secp256k1 Schnorr: + +Number of public keys: + + [num_pubkeys]: 0x02 + +Pubkey 1: + [pubkey_length]: 0x0701 (1793 bytes) + [pubkey]: public_key_falcon_1024 + +Pubkey 2: + [pubkey_length]: 0x20 (32 bytes) + [pubkey]: public_key_secp256k1 + +Number of signatures: + + [num_signatures]: 0x02 + +Signature 1: + [signature_length]: 0x0500 (1280 bytes) + [signature]: signature_falcon_1024 + +Signature 2: + [signature_length]: 0x40 (64 bytes) + [signature]: signature_secp256k1 + +Note: This contrasts with multisig inputs, where the attestation structure repeats for each public key and signature. + +=== 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 +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 V, a single signature is 4,595 bytes, 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 four 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. || 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, and support is planned, but it will be some time until it is +approved for production use. 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. + +Ideally SQIsign also proves to be flexible enough to support +[https://www.pierrickdartois.fr/homepage/wp-content/uploads/2022/04/Report_OSIDH_DARTOIS.pdf Isogeny Diffie-Hellman] to +replace ECDH applications, and also provide methods for the key tweaking necessary to support TapScript for P2QR +outputs. Additionally, isogeny-based post-quantum cryptography is based on higher-order elliptic curves, and so it +might be possible to implement Isogeny Schnorr signatures. + +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. Fortunately, SQIsign signatures are substantially faster to verify than it is to generate +keys or to sign, which is a major consideration when a transaction need only be signed once, or a handful of times with +PSBT, compared to being verified simultaneously on tens of thousands of nodes. Key generation may need to be cached in +BIP-32 Hierarchical Deterministic wallets. + +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. + +* 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.