Address feedback from vostrnad.

bip-0360.mediawiki

@@ -60,31 +60,45 @@ the key behind high-value addresses. A long-range quantum attack can be consider
 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. 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.
+requires more sophisticated CRQCs.<ref name="short-range">
+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.
+</ref>
+
+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) address type that relies on a PQC signature
 algorithm. This new address 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 non-exhaustive but intended to inform the average Bitcoin user whether their bitcoin is
-vulnerable to a long-range quantum attack:
+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 || 04 ||
-0496b538e853519c726a2c91e61ec11600ae1390813a627c66fb8be7947be63c52da7589379515d4e0a604f8141781e62294721166bf621e73a82cbf
-2342c858ee
+| P2PK || Yes || Varies || 2103203b768951584fe9af6d9d9e6ff26a5f76e453212f19ba163774182ab8057f3eac
 |-
 | P2PKH || No || 1 || 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa
 |-
+| P2MS || Yes || Varies || 52410496ec45f878b62c46c4be8e336dff7cc58df9b502178cc240e...
+|-
+| P2SH || No || 5 || 3FkhZo7sGNue153xhgqPBcUaBsYvJW6tTx
+|-
 | P2WPKH || No || bc1q || bc1qsnh5ktku9ztqeqfr89yrqjd05eh58nah884mku
 |-
+| P2WSH || No || bc1q || bc1qvhu3557twysq2ldn6dut6rmaj3qk04p60h9l79wk4lzgy0ca8mfsnffz65
+|-
 | P2TR || Yes || bc1p || bc1p92aslsnseq786wxfk3ekra90ds9ku47qttupfjsqmmj4z82xdq4q3rr58u
+|-
+| P2QRH || No || bc1r || bc1r8rt68aze8tek87cnz4ndnvfzk6tk93jv39n4lmpu5a4yw453rcpszsft3z
 |}
 
 It should be noted that Taproot outputs are vulnerable in that they encode a 32-byte x-only public key, from which a
@@ -113,14 +127,13 @@ Short-range attacks require much larger, more expensive CRQCs since they must be
 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.
 
-Should quantum advantage manifest, a convention is proposed in spending the full 65-byte P2PK key used by the coinbase
-output in Block 1 back to itself. It is proposed to call the address in Block 1 the
+Should quantum advantage manifest, a convention is proposed in spending the 65-byte P2PK output used by the coinbase
+output in Block 1. It is proposed to call the address in Block 1 the
 [https://mempool.space/address/0496b538e853519c726a2c91e61ec11600ae1390813a627c66fb8be7947be63c52da7589379515d4e0a604f81
-41781e62294721166bf621e73a82cbf2342c858ee
-Canary address] since it can only be spent from by others (assuming Satoshi's continued absence) if secp256k1 is
-broken. Should the Canary coins move, that will signal that reliance on secp256k1 is presently vulnerable. Without the
-Canary, or an address like it, there may be some doubt as to whether the coins were moved with keys belonging to the
-original owner.
+41781e62294721166bf621e73a82cbf2342c858ee Canary address] since it can only be spent from by others (assuming Satoshi's
+ continued absence) if secp256k1 is broken. Should the Canary coins move, that will signal that reliance on secp256k1
+is presently vulnerable. Without the Canary, or an address like it, there may be some doubt as to whether the coins were
+moved with keys belonging to the original owner.
 
 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
@@ -156,8 +169,7 @@ This is the first in a series of BIPs under a QuBit soft fork. A qubit is a fund
 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 (similar to how bc1q corresponds to Se(q)Wit and bc1p corresponds
-to Ta(p)root). This is referencing the lookup table under
+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].
 
 The proposal above also leaves a gap in case it makes sense to use version 2, or bc1z, for implementation of other
@@ -169,11 +181,9 @@ should a vulnerability exist in one of the signature algorithms used. One key di
 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, which is similar to that used in
-[https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki#specification BIP-16]) 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. It goes into the output spend script, which does not receive the
-witness discount.
+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. It goes into the scriptPubKey, which does not receive the witness 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
@@ -316,20 +326,21 @@ Following BIP-141, a new transaction serialization format is introduced to inclu
 
 The attestation field consists of:
 
-* <code>num_pubkeys</code>: The number of public keys (VarInt encoded).
+* <code>num_pubkeys</code>: The number of public keys
+([https://learnmeabitcoin.com/technical/general/compact-size/ compact size]).
 
 For each public key:
 
-* <code>pubkey_length</code>: VarInt encoded length of the public key.
+* <code>pubkey_length</code>: compact size length of the public key.
 * <code>pubkey</code>: The public key bytes.
 
 Then:
 
-* <code>num_signatures</code>: The number of signatures (VarInt encoded).
+* <code>num_signatures</code>: The number of signatures (compact size).
 
 For each signature:
 
-* <code>signature_length</code>: VarInt encoded length of the signature.
+* <code>signature_length</code>: compact size length of the signature.
 * <code>signature</code>: The signature bytes.
 
 This structure repeats for each input, in order, for flexibility in supporting multisig schemes and various
@@ -573,6 +584,7 @@ seeds to act as the authoritative secret when signing. These measures are deemed
 
 To help implementors understand updates to this BIP, we keep a list of substantial changes.
 
+* 2024-12-20 - Address feedback from vostrnad.
 * 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-06 - Update title and formatting.
@@ -593,4 +605,4 @@ 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, and Murchandamus.
+Dallaire-Demers, Ethan Heilman, Jon Atack, Jameson Lopp, Murchandamus, and Vojtěch Strnad.