Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
wants to merge 36 commits into
base: master
Choose a base branch
from
Open
Changes from 1 commit
Commits
Show all changes
36 commits
Select commit Hold shift + click to select a range
1fa2485
QuBit - P2QRH spending rules - Final draft before submitting upstream…
cryptoquick Sep 27, 2024
6f67a3d
Add pqNTRUsign to .typos.toml.
cryptoquick Sep 27, 2024
d83c29d
QuBit - P2QRH
cryptoquick Sep 28, 2024
ae0936a
typo fix
jlopp Oct 2, 2024
d89b7c5
Merge pull request #13 from jlopp/patch-3
cryptoquick Oct 4, 2024
b4c329b
QuBit - P2QRH spending rules
cryptoquick Oct 21, 2024
53d497e
Adds clarity and brevity
Nov 5, 2024
0a2ed4a
Apply suggestions from review
cryptoquick Nov 21, 2024
c92a9b0
QuBit - P2QRH spending rules
cryptoquick Nov 21, 2024
e1b7007
Add details on attestation structure and parsing. (#14)
cryptoquick Dec 3, 2024
60d7294
MediaWiki formatting fixes
cryptoquick Dec 3, 2024
2d098d9
MediaWiki formatting fixes
cryptoquick Dec 5, 2024
ed4e862
MediaWiki fixes, remove redundant sections. (#16)
cryptoquick Dec 6, 2024
f2426c6
Update title and formatting.
cryptoquick Dec 6, 2024
2e4ad81
More wrestling with MediaWiki formatting...
cryptoquick Dec 6, 2024
9935005
I give up. Removing code and pre blocks.
cryptoquick Dec 6, 2024
cc47f9e
More formatting fixes.
cryptoquick Dec 6, 2024
ff4d2c2
Apply suggestions from code review
cryptoquick Dec 6, 2024
f206b97
Address Murch feedback.
cryptoquick Dec 6, 2024
70649ea
Merge branch 'p2qrh' of github.com:cryptoquick/bips into p2qrh
cryptoquick Dec 6, 2024
feff847
MediaWiki formatting.
cryptoquick Dec 6, 2024
e186b52
Swap layer and title.
cryptoquick Dec 9, 2024
d500124
Apply suggestions from code review
cryptoquick Dec 13, 2024
85a347b
Update to use merkle tree for attestation commitment. Update LR & SR …
cryptoquick Dec 13, 2024
85348c0
P2QRH assigned BIP number 360.
cryptoquick Dec 18, 2024
a4f3dc6
Apply suggestions from code review
cryptoquick Dec 20, 2024
2b641b8
Address feedback from vostrnad.
cryptoquick Dec 20, 2024
4b8b647
Update typos list.
cryptoquick Dec 20, 2024
990d8a8
Fixes, typos, formatting.
cryptoquick Dec 20, 2024
0fdd8c3
Updates based on Murch and vostrnad feedback.
cryptoquick Dec 20, 2024
208a987
Fix title change in README.
cryptoquick Dec 20, 2024
8eb35c8
Apply suggestions from code review
cryptoquick Dec 23, 2024
d9bb0ff
Fix broken link.
cryptoquick Dec 23, 2024
0ae69db
Remove Canary section.
cryptoquick Dec 23, 2024
81e1838
Apply suggestions from code review
cryptoquick Jan 14, 2025
c1b9047
Address suggestions from jonatack's review.
cryptoquick Jan 14, 2025
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
45 changes: 23 additions & 22 deletions bip-0360.mediawiki
Original file line number Diff line number Diff line change
Expand Up @@ -40,11 +40,11 @@ relies on post-quantum cryptographic (PQC) signature algorithms. By adopting PQC
resistance without requiring a hard fork or block size increase.

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
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 addresses might be vulnerable, representing 5M to 10M bitcoin.
[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 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 addresses might be vulnerable, representing
5M to 10M bitcoin.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As described above, please don’t reformat the entire paragraph when you change a single line. Moving all the line breaks makes it needlessly difficult to see what actually changed about the text.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I just noticed that it was over 120 characters in length, which was something you requested earlier.


Ordinarily, when a transaction is signed, the public key is explicitly stated in the input script. This means that the
public key is exposed on the blockchain when the transaction is spent, making it vulnerable to quantum attack until
Expand Down Expand Up @@ -79,7 +79,7 @@ The following table is intended to inform the average Bitcoin user whether their
quantum attack:

{| class="wikitable"
|+ Vulnerable output types
|+ Output types vulnerable to long-range attacks on unspent addresses
|-
! Type !! Vulnerable !! Prefix !! Example
|-
Expand Down Expand Up @@ -129,13 +129,11 @@ before a transaction is mined. Long-range attacks can be executed over a longer
exposed on the blockchain indefinitely.

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 at the time of writing in P2PK outputs alone. The majority of these have a
block reward of 50 coins each, 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.
are vulnerable from the first epoch in P2PK outputs alone. The majority of these have a block reward of 50 coins each,
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.
Comment on lines +133 to +136
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Once someone just starts stealing ~5% of the supply, it seems that it would be too late?


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
Expand All @@ -148,12 +146,12 @@ upgraded by 2030, with browsers and operating systems fully upgraded by 2033. Ac
Cryptography is planned to be disallowed within the US federal government after 2035. An exception is made for hybrid
cryptography, which is the use of ECC and post-quantum algorithms together.

Although the main threat posed by CRQCs is to the signatures used in Bitcoin, a smaller threat is to Bitcoin's hash algorithms.
In particular, while a CRQC could use [https://en.wikipedia.org/wiki/Grover's_algorithm Grover's algorithm] to gain a
quadratic speedup on brute-force attacks on the hash functions used in Bitcoin, a significantly more powerful CRQC is
needed for these attacks to meaningfully impact Bitcoin. For instance, a preimage attack on HASH160 <ref name="hash160">
Used by P2PKH, P2SH, and P2WPKH addresses, though not P2WSH because it uses 256-bit hashes.</ref> using Grover's
algorithm would require at least 10^24 quantum operations. As for Grover's application to mining, see
Although the main threat posed by CRQCs is to the signatures used in Bitcoin, a smaller threat is to Bitcoin's hash
algorithms. In particular, while a CRQC could use [https://en.wikipedia.org/wiki/Grover's_algorithm Grover's algorithm]
to gain a quadratic speedup on brute-force attacks on the hash functions used in Bitcoin, a significantly more powerful
CRQC is needed for these attacks to meaningfully impact Bitcoin. For instance, a preimage attack on
HASH160 <ref name="hash160">Used by P2PKH, P2SH, and P2WPKH addresses, though not P2WSH because it uses 256-bit hashes.</ref>
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].

=== Rationale ===
Expand Down Expand Up @@ -315,8 +313,9 @@ keys from the transaction while still proving they were part of the original com
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.
This allows for inclusion of a [https://github.com/bitcoin/bips/blob/master/bip-0114.mediawiki BIP-114] Taproot
Merkelized Abstract Syntax Tree (MAST) merkle root in the attestation, which makes P2QRH a quantum-resistant
version of Taproot transactions.
Comment on lines +316 to +318
Copy link
Contributor

@murchandamus murchandamus Jan 16, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Taproot does not use an Abstract Syntax Tree. It uses an Alternative Script Tree. Also the term "MAST" is not used in the Taproot BIPs in this context, they refer to the concept as "script tree".


=== Transaction Serialization ===

Expand Down Expand Up @@ -513,7 +512,9 @@ Hash-based cryptography
|-
| [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
especially with high values for w. Winternitz values are for w of 4. It's worth noting that Winternitz signatures can
only safely be used one time per public key. If addresses are reused, private key information might be leaked, allowing
attackers to spend future outputs assigned to the same address.</ref> || 2,368 bytes || Hash-based cryptography
|-
| [https://sphincs.org/data/sphincs+-r3.1-specification.pdf SPHINCS+ Rd. 3.1 (FIPS 205 - SLH-DSA)] || 2015 || 29,792
bytes || 64 bytes || Hash-based cryptography
Expand Down
Loading