Skip to content

Commit

Permalink
Apply suggestions from code review
Browse files Browse the repository at this point in the history
Co-authored-by: Jon Atack <[email protected]>
cryptoquick and jonatack authored Jan 14, 2025

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
1 parent 0ae69db commit 81e1838
Showing 1 changed file with 12 additions and 12 deletions.
24 changes: 12 additions & 12 deletions bip-0360.mediawiki
Original file line number Diff line number Diff line change
@@ -44,7 +44,7 @@ The vulnerability of existing Bitcoin addresses is investigated in
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.
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
@@ -62,7 +62,7 @@ would be one performed on keys in the mempool, which is seen as much more diffic
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
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.
</ref>
@@ -105,12 +105,12 @@ quantum attack:
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
If the parent private key of an extended public key (xpub) is recovered by a 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
A 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)
@@ -119,8 +119,8 @@ period of time, giving an attacker ample opportunity to break the cryptography.
* 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:
A Short Range 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)
@@ -148,7 +148,7 @@ upgraded by 2030, with browsers and operating systems fully upgraded by 2033. Ac
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.
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 <ref name="hash160">
@@ -242,7 +242,7 @@ its argument. For example:
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
there should be two public keys 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.

=== Address Format ===
@@ -265,12 +265,12 @@ Where:

* <code>OP_PUSHNUM_3</code> (<code>0x03</code>) indicates SegWit version 3.
* <nowiki><hash></nowiki> is the 32-byte HASH256 of the merkle root of a tree of public key hashes, as defined in the
Hash Computation section.
Hash Computation section below.

=== 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
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
@@ -387,7 +387,7 @@ Supported PQC algorithms and their NIST Level V parameters:
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
If 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 ===
@@ -567,7 +567,7 @@ 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
for performance comparison. Fortunately, SQIsign signatures are substantially faster to verify than they are 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.

0 comments on commit 81e1838

Please sign in to comment.