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.

jonasnick · 2025-03-24T14:28:50Z

bip-0360.mediawiki

+This design maintains compatibility for [https://github.com/bitcoin/bips/blob/master/bip-0114.mediawiki BIP-114]
+Taproot Merkelized Alternative Script Tree (MAST) merkle root in the commitment, which makes P2QRH a
+quantum-resistant version of Taproot transactions. The TapScript itself must however be provided in the witness,


Did you mean to refer to BIP 341 here?

mraksoll4 · 2025-04-26T22:48:55Z

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 · 2025-05-27T20:53:30Z

@cryptoquick any update here?

cryptoquick · 2025-05-27T20:55:44Z

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

cryptoquick · 2025-06-23T10:30:55Z

@EthanHeilman has joined the chat.
cryptoquick#21
It's a big change, so I recommend reviewing the PR separately.
Any suggestions, especially answers to the questions / open checkmarks would be helpful, thanks!

* Rewrote rationale * Fix bolded principles * Actually fix bold * Updates to talk about signature + public key size rather than just signature size * Took a pass over rationale * Started work on specification * Adds example tapscript hybrid signatures * More work on the specification * Cleans up TODO * Fixing grammar, other minor changes * SHL --> SLH * Apply suggestions from code review Co-authored-by: Hunter Beast <[email protected]> * Adds discussion of SQIsign * Fixes broken llink to libbitcoinpqc Co-authored-by: Hunter Beast <[email protected]> * Fixes writing in SQIsign section Co-authored-by: Hunter Beast <[email protected]> * Add rational section on big signatures and public keys * Fixes typos * Adds script validation from BIP 341 * Add commas * Add design section, stack element size increase now in PQ sigs * Fixes typo * Fixes typos and formatting Co-authored-by: Hunter Beast <[email protected]> * Add authorship to readme * Add diagram of P2QRH merke tree, scriptPubKey and Witness * Remove completed todo * Add security section * Clean up wording, moves some things around * Minor rewording * Review suggestions Co-authored-by: Hunter Beast <[email protected]> * Clarified size differences * Changed header size and order * does --> doUpdate bip-0360.mediawiki Co-authored-by: Hunter Beast <[email protected]> * Add related work section * Better scale figure * Respond to review comments * remove double space Co-authored-by: Armin Sabouri <[email protected]> * Address review comments * Addressing Ademan comments * Sync source svg * Address review * Addresses review * Apply suggestions from code review Co-authored-by: Joey Yandle <[email protected]> * Update bip-0360.mediawiki Co-authored-by: Joey Yandle <[email protected]> * Update bip-0360.mediawiki Co-authored-by: Joey Yandle <[email protected]> * Addressing review comments * Addressing reviews --------- Co-authored-by: Hunter Beast <[email protected]> Co-authored-by: Armin Sabouri <[email protected]> Co-authored-by: Joey Yandle <[email protected]>

cryptoquick · 2025-07-07T15:06:10Z

The latest has been merged. This is a very different BIP now and took a lot of time and effort. We'll be making an announcement to the mailing list soon.

Thanks everyone to who reviewed, and thanks @EthanHeilman for all the help as co-author.

…P-360. (#24)

cryptoquick · 2025-07-13T15:55:27Z

I just wanted to confirm who's reviewing this BIP? I've addressed several of the previous reviewer's asks, including getting a co-author and reducing the scope of the BIP by omitting the PQC components. I do appreciate everyone's time and any review help I can get! I realize we made a lot of big changes and that will take more time to review. I just wanted to make sure everything was addressed in order to speed up the review process and hopefully get this merged.

Also, one question, would it simplify or complicate the review process if we added test vectors to this pull request? Should we wait to merge test vectors (when they're finished, which should be soon) until this PR is approved and merged? They will be available in both Rust and Python, in case that helps.

murchandamus

Thanks for the big update, it is much easier to follow and the design seems to be drastically improved. There are a number of instances in which I find naming of concepts a bit odd, especially where it needlessly deviates for concepts replicated from BIP 341.

murchandamus · 2025-07-14T20:47:49Z

bip-0360.mediawiki

+{| class="wikitable"
+|+ Output types vulnerable to long-exposure attacks on unspent addresses
+|-
+! Type !! Vulnerable !! Prefix !! Example
+|-
+| P2PK || Yes || Varies || 2103203b768951584fe9af6d9d9e6ff26a5f76e453212f19ba163774182ab8057f3eac
+|-
+| P2PKH || No¹ || 1 || 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa
+|-
+| P2MS || Yes || Varies || 52410496ec45f878b62c46c4be8e336dff7cc58df9b502178cc240e...
+|-
+| P2SH || No¹ || 3 || 3FkhZo7sGNue153xhgqPBcUaBsYvJW6tTx
+|-
+| P2WPKH || No¹ || bc1q || bc1qsnh5ktku9ztqeqfr89yrqjd05eh58nah884mku
+|-
+| P2WSH || No¹ || bc1q || bc1qvhu3557twysq2ldn6dut6rmaj3qk04p60h9l79wk4lzgy0ca8mfsnffz65
+|-
+| P2TR || Yes || bc1p || bc1p92aslsnseq786wxfk3ekra90ds9ku47qttupfjsqmmj4z82xdq4q3rr58u
+|-
+| P2QRH || No || bc1r || bc1r8rt68aze8tek87cnz4ndnvfzk6tk93jv39n4lmpu5a4yw453rcpszsft3z
+|}


Nit: There are no address standards for P2PK and P2MS, so perhaps the fourth column should be titled "Address or output script example" or similar

murchandamus · 2025-07-14T21:06:18Z

bip-0360.mediawiki

+A Long Exposure 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)


P2PK output scripts start with a push opcode, not "04". IIRC, uncompressed public keys start with 0x04, but compressed public keys start with 0x02 or 0x03 as the one in your example in the table.

This is meant to be a visual indication, and that's how they show up in the mempool explorer:
https://mempool.space/tx/0e3e2357e806b6cdb1f70b54c3a3a17b6714ee1f0e68bebb44a74b1efd512098
iirc compressed public key output types use pushbytes33.

I’m not sure why you are telling me that, when I already pointed out that uncompressed public keys start with 0x04. The points I’m raising are:

A P2PK output scripts do not start with 0x04, it starts with a push.

P2PK output scripts can either hold compressed or uncompressed public keys, therefore the content of the push can start with 04, but only if its an uncompressed key. It does not start with 0x04 in the case of a compressed key.

Your own example in line 99 is 2103203b768951584fe9af6d9d9e6ff26a5f76e453212f19ba163774182ab8057f3eac, which is a compressed key that starts with 0x03 and you are providing the whole script including the push opcode.—So your own example doesn’t start with 0x04 in two ways.

My recommendation would be to either drop "starts with 04", or to explain what exactly starts with 04, because P2PK outputs do not.

murchandamus · 2025-07-14T21:11:17Z

bip-0360.mediawiki

+Coinbase outputs to P2PK keys go as far as block 200,000, so there are, at the time of writing, 1,723,848 coins that
+are vulnerable from the first epoch in P2PK outputs alone. The majority of these have a block reward of 50 coins each,


P2PK outputs were created as recently as 2021, and the total amount of bitcoins held in P2PK outputs was 1,719,270.33902196 three days ago, so it does not seem accurate that all of these coins are held in outputs from the first epoch.

murchandamus · 2025-07-14T21:26:30Z

bip-0360.mediawiki

+and there are roughly 34,000 distinct P2PK scripts that are vulnerable. These coins can be considered
+"Satoshi's Shield." Any addresses with a balance of less than the original block subsidy of 50 coins can be considered
+cryptoeconomically incentive incompatible to capture until all of these are mined, and these addresses serve to provide
+time to transition Bitcoin to implement post-quantum security.
+
+It's for the above reason that, for those who wish to be prepared for quantum emergency, it is recommended that no more
+than 50 bitcoin are kept under a single, distinct, unused Native SegWit (P2WPKH, "bc1q") address at a time. This is
+assuming that the attacker is financially motivated instead of, for example, a nation state looking to break confidence
+in Bitcoin. Independently, this assumes that other vulnerable targets such as central banks have upgraded their
+cryptography by this time.


As mentioned before, the "Satoshi’s Shield" is argument is not convincing to me.
Satoshi’s coins are closely monitored and spending them would raise awareness immediately. Grabbing coins from some reused addresses likely would go unnoticed (or disputed) much longer. Once an attacker is able to take coins from any address, they may decide to find a number of private keys first before swiping a smaller UTXOs for a few blocks and then e.g., taking the Binance Cold Wallet and start with Satoshi’s coins after. Arguably I haven’t spent a lot of time thinking about it, but I just don’t see how it is useful for this BIP to attempt to predict the order in which an attacker would attack UTXOs and then to venture even further into the weeds by making recommendations to users about how to structure their UTXOs.

It's not trying to predict the order, it's making the observation that people with UTXOs fewer than 50 bitcoin are safer for longer. It's good, practical advice.

murchandamus · 2025-07-14T21:43:55Z

bip-0360.mediawiki

+called P2QRH (Pay to Quantum Resistant Hash). This output type is designed to support post-quantum signature algorithms
+but those algorithms will be specified in future BIPs.
+
+It is proposed to use SegWit version 3. This results in addresses that start with bc1r, which could be a useful way to


A convenient mnemonic is a poor reason to skip version 2.

Ethan has backed me up in this, you can find some of his reasoning here:
cryptoquick#23 (comment)

Another reason to skip version 2, or bc1z, is it would be ideal for use with BitZip if that ever works out.

I know it is a bit strange. There is a comment way back on the BIP where I also objected to it, but the idea has grown on me. That said, it is proving one of the most controversial aspects of P2QRH and I wouldn't fight for inclusion if it continues to be controversial. I want to write up a mailinglist post about it as I think treating SegWit versions as flags might be something we should consider for all new output types.

Please go sequentially. Skipping numbers for a mnemonic is stupid.

murchandamus · 2025-07-15T00:24:14Z

bip-0360.mediawiki

+P2QRH outputs provide the same tapscript functionality as P2TR outputs, but without the quantum-vulnerable key-spend
+path. This enables users, exchanges and other hodlers to easily move their coins from taproot outputs to P2QRH outputs


Suggested change

P2QRH outputs provide the same tapscript functionality as P2TR outputs, but without the quantum-vulnerable key-spend

path. This enables users, exchanges and other hodlers to easily move their coins from taproot outputs to P2QRH outputs

P2QRH outputs provide the same tapscript functionality as P2TR outputs, but without the quantum-vulnerable key path.

This enables users, exchanges and other hodlers to easily move their coins from taproot outputs to P2QRH outputs

murchandamus · 2025-07-15T00:29:43Z

bip-0360.mediawiki

+scripts into its design. P2QRH inherits this capability from taproot because P2QRH is simply taproot with the key-spend
+path removed. As a result, P2QRH does have the taproot internal key or tweak key, instead P2QRH commits directly to the


Suggested change

scripts into its design. P2QRH inherits this capability from taproot because P2QRH is simply taproot with the key-spend

path removed. As a result, P2QRH does have the taproot internal key or tweak key, instead P2QRH commits directly to the

scripts into its design. P2QRH inherits this capability from taproot because P2QRH is simply taproot with the key path

removed. As a result, P2QRH does not have the taproot internal key or tweak key, instead P2QRH commits directly to the

murchandamus · 2025-07-15T00:30:23Z

bip-0360.mediawiki

+
+Below we attempt to summarize some of the ideas discussed on the Bitcoin Bitcoin-Dev that relate to P2QRH.
+
+The idea of a taproot but with the key-spend path removed has been discussed a number of times in the Bitcoin community.


Suggested change

The idea of a taproot but with the key-spend path removed has been discussed a number of times in the Bitcoin community.

The idea of a taproot but with key path spending removed has been discussed a number of times in the Bitcoin community.

murchandamus · 2025-07-15T00:32:40Z

bip-0360.mediawiki

+
+The idea of a taproot but with the key-spend path removed has been discussed a number of times in the Bitcoin community.
+[https://gnusha.org/pi/bitcoindev/CAD5xwhgzR8e5r1e4H-5EH2mSsE1V39dd06+TgYniFnXFSBqLxw@mail.gmail.com/ OP_CAT Makes Bitcoin Quantum Secure]
+notes that if we disable the key-spend in taproot and activated CAT [https://github.com/bitcoin/bips/blob/master/bip-0347.mediawik BIP-347],


Here and everywhere: "key path (spending)" instead of "key-spend" or "key-spend path".

Thanks for point that out. I should have checked I was maintaining a consistent terminology.

I was trying to use key-spend path to refer to the capability and key-spend to refer to the action.

BIP-0342 uses

taproot spend to mean key-spend

script path spend to mean script-spend

I could use the language in BIP-0342, but it seems confusing to say we disable the taproot spend in pay-to-taproot. Rereading BIP-0342, I know realize that it is using path as shorthand for merkle path.

No one seems to use this "taproot spend" language anymore.

We could use:

script path spend and key path spend. "taproot but with the key path spend removed..."

script-spend and key-spend. "taproot but with the key-spend capability removed..."

script spend and key spend (no hyphen).

Do you have any preference?

I was unaware that BIP 342 was not consistent with BIP 341 in that regard, but I would consider "key path spend" and "script path spend" to be the established terms.

Updated all the places to use key path spend and script path spend consistently

murchandamus · 2025-07-15T00:34:31Z

bip-0360.mediawiki

+attestation was later discarded when Ethan Heilman joined as co-author, whom I'm incredibly grateful to for
+transforming this BIP into something far more congruent with existing Bitcoin design. Thank you as
+well to those who took the time to review and contribute, including Jeff Bride, Adam Borcany, Antoine Riard, Pierre-Luc
+Dallaire-Demers, Mark Erhardt, Joey Yandle, Jon Atack, Armin Sabouri, Jameson Lopp, Murchandamus, and Vojtěch Strnad.


Murchandamus and Mark Erhardt are the same person

This is fixed

achow101

I fail to see why this BIP both has all of the discussion about quantum resistant signatures and is called "Pay to Quantum Resistant Hash".

Essentially what this BIP does is describe a new output type that is taproot but without keypath spends, which is useful for preparing for post quantum signature schemes.

Since the actual specification of this BIP is that simple, why is there all of this discussion about post quantum signature schemes? These are completely irrelevant to the task of specifying a new output type that is taproot without keypath spends. Certainly some mention of doing this for future quantum resistance is helpful in the motivation section, but having thousands of words on the topic of quantum resistant signatures is entirely unnecessary. There doesn't need to be a discussion about quantum resistant signature security when the specification itself does not specify any quantum resistant signature scheme.

I also find the term "Pay to Quantum Resistant Hash" confusing. The phrase "quantum resistant" is typically used as an adjective. This title therefore suggests that the hash itself is quantum resistant, when actually it is the output that is "quantum resistant" insofar as it can't be spent with a simple signature.

achow101 · 2025-07-16T20:11:50Z

bip-0360.mediawiki

+* P2PK outputs (Satoshi's coins, CPU miners, starts with 04)
+* Reused addresses (any type, except P2QRH)
+* Taproot addresses (starts with bc1p)
+* Extended public keys, commonly known as "xpubs"
+* Wallet descriptors


I have a hard time understanding what this list is supposed to be. If it is a list of things that appear in the blockchain involved in a "long exposure quantum attack", then neither addresses, xpubs, nor descriptors appear in the blockchain.

If the point is that these things are affected (how?) by a "long exposure quantum attack", then perhaps, but in that case, the list is in correct. For example, descriptors are not necessarily affected, as descriptors allow for keys to be derived, and for them to be in output types that are hashed. Furthermore, future descriptors can also include P2QRH, so they won't always necessarily be "affected".

I think this list is generally superfluous and unnecessary. The single sentence defining "long exposure quantum attack" is sufficient and I don't think examples are needed for a reader to understand.

achow101 · 2025-07-16T20:16:03Z

bip-0360.mediawiki

+
+This document is licensed under the 3-clause BSD license.
+
+=== Motivation ===


I think this motivation section is overly wordy. It explains a lot of things that I think are unnecessary to understanding the reason why readers should be interested in a quantum signature scheme to be specified.

I think everything after the 3rd paragraph (starting with "Ordinarily, when a transaction is signed") could be dropped and we wouldn't be losing any important context for why this BIP should exist.

achow101 · 2025-07-16T20:18:21Z

bip-0360.mediawiki

+called P2QRH (Pay to Quantum Resistant Hash). This output type is designed to support post-quantum signature algorithms
+but those algorithms will be specified in future BIPs.
+
+It is proposed to use SegWit version 3. This results in addresses that start with bc1r, which could be a useful way to


Please go sequentially. Skipping numbers for a mnemonic is stupid.

achow101 · 2025-07-16T20:19:59Z

bip-0360.mediawiki

+
+=== Design ===
+
+This is the first in a series of BIPs under a QuBit soft fork. A qubit is a fundamental unit of quantum computing, and


This is entirely extraneous and unnecessary, especially in the section which is specifying this BIP in particular.

Include the rationale for naming is entirely unnecessary and is just fluff.

achow101 · 2025-07-16T20:25:09Z

bip-0360.mediawiki

+using Grover's algorithm would require at least 10^24 quantum operations. As for Grover's application to mining, see
+[https://quantumcomputing.stackexchange.com/a/12847 Sam Jaques' post on this].
+
+=== Design ===


It's unclear to me why this section is part of "Introduction" when there is a specification down below in "Specification" that the text here should be within.

The "Design" section as used in other BIPs is to lay out design goals, not specific details as done here.

As an implementer, I will absolutely miss this relevant part of the specification because I skipped past it to go to the section titled "Specification".

achow101 · 2025-07-16T20:29:13Z

bip-0360.mediawiki

+since P2QRH does not have a key-spend path. We omit the public key from the control block as it is not needed in P2QRH.
+We maintain support for the optional annex in the witness (see specification for more details).
+
+=== Rationale ===


This section seems like it should be named "Design" rather than "Rationale". "Rationale" is usually used for specific footnotes giving rationale for specific details rather than laying out design goals.

achow101 · 2025-07-16T20:34:30Z

bip-0360.mediawiki

+can be used in a quantum resistant manner. In a future BIP, we enable tapscript programs to verify two Post-Quantum (PQ) signature
+algorithms, ML-DSA (CRYSTALS-Dilithium) and SLH-DSA (SPHINCS+). It is important to consider these two changes together because P2QRH must
+be designed to support the addition of these PQ signature algorithms. The full description of these signatures will be provided in a future BIP.
+


The rest of the text in this section seems unnecessary to me at this position in the BIP. It lays out a bunch of detailed reasoning which I think is better suited for an appendix or a discussion section at the end of the BIP. It's a lot of text that I don't think implementers really care about.

achow101 · 2025-07-16T20:36:08Z

bip-0360.mediawiki

+Example P2QRH address:
+
+<code>bc1r...</code> (32-byte Bech32m-encoded tapleaf merkle root)


If you're going to put something labeled as an example address, then it should be a complete and valid address. Otherwise, this adds no new useful information.

achow101 · 2025-07-16T20:37:46Z

bip-0360.mediawiki

+** Execute the script, according to the applicable script rules, using the witness stack elements excluding the script ''s'', the control block ''c'', and the annex ''a'' if present, as initial stack. This implies that for the future leaf versions (non-''0xC0'') the execution must succeed.
+
+The steps above follow the script path spending logic from [[bip-0341.mediawiki|BIP-341]] with the following changes:
+- The witness program is the tapleaf merkle root and not a public key. This means that we skip directly to BIP-341 spend path tapleaf merkle tree validation.


- is not a valid bullet point character in mediawiki. Use * instead, otherwise this list does not render correctly.

EthanHeilman · 2025-07-17T12:46:10Z

Thanks so much for this review.

Since the actual specification of this BIP is that simple, why is there all of this discussion about post quantum signature schemes? [...] There doesn't need to be a discussion about quantum resistant signature security when the specification itself does not specify any quantum resistant signature scheme.

I'm working on the PQ signature algorithm BIP, but I haven't created a PR for it. I'm planning on moving a bunch of the PQ signature text from this BIP to that BIP. Since it isn't public yet and the motivation behind this BIP is that provides the foundation for PQ signatures,.

I agree current text in BIP goes well beyond the minimal test that is necessary. I'll move the PQ signatures out of this PR and into the PQ signature BIP.

I also find the term "Pay to Quantum Resistant Hash" confusing. The phrase "quantum resistant" is typically used as an adjective. This title therefore suggests that the hash itself is quantum resistant, when actually it is the output that is "quantum resistant" insofar as it can't be spent with a simple signature.

I've been hearing that feedback and we are open to alternative names. Pay-to-tapleaf-hash/pay-to-tapscript-hash (P2TH), pay-to-tapscript-tree-hash (P2TTH), pay-to-script-tree-hash (P2STH), pay-to-quantum-resistant-taptree (P2QRT)?

…apleaf merkle tree

conduition · 2025-07-18T23:16:42Z

Hey @EthanHeilman , I wanted to cross-link this post on delving. Adding a new tapleaf version with dynamically endorsed script leafs may give us a way to start migrating people early, even before ml-dsa and slh-dsa opcodes are defined, but still allow the use of those opcodes once they're spec'd out and deployed.

That said, if we can package those opcodes together alongside BIP360, i still think that'd be a better option. It will lead to less complexity and confusion overall.

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

jonasnick reviewed Mar 24, 2025

View reviewed changes

This comment was marked as spam.

Sign in to view

bitcoin deleted a comment from masoudahg00 Apr 5, 2025

murchandamus mentioned this pull request May 7, 2025

BIP 443: OP_CHECKCONTRACTVERIFY #1793

Merged

This comment was marked as off-topic.

Sign in to view

This comment has been minimized.

Sign in to view

This comment was marked as duplicate.

Sign in to view

Update changelog and acknowledgements with the new developments in BI…

77dbeee

…P-360. (#24)

murchandamus reviewed Jul 15, 2025

View reviewed changes

Fix duplicate acknowledgement

44778df

bitcoin deleted a comment from Noxcheborz Jul 16, 2025

achow101 reviewed Jul 16, 2025

View reviewed changes

EthanHeilman mentioned this pull request Jul 17, 2025

Task list of changes to BIP-360 cryptoquick/bips#27

Open

11 tasks

EthanHeilman added 7 commits July 17, 2025 09:23

Fix itemize by using mediawiki splat

1c2fb22

Use consistent naming for script path spend and key path spend.

01e9d06

Hyphenate 32-byte

26113f1

Use leaf rather than tapleaf when describing leaf tapscripts in the t…

eddf8f9

…apleaf merkle tree

Minor terminology fixes

1f65b67

Minor terminology fixes

e3e64a6

Remove qubit name

c3bd091

		Coinbase outputs to P2PK keys go as far as block 200,000, so there are, at the time of writing, 1,723,848 coins that
		are vulnerable from the first epoch in P2PK outputs alone. The majority of these have a block reward of 50 coins each,

		P2QRH outputs provide the same tapscript functionality as P2TR outputs, but without the quantum-vulnerable key-spend
		path. This enables users, exchanges and other hodlers to easily move their coins from taproot outputs to P2QRH outputs

		scripts into its design. P2QRH inherits this capability from taproot because P2QRH is simply taproot with the key-spend
		path removed. As a result, P2QRH does have the taproot internal key or tweak key, instead P2QRH commits directly to the


		Below we attempt to summarize some of the ideas discussed on the Bitcoin Bitcoin-Dev that relate to P2QRH.

		The idea of a taproot but with the key-spend path removed has been discussed a number of times in the Bitcoin community.

	The idea of a taproot but with the key-spend path removed has been discussed a number of times in the Bitcoin community.
	The idea of a taproot but with key path spending removed has been discussed a number of times in the Bitcoin community.


		This document is licensed under the 3-clause BSD license.

		=== Motivation ===


		=== Design ===

		This is the first in a series of BIPs under a QuBit soft fork. A qubit is a fundamental unit of quantum computing, and

		Example P2QRH address:

		<code>bc1r...</code> (32-byte Bech32m-encoded tapleaf merkle root)

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

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jonatack left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

jonatack commented Oct 1, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jonatack commented Oct 21, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This comment was marked as spam.

Uh oh!

This comment was marked as spam.

Uh oh!

mraksoll4 commented Apr 26, 2025

Uh oh!

This comment was marked as off-topic.

jonatack commented May 27, 2025

Uh oh!

cryptoquick commented May 27, 2025

Uh oh!

This comment has been minimized.

This comment was marked as duplicate.

cryptoquick commented Jun 23, 2025

Uh oh!

cryptoquick commented Jul 7, 2025

Uh oh!

cryptoquick commented Jul 13, 2025

Uh oh!

murchandamus left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

murchandamus Jul 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

EthanHeilman Jul 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jonatack left a comment •

edited

Loading

jonatack commented Oct 1, 2024 •

edited

Loading

murchandamus Jul 15, 2025 •

edited

Loading

EthanHeilman Jul 16, 2025 •

edited

Loading