BIP-360: QuBit - Pay to Quantum Resistant Hash #1670

cryptoquick · 2024-09-27T16:08:30Z

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.

… to bitcoin/bips

bip-p2qrh.mediawiki

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

bip-p2qrh.mediawiki

jonatack · 2024-10-01T18:09:31Z

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

typo fix

jonatack · 2024-10-21T15:27:42Z

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

kayabaNerve · 2024-12-19T07:41:33Z

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
https://eprint.iacr.org/2024/184
https://eprint.iacr.org/2024/496

This would avoid the on-chain cost of several signatures and provide indistinguishability.

cryptoquick · 2024-12-19T13:32:35Z

@kayabaNerve This BIP supports multisig. Maybe threshold signatures can be added once they're more mature.

kayabaNerve · 2024-12-19T14:37:52Z

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

vostrnad · 2024-12-19T23:13:42Z

bip-0360.mediawiki

+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


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.

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>

bip-0360.mediawiki

Co-authored-by: Vojtěch Strnad <43024885+vostrnad@users.noreply.github.com>

murchandamus

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.

bip-p2qrh.mediawiki

murchandamus · 2024-12-20T21:08:48Z

bip-0360.mediawiki

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


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.

I've tried to add more supporting information. Let me know if that's better.

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.

BIP114 is also named "MAST" (Merkelized Abstract Syntax Trees), so perhaps write out the MAST you are referring to here.

murchandamus · 2024-12-20T21:10:33Z

bip-0360.mediawiki

+
+* <code>marker</code>: <code>0x00</code> (same as SegWit)
+
+* <code>flag</code>: <code>0x02</code> (indicates the presence of both witness and attestation data)


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?

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.

murchandamus · 2024-12-20T21:12:24Z

bip-0360.mediawiki

+* <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.


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?

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.

murchandamus · 2024-12-20T21:14:25Z

bip-0360.mediawiki

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


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?

That's a good point. Does that need to be committed to in the output or just expressed in the attestation?

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.

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.

bip-0360.mediawiki

murchandamus

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.

bip-0360.mediawiki

murchandamus · 2024-12-20T21:36:10Z

bip-0360.mediawiki

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


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.

That is the idea, yes. QuBit is the name of the soft fork, similar to SegWit and Taproot.

bip-0360.mediawiki

cryptoquick · 2024-12-20T23:20:33Z

@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:
0fdd8c3

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.

murchandamus

Just a few quick responses to the edits

bip-0360.mediawiki

murchandamus · 2024-12-23T20:52:07Z

bip-0360.mediawiki

+  h1 = HASH256(pubkey1)
+  h2 = HASH256(pubkey2)
+  h3 = HASH256(pubkey3)
+  h4 = HASH256(pubkey4)


Have you considered making this tagged hashes to mitigate some of the general issues with Satoshi-style merkle trees?

I have not. I'm not familiar with the problem with Satoshi-style merkle trees. Wouldn't tagged hashes require additional data?

No, they’re the same cost, you just prefix the hashing process with the tag. The advantage is that it prevents any collisions or hashing the same things at different levels of the tree in different contexts. They could for example be used to disambiguate the different types of cryptographic schemes on the public key commitment level for free, or for distinguishing public key hashes from inner node hashes. I’m not sure they’re necessary here, but they clean-up a whole category of issues, so they might be useful.

That makes sense. That might be a good idea, if we are using Merkle trees.

murchandamus · 2024-12-23T20:53:54Z

bip-0360.mediawiki

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


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

murchandamus

This is all that I have at this time from an editorial standpoint.It would be good if this proposal got more feedback and/or endorsements from domain experts in the next steps.

murchandamus · 2024-12-26T17:10:01Z

bip-0360.mediawiki

+  h1 = HASH256(pubkey1)
+  h2 = HASH256(pubkey2)
+  h3 = HASH256(pubkey3)
+  h4 = HASH256(pubkey4)


No, they’re the same cost, you just prefix the hashing process with the tag. The advantage is that it prevents any collisions or hashing the same things at different levels of the tree in different contexts. They could for example be used to disambiguate the different types of cryptographic schemes on the public key commitment level for free, or for distinguishing public key hashes from inner node hashes. I’m not sure they’re necessary here, but they clean-up a whole category of issues, so they might be useful.

mraksoll4 · 2024-12-30T17:52:32Z

the main problem that I see is decryptor wallets, as well as a master private key and a master public key, curves allow us to use something like this, but post-quantum algorithms do not provide such an opportunity (in current implementations)

if use clasic logic with key pool , we simple get key pairs and use them

but how are we going to associate a key obtained from master keys with post quantum keys?

cryptoquick · 2025-01-01T05:06:32Z

@mraksoll4 All PQC algos will of course need to be compatible with BIP-32 HD wallet-style key derivation. There are definitely PQC libraries out there that just assume you'll never want to bring your own entropy, and so they don't provide a field or argument to provide that, but the intention behind the implementation of this BIP is that there will be a custom PQC library for bitcoin specifically that will implement things like this. So, your concern, while valid, is an implementation detail, and doesn't really have much bearing on the BIP itself.

mraksoll4 · 2025-01-01T16:22:04Z

@mraksoll4 All PQC algos will of course need to be compatible with BIP-32 HD wallet-style key derivation. There are definitely PQC libraries out there that just assume you'll never want to bring your own entropy, and so they don't provide a field or argument to provide that, but the intention behind the implementation of this BIP is that there will be a custom PQC library for bitcoin specifically that will implement things like this. So, your concern, while valid, is an implementation detail, and doesn't really have much bearing on the BIP itself.

Well, we have no problems with private keys, and also with generating from a seed, I have already implemented for experiments on the liboqs library the use of my own seed for falcon and dilithium to obtain a pair of keys, as well as obtaining a public key from a private one.

There are also no problems with multi-signature, the signature itself can be merged.

but we have a problem with obtaining public keys from the master public key ; due to the design of post quantum algorithms, we do not have the ability to obtain public keys from other public keys through predictable mathematical operations as in ecdsa.

although perhaps I don’t fully understand how we get the master public key.

how start you can see at base examle .

open-quantum-safe/liboqs#2031

first we need to solve the problem of key hierarchy, or we will have to forget about generating public keys without cration the private key, although for example in Falcon you don't need the entire private key but only part of it to reconstruct the public key


/*
 * This function reconstructs the public key from a given private key.
 * It decodes the private key components (f and g) from the secret key
 * and uses them to regenerate the corresponding public key (h).
 * The generated public key is then encoded into the provided pk array.
 * 
 * public (pk):  The output buffer where the public key will be stored (must be at least PQCLEAN_FALCON512_CLEAN_CRYPTO_PUBLICKEYBYTES in size).
 * private (sk):  The input secret key (private key) in byte array format (must be PQCLEAN_FALCON512_CLEAN_CRYPTO_SECRETKEYBYTES in size).
 * Return value: 0 on success, -1 on error.
 */
int 
PQCLEAN_FALCON1024_CLEAN_crypto_sign_pubkey_from_privkey(
    uint8_t *pk, const uint8_t *sk) {
    union {
        uint8_t b[FALCON_KEYGEN_TEMP_10];
        uint64_t dummy_u64;
        fpr dummy_fpr;
    } tmp;
    int8_t f[1024], g[1024], F[1024];
    uint16_t h[1024];
    size_t u, v;

    /*
     * Decode the private key.
     */
    if (sk[0] != 0x50 + 10) {
        return -1;
    }
    u = 1;
    v = PQCLEAN_FALCON1024_CLEAN_trim_i8_decode(
            f, 10, PQCLEAN_FALCON1024_CLEAN_max_fg_bits[10],
            sk + u, PQCLEAN_FALCON1024_CLEAN_CRYPTO_SECRETKEYBYTES - u);
    if (v == 0) {
        return -1;
    }
    u += v;
    v = PQCLEAN_FALCON1024_CLEAN_trim_i8_decode(
            g, 10, PQCLEAN_FALCON1024_CLEAN_max_fg_bits[10],
            sk + u, PQCLEAN_FALCON1024_CLEAN_CRYPTO_SECRETKEYBYTES - u);
    if (v == 0) {
        return -1;
    }

    /*
     * Reconstruct the public key using f and g by calling the compute_public function.
     */
    if (!PQCLEAN_FALCON1024_CLEAN_compute_public(h, f, g, 10, tmp.b)) {
        return -1;
    }

    /*
     * Encode public key.
     */
    pk[0] = 0x00 + 10;
    v = PQCLEAN_FALCON1024_CLEAN_modq_encode(
            pk + 1, PQCLEAN_FALCON1024_CLEAN_CRYPTO_PUBLICKEYBYTES - 1,
            h, 10);
    if (v != PQCLEAN_FALCON1024_CLEAN_CRYPTO_PUBLICKEYBYTES - 1) {
        return -1;
    }

    return 0;
}

jonatack

Did another review pass. Updated the PR title, as it looks like the BIP is now named "Pay to Quantum Resistant Hash."

Have you read the mail list discussion at https://groups.google.com/g/bitcoindev/c/8O857bRSVV8? It might be good to weigh in there if you're inclined.

Most important of the comments below: #1670 (comment) and #1670 (comment).

jonatack · 2025-01-02T22:34:22Z

bip-0360.mediawiki

+
+The vulnerability of existing Bitcoin addresses is investigated in
+[https://web.archive.org/web/20240715101040/https://www2.deloitte.com/nl/nl/pages/innovatie/artikelen/quantum-computers-
+and-the-bitcoin-blockchain.html this Deloitte report]. The report estimates that in 2020 approximately 25% of the


nit, let's avoid a line break in the url here, and s/estimates/estimated/

-[https://web.archive.org/web/20240715101040/https://www2.deloitte.com/nl/nl/pages/innovatie/artikelen/quantum-computers- -and-the-bitcoin-blockchain.html this Deloitte report]. The report estimates that in 2020 approximately 25% of the +[https://web.archive.org/web/20240715101040/https://www2.deloitte.com/nl/nl/pages/innovatie/artikelen/quantum-computers-and-the-bitcoin-blockchain.html this Deloitte report]. The report estimated that in 2020 approximately 25% of the

jonatack · 2025-01-02T22:41:09Z

bip-0360.mediawiki

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


Suggested change

even more might be vulnerable.

even more addresses might be vulnerable, representing 5M to 10M bitcoin.

jonatack · 2025-01-02T22:48:39Z

bip-0360.mediawiki

+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


Suggested change

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

jonatack · 2025-01-02T22:54:00Z

bip-0360.mediawiki

+|-
+| P2WPKH || No¹ || bc1q || bc1qsnh5ktku9ztqeqfr89yrqjd05eh58nah884mku
+|-
+| P2WSH || No¹ || bc1q || bc1qvhu3557twysq2ldn6dut6rmaj3qk04p60h9l79wk4lzgy0ca8mfsnffz65


ISTM all of the No¹ entries ought to be Yes¹ or If revealed¹...

jonatack · 2025-01-02T22:56:08Z

bip-0360.mediawiki

+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


Suggested change

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

jonatack · 2025-01-03T01:16:01Z

bip-0360.mediawiki

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


BIP114 is also named "MAST" (Merkelized Abstract Syntax Trees), so perhaps write out the MAST you are referring to here.

jonatack · 2025-01-03T01:18:29Z

bip-0360.mediawiki

+
+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


Suggested change

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

jonatack · 2025-01-03T01:26:04Z

bip-0360.mediawiki

+
+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


Suggested change

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

jonatack · 2025-01-03T01:30:15Z

bip-0360.mediawiki

+|-
+| [https://eprint.iacr.org/2011/191.pdf Winternitz signature] || 1982 || 2,368 bytes<ref name="winternitz">Winternitz
+signatures are much smaller than Lamport signatures due to efficient chunking, but computation is much higher,
+especially with high values for w. Winternitz values are for w of 4.</ref> || 2,368 bytes || Hash-based cryptography


Should the caveat and consequences be mentioned here that Winternitz signatures are one-time?

jonatack · 2025-01-03T01:33:00Z

bip-0360.mediawiki

+
+== Test Vectors and Reference Code ==
+
+TBD


Any timeline for adding these?

First, it is necessary to solve a rather simple and complex problem: key structure tree of priv and pub keys. Since in post-quantum algorithms there are not even approximate solutions, possible it will be universal since almost all of them are built on lattices

Well, what’s important is that we only have a problem with generating public keys from a master public key or xpub, there are no problems with private keys, in almost any algorithm you can feed a seed to get a pair of keys and, as in the example above, reconstruct the public key from part of the private one.

cryptoquick added 2 commits September 27, 2024 10:05

QuBit - P2QRH spending rules - Final draft before submitting upstream…

1fa2485

… to bitcoin/bips

Add pqNTRUsign to .typos.toml.

6f67a3d

cryptoquick marked this pull request as draft September 27, 2024 18:18

EthanHeilman reviewed Sep 27, 2024

View reviewed changes

bip-p2qrh.mediawiki Outdated Show resolved Hide resolved

EthanHeilman reviewed Sep 27, 2024

View reviewed changes

bip-p2qrh.mediawiki Outdated Show resolved Hide resolved

EthanHeilman reviewed Sep 27, 2024

View reviewed changes

bip-p2qrh.mediawiki Outdated Show resolved Hide resolved

jonatack added the New BIP label Sep 27, 2024

jonatack reviewed Sep 27, 2024

View reviewed changes

bip-p2qrh.mediawiki Outdated Show resolved Hide resolved

cryptoquick force-pushed the p2qrh branch 2 times, most recently from b6ed2c3 to d6d15ad Compare September 28, 2024 18:01

kingcathy23 approved these changes Sep 28, 2024

View reviewed changes

cryptoquick force-pushed the p2qrh branch 2 times, most recently from 0608cc1 to a595bf0 Compare September 28, 2024 18:12

cryptoquick requested review from jonatack and EthanHeilman September 28, 2024 18:55

cryptoquick force-pushed the p2qrh branch from a595bf0 to eae4707 Compare September 29, 2024 07:22

luisschwab mentioned this pull request Sep 29, 2024

Tópicos Out/24 BitDevsBSB/BitDevsBSB#11

Closed

cryptoquick force-pushed the p2qrh branch 2 times, most recently from 19d4592 to 7f4456d Compare September 30, 2024 11:42

jonatack reviewed Sep 30, 2024

View reviewed changes

bip-p2qrh.mediawiki Outdated Show resolved Hide resolved

QuBit - P2QRH

d83c29d

cryptoquick force-pushed the p2qrh branch from 7f4456d to d83c29d Compare October 1, 2024 01:03

jlopp and others added 2 commits October 2, 2024 10:30

typo fix

ae0936a

Merge pull request #13 from jlopp/patch-3

d89b7c5

typo fix

jonatack added the PR Author action required Needs updates, has unaddressed review comments, or is otherwise waiting for PR author label Oct 9, 2024

luisschwab mentioned this pull request Oct 14, 2024

Novembro 2024 saopaulobitdevs/saopaulobitdevs.org#38

Closed

QuBit - P2QRH spending rules

b4c329b

cryptoquick force-pushed the p2qrh branch from a3af198 to b4c329b Compare October 21, 2024 17:39

cryptoquick force-pushed the p2qrh branch 2 times, most recently from 9d12258 to 60a3cdc Compare December 18, 2024 21:48

P2QRH assigned BIP number 360.

85348c0

cryptoquick force-pushed the p2qrh branch from 60a3cdc to 85348c0 Compare December 18, 2024 21:49

cryptoquick requested a review from jonatack December 18, 2024 23:05

sootisooti mentioned this pull request Dec 19, 2024

Write chapter to analyze what a quantum safe / emergency quantum break fork might look like bitcoin-cap/bcap#58

Open

vostrnad reviewed Dec 19, 2024

View reviewed changes

cryptoquick and others added 3 commits December 20, 2024 10:08

Apply suggestions from code review

a4f3dc6

Co-authored-by: Vojtěch Strnad <43024885+vostrnad@users.noreply.github.com>

Address feedback from vostrnad.

2b641b8

Update typos list.

4b8b647

cryptoquick requested a review from vostrnad December 20, 2024 19:52

Fixes, typos, formatting.

990d8a8

murchandamus reviewed Dec 20, 2024

View reviewed changes

cryptoquick added 2 commits December 20, 2024 16:12

Updates based on Murch and vostrnad feedback.

0fdd8c3

Fix title change in README.

208a987

murchandamus reviewed Dec 23, 2024

View reviewed changes

cryptoquick and others added 3 commits December 23, 2024 15:22

Apply suggestions from code review

8eb35c8

Co-authored-by: Mark "Murch" Erhardt <murch@murch.one>

Fix broken link.

d9bb0ff

Remove Canary section.

0ae69db

murchandamus reviewed Dec 26, 2024

View reviewed changes

jonatack reviewed Jan 3, 2025

View reviewed changes

jonatack changed the title ~~BIP-360: QuBit - P2QRH spending rules~~ BIP-360: QuBit - Pay to Quantum Resistant Hash Jan 3, 2025


		* <code>marker</code>: <code>0x00</code> (same as SegWit)

		* <code>flag</code>: <code>0x02</code> (indicates the presence of both witness and attestation data)

		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.

	even more might be vulnerable.
	even more addresses might be vulnerable, representing 5M to 10M bitcoin.

	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

	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


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

	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

BIP-360: QuBit - Pay to Quantum Resistant Hash #1670

Are you sure you want to change the base?

BIP-360: QuBit - Pay to Quantum Resistant Hash #1670

Conversation

cryptoquick commented Sep 27, 2024

jonatack left a comment • edited Loading

Choose a reason for hiding this comment

jonatack commented Oct 1, 2024 • edited Loading

jonatack commented Oct 21, 2024

kayabaNerve commented Dec 19, 2024 • edited Loading

cryptoquick commented Dec 19, 2024

kayabaNerve commented Dec 19, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

murchandamus left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cryptoquick Dec 23, 2024 • edited Loading

Choose a reason for hiding this comment

murchandamus left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cryptoquick commented Dec 20, 2024 • edited Loading

murchandamus left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

murchandamus left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mraksoll4 commented Dec 30, 2024

cryptoquick commented Jan 1, 2025

mraksoll4 commented Jan 1, 2025 • edited Loading

jonatack left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jonatack Jan 3, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jonatack left a comment •

edited

Loading

jonatack commented Oct 1, 2024 •

edited

Loading

kayabaNerve commented Dec 19, 2024 •

edited

Loading

cryptoquick Dec 23, 2024 •

edited

Loading

cryptoquick commented Dec 20, 2024 •

edited

Loading

murchandamus left a comment •

edited

Loading

mraksoll4 commented Jan 1, 2025 •

edited

Loading

jonatack left a comment •

edited

Loading

jonatack Jan 3, 2025 •

edited

Loading