BIP-360: QuBit - P2QRH spending rules #1670
Conversation
There was a problem hiding this comment.
Interesting (the question of resistance to quantum computing may have resurged lately with the publication of https://scottaaronson.blog/?p=8329, see also https://x.com/n1ckler/status/1839215426091249778).
cryptoquick
force-pushed
the
p2qrh
branch
2 times, most recently
from
b6ed2c3 to
d6d15ad
Compare
cryptoquick
force-pushed
the
p2qrh
branch
2 times, most recently
from
0608cc1 to
a595bf0
Compare
cryptoquick
force-pushed
the
p2qrh
branch
2 times, most recently
from
19d4592 to
7f4456d
Compare
|
@cryptoquick Can you begin to write up the sections currently marked as TBD, along with a backwards compatibility section (to describe incompatibilities, severity, and suggest mitigations, where applicable/relevant)? We've begun to reserve a range of BIP numbers for this topic, pending continued progress here. |
jonatack
added
the
PR Author action required
|
@cryptoquick ping for an update here. Have you seen https://groups.google.com/g/bitcoindev/c/p8xz08YTvkw / https://github.com/chucrut/bips/blob/master/bip-xxxx.md? It may be interesting to review each other and possibly collaborate. |
|
@jonatack Why did you re-add the draft designation? From what I understand, @murchandamus recommended that be changed: |
I see. The PR title doesn't refer to the GitHub status of "draft, not ready for review", only that it is a BIP draft as yet without a number -- once there is a number, then the title becomes "BIP <number>: ..." instead. I unified a few titles yesterday to make it easier for me to follow the various PRs. |
|
Are there any remaining obstacles keeping this from getting a BIP number? |
|
I have a range of numbers in mind for QC resistance BIPs to run by the other editors and am re-reviewing here. |
jonatack
changed the title
cryptoquick
force-pushed
the
p2qrh
branch
2 times, most recently
from
9d12258 to
60a3cdc
Compare
|
Sorry for being late, but was any thought been given to the feasibility of cryptographic multisig for the algorithms named? Raccoon has a few threshold signature protocols which can drop in with the originally defined Raccoon (so long as parameters are mutual). https://eprint.iacr.org/2024/1291 This would avoid the on-chain cost of several signatures and provide indistinguishability. |
|
@kayabaNerve This BIP supports multisig. Maybe threshold signatures can be added once they're more mature. |
|
I'm aware of the on-chain multisig possible with this proposal, which would have non-trivial scalability limits. Raccoon was one of the PQ signature algorithms submitted to the NIST competition for additional schemes, alongside SQIsign. It isn't explicitly/inherently a threshold signature and just has threshold signature schemes available. I'd question if it is too immature given the (currently rather) unique benefits provided. |
bip-0360.mediawiki
Outdated
| 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 |
There was a problem hiding this comment.
It seems intuitive that a short range attack would require a more powerful QC than a long range attack, but is this just intuition or is it rooted in actual science? In the former case this text needs more "may"s and "it is believed"s, and in the latter case a link to relevant research.
There was a problem hiding this comment.
Yes, I will add this section:
<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>
Co-authored-by: Vojtěch Strnad <[email protected]>
There was a problem hiding this comment.
Sorry for the many comments. I’m glad that someone is looking into this topic, but it seems to me that there are still many unknowns with the topic, and I’m not sure the proposal is already at a level where it provides sufficient information for anyone to fashion an implementation.
| 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. |
There was a problem hiding this comment.
I’m fairly lost here. The multiple public keys and tree construction seems to be mentioned for the first time here. If there was rationale for this tree construction, I missed it. It’s not clear to me what this tree construction achieves. How many of the public keys can be provided directly in the form of their hashes? When you mention MAST, I assume you mean "Merklized Alternative Script Trees", so one would spend by revealing only a single key from the tree and satisfy its spending conditions? Altogether, this section is hard to follow for me.
There was a problem hiding this comment.
I've tried to add more supporting information. Let me know if that's better.
There was a problem hiding this comment.
I think I’m slowly getting the gist of it, but it might help to cover the abstract idea briefly at a higher level before getting into all the details.
bip-0360.mediawiki
Outdated
| * <code>marker</code>: <code>0x00</code> (same as SegWit) | ||
| * <code>flag</code>: <code>0x02</code> (indicates the presence of both witness and attestation data) |
There was a problem hiding this comment.
Should the flag not be considered a boolean array? 0x01 for witness, 0x02 for attestation, 0x03 for witness and attestation? Is it possible for an attestation to appear without a witness section?
There was a problem hiding this comment.
I've considered this, and yes, it might make sense if we've completely transitioned away from classical cryptography. I'll be sure to factor that in.
| * <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 | ||
| quantum-resistant algorithms. |
There was a problem hiding this comment.
I haven’t thought a lot about this, but given the goal of extensibility, it might be good to add a byte to indicate a signature type for more flexibility?
There was a problem hiding this comment.
As I go into in the Signature Algorithm Identification section, we just use the length of the key and signature to indicate signature type. If there's overlap, an extra byte is added.
| 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. |
There was a problem hiding this comment.
For a multisignature scheme, would you need to reveal multiple leafs from the pubkey tree? From what I understood the tree can only hold public keys, not scripts. How then is the threshold communicated? Wouldn’t a spender be able to reveal only their own key and provide a signature for that?
There was a problem hiding this comment.
That's a good point. Does that need to be committed to in the output or just expressed in the attestation?
There was a problem hiding this comment.
If it’s not committed to in advance, you are building either a 1-of-n or a 0-of-n scheme, depending on the minimum value for the threshold.
There was a problem hiding this comment.
That makes sense. So, we essentially need to commit to a script hash. I'm thinking we just do a bunch of consecutive data pushes of PKHs and they correspond to leaves on a binary tree. This is then included in the witness. Keys in the attestation are hashed and compared to the PKHs in the v3 witness. Like this:
OP_3
OP_PUSHBYTES_32
d81fd577272bbe73308c93009eec5dc9fc319fc1ee2e7066e17220a5d47a1a5
OP_PUSHBYTES_32
8314578be2faea34b9f1f8ca078f8621acd4bc22897b03daa422b9bf56646b3
OP_PUSHBYTES_32
ec3afff0b2b66e8152e9018fe3be3fc92b30bf886b3487a525997d00fd9dae1
OP_PUSHBYTES_32
2d012dce5d5275854adc3106572a5d1e12d4211b228429f5a7b2f7ba92eb047
OP_PUSHBYTES_32
b49b496684b02855bc32f5daefa2e2e406db4418f3b86bca5195600951c7db9
OP_5
OP_CHECKMULTISIG
Notice, all 5 PKHs need to be committed to in advance in the script hash. Maybe we need to introduce a concept like QPKH? QuBit public key hash? And QSH for script hashes? Or would APKH / ASH be better, for attestation?
What do you think? This I think will obviate the necessity for a merkle tree, as recommended by @EthanHeilman. If 3 public keys aren't included and don't hash to any of the public keys in the script hash, then the transaction fails.
There was a problem hiding this comment.
After going over the editor checklist, I’m not sure why the term "QuBit" is introduced.
Altogether, it feels like Motivation and Rationale are giving a very broad overview of the topic, straying maybe a bit too far for a document describing "Spending Rules". Perhaps the document could be more concise in several sections, and the corresponding information could be provided outside of the BIP and just linked, or moved to the footnotes.
| 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. |
There was a problem hiding this comment.
Is the intention to make a group of several BIPs that are intended to be activated together like SegWit? Otherwise I’m not sure whether I get the purpose of introducing the term "QuBit" here.
There was a problem hiding this comment.
That is the idea, yes. QuBit is the name of the soft fork, similar to SegWit and Taproot.
|
@murchandamus @vostrnad Thank you for taking the time to review. I realize this is a long BIP and there's a lot to go over, but I think it's important as the first quantum BIP to go into the problem in detail. In that way it's similar to BIP-52. Regardless, I've made updates to satisfy your recommendations the best I can, here's a diff for your convenience: For context, I also intend to introduce a QuBit activation BIP, and a P2TRH BIP separate from QuBit. Additionally, I realize that there's some sections here that are underspecified. That will come with test vectors and an implementation, which I'm working towards. |
| believed to need 10^8 operations to break a 256-bit elliptic curve public key.</ref>, 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'']. |
There was a problem hiding this comment.
Collaboration nit: Please don’t reformat a paragraph when you change just a couple words. Keep the line breaks at the same place to make it easier to spot the changes:
It’s much easier to review
believed to need 10^8 operations to break a 256-bit elliptic curve public key.</ref>, allowing the derivation of private
-keys from public keys—a process referred to as quantum key decryption. Importantly, simply increasing the public key
+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''
+[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''].than
-believed to need 10^8 operations to break a 256-bit elliptic curve public key.</ref>, allowing the derivation of private
-keys from public keys—a process referred to as quantum key decryption. Importantly, simply increasing 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''].
+believed to need 10^8 operations to break a 256-bit elliptic curve public key.</ref>, 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''].because all the linebreaks were readjusted after the "private" at the end of the first line was moved to the second line.
| h1 = HASH256(pubkey1) | ||
| h2 = HASH256(pubkey2) | ||
| h3 = HASH256(pubkey3) | ||
| h4 = HASH256(pubkey4) |
There was a problem hiding this comment.
Have you considered making this tagged hashes to mitigate some of the general issues with Satoshi-style merkle trees?
There was a problem hiding this comment.
I have not. I'm not familiar with the problem with Satoshi-style merkle trees. Wouldn't tagged hashes require additional data?
| 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. |
There was a problem hiding this comment.
I think I’m slowly getting the gist of it, but it might help to cover the abstract idea briefly at a higher level before getting into all the details.
Co-authored-by: Mark "Murch" Erhardt <[email protected]>
This spent several months gathering feedback from the mailing list and from other advisors. This is hopefully polished enough to submit upstream.
Let me know if you have any questions or feedback, and of course feel free to submit suggestions.
Thank you for your time.