BIP-360: QuBit - Pay to Quantum Resistant Hash

[cryptoquick]

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.

[jonatack]

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).

[jonatack]

@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]

@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.

[katesalazar]

do you recommend I also submit P2TRH to BIPs?

@cryptoquick know your peer... I've done few and casual administrivia and cleaning up here and there, but I don't understand cryptography or other advanced math by myself, and not sure I can even. Therefore I don't comment on BIP content, often not even on BIP structure and style.

[mark-nesbitt]

@cryptoquick I really appreciate this BIP -- I learned about it from the Bitcoin Season 2 podcast you did.

I read the BIP and still need to digest it, but I'm trying to summarize the proposal. Would you say this is accurate:

This BIP introduces a new address type that supports quantum resistant public keys. Because new ciphers are at significantly greater risk of being broken, a single address can require multiple public keys. The user can construct an address using 3 types of QR public keys and a standard, non-QR resistant ECDSA pubkey. The user can define a multisig construction such that only a subset of these keys need provide a digital signature in order to spend the output. For those only concerned with security against quantum computers, the most logical construction would be a 4/4 multsig with keys of each of the 4 pubkey types.

EDIT: Updated the above language to capture multisig component.

This raised a question in my mind. Have you considered eliminating the additional complexity required to support multisig? Perhaps it would be a simpler, cleaner BIP to address one and only one need: quantum resistance. The end user can choose 1,2,3 or 4 pub keys, 1 of each type, and there must be n/n signatures to spend.

I'm supposing that the answer is "QR multisig is a valid use case -- we why not support it?" I think that's totally valid, but was just wondering if those were your thoughts and whether you think there's value in the simplicity gains from eliminating the need for multisig.

[cryptoquick]

@mark-nesbitt
Your summary is fine.

A merkle tree is still needed to support multiple kinds of keys. The only differences are that multisig will require some multisig specific bytes committed to in the address hash and revealed in the attestation, and hashes will be supported in a sparse merkle tree. I think it's important we still preserve the use case of multisig to support self-custody and L2s.

[tsusanka]

Is there any reason why this is based on SegWit's BIP-0143 instead of Taproot which brought some reasonable changes? See https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#signature-validation-rules

[cryptoquick]

That's a good catch, I hadn't thought of that. I'll get that updated.

[cryptoquick]

I just pushed some updates. They can be found here:
https://github.com/cryptoquick/bips/pull/19/files?short_path=e296d32#diff-e296d32a8f60ef9f846683e801718d16c41fa7d8f1065e0afa6405a0764a91e3

I appreciate everyone's feedback so far. There have been nearly 300 comments on this pull request, which is great and I won't complain about the attention. Lots of feedback has been helpful, including about the multisig merkle tree hashing mechanism and the suggestion to use NIST I cryptography as NIST V has repeatedly been deemed overkill. Additionally, some oversights around sighash flags and Taproot compatibility were addressed.

BIP-360 is not the perfect solution, and it never was supposed to be. It is, however, the best compromise between various technical requirements I can come up with, and I hope that the technical decisions made are sensible when viewed in combination. As the first BIP to address quantum security, I intend it to be the most mature and conservative solution to the problem.

I hope now I've addressed all the holes present in the design. My next steps are to build the test vectors json using a fork of rust-bitcoin, which I will call rust-bitcoin-pqc. I will also be making a library called libbitcoinpqc, written in C but with Rust bindings included, and eventually I will integrate these into a fork of BDK I will call QBDK.

[jonatack]

@cryptoquick I re-read through the review feedback of the past four months, but it is difficult and laborious to try to understand what you did to concretely address each comment.

Would you please indicate in response to each comment the link to the commit patch with the relevant change you made, and particular for the review feedback from @jonasnick and @vostrnad above?

There is also review feedback marked as resolved, but without a reply. Please help reviewers connect the dots :)

Those pointers would be very helpful, I think, in determining what was done and/or remains to be done in response, and would aid review.

[cryptoquick]

@jonatack Thank you for the advice! I went back and did my best to provide some links to the relevant changes. Hope that helps.

Also, I've made a note to address this concern I overlooked:

https://github.com/bitcoin/bips/pull/1670/files#r1994349769

I'd appreciate any thoughts you have on that. Thanks!

[cryptoquick]

In the above changeset I rethought how we do the SegWit v3 scriptPubKey hash commitment... I think the merkle tree is nonsense at this point, since it cannot be sparse because all public key hashes must be known in advance in order to compute a complete commitment. Even in selective disclosure, all hashes have to be provided. @EthanHeilman originally suggested the merkle tree to me, so maybe there's something I'm missing, but for now I'm going back to concatenated hashes. Hopefully this simplifies the BIP a bit, also.

I also made sure we're more declarative of keytypes and thresholds in the attestation because bytes there will be cheap, especially if there's an increased attestation discount. The reason the attestation exists is because it can be discounted separately and its functionality limited to fixed signature operations.

[cryptoquick]

In the above changeset I also updated the descriptor format to show a more complete example of how I expect selectively disclosed threshold multisigs to work.

[QbitsCode]

Is there somethin in a horizon, how can we reflect the current progression in percent. A clarfication meeting was requested to accelerate finalizing pqcBitcoin but no feedback.

[cryptoquick]

@QbitsCode A community call isn't a bad idea. If there is one, we'll most likely announce it in our Telegram group.

[murchandamus]

People appear to agree conceptually that we should be looking into PQ, but skimming the conversation on this PR, I must admit that I am a bit concerned regarding the seeming lack of approach buy-in.

There seem to be concerns about e.g., introducing too many different PQ Signature schemes introducing unnecessary complexity, the resulting scheme dropping support for existing features, and uncertainty about the properties of the attestation structure's properties. It also seems to me that it is not clear to me what the priority is:
If this is developing an emergency PQ-response that might be deployed on short notice, it would seem that going for less complexity would be fruiltful. If we are going for a fully-fledged, comprehensive response to PQ, it should e.g., not gratuitously drop support for scripting in outputs—don’t we still want HTLCs in a PQ future?

While you are reconsidering the structure of the attestation, perhaps it would be good to take another step back and collect more input on the big picture design goals before jumping back into the tweaking details of another variant of the same approach.

[cryptoquick]

Thanks for chiming in once more, Murch.

There seem to be concerns about e.g., introducing too many different PQ Signature schemes introducing unnecessary complexity

You have good timing with this, since I just published libbitcoinpqc, which should be a one-stop shop focal point for PQC needed for BIP-360, similar to how libsecp256k1 was for BIP-340. You can check out that work here:
https://github.com/cryptoquick/libbitcoinpqc

The algorithmic complexity shouldn't be so bad now that it's abstracted in a useful way.

If we are going for a fully-fledged, comprehensive response to PQ, it should e.g., not gratuitously drop support for scripting in outputs—don’t we still want HTLCs in a PQ future?

I'm not dropping support for witness scripts. The attestation is just like putting additional locks on coins in an address, in addition to whatever is expected to happen in the witness. I expect this to be compatible with a lot that's already been developed for Lightning and Taproot. I would like to verify that in practice however. A good start to that would be post quantum-flavored versions of rust-bitcoin, BDK, and LDK.

While you are reconsidering the structure of the attestation, perhaps it would be good to take another step back and collect more input on the big picture design goals before jumping back into the tweaking details of another variant of the same approach.

Perhaps, but another alternative is to put the work needed into proving out this design. There's too many variables to consider without something concrete to work from and think about. I'm definitely willing to do that in order to prove that BIP-360 works in various scenarios.

[jonasnick]

Did you mean to refer to BIP 341 here?

[mraksoll4]

the idea itself is quite simple, we have a separate address, a separate storage of keys, a double signature. In the case of old wallets ignore the new pq signature when verify, new ones read both.

but we will most likely have to forgot about derevation logic in new address type atleast for now, yes it will make the wallet file thicker, and the blockchain will become thicker. But it will provide additional security, also do not forget that unlike the same ETH, Bitcoin blockchain can be kept on HDD without problems and pruned, when ETH only requires super fast SSD.. and there pq signatures will be real problem.

[jonatack]

@cryptoquick any update here?

[cryptoquick]

@jonatack I'm waiting for Ethan to finish his rewrite before adding new changes. Please bear with us, the wait will be worth it!