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. |
|
Hi, Sorry for the ping, This is too complicated for me. Is there no way to simplify or generalize this? |
|
Yesterday, we pushed it with a simplified and holistic version. |
Perhaps a good summary is this: In this BIP we suggest a new address format beginning with bc1r that introduces the capability for users to generate addresses that can receive payments signed using quantum-resistant keys and signatures. It really is that simple, but there are the details for why this needs to happen and how it should happen and this tries to cover those in a comprehensive enough manner, or at least, as comprehensive as we can be without test vectors. |
jonatack
changed the title
|
@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.
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.
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. |
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.