Draft: QuBit - P2QRH spending rules #1670
Conversation
bip-p2qrh.mediawiki
Outdated
|
|
||
| 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. | ||
|
|
||
| Ordinarily, when a transaction is signed, the public key can be recovered from the signature. This makes a transaction submitted to the mempool vulnerable to quantum attack until it's mined. One way to mitigate this is to submit the transaction directly to a mining pool, which bypasses the mempool. This process is known as an out-of-band transaction. The mining pool must be trusted not to reveal the key to attackers. |
There was a problem hiding this comment.
What about public keys that are derived via BIP-32 non-hardened child keys? While the public key is not reused, one might be able to guess and check child keys from revealed public keys and learn the public key for a p2pkh address prior to seeing a signature for that public key. Is there a reason this is not a concern?
There was a problem hiding this comment.
That is a concern I haven't considered. I'll be sure to add that.
There was a problem hiding this comment.
It's also been added to the new table for scenarios for revealed public keys on bitcoin.
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. |
There was a problem hiding this comment.
This is a quick first skim. Seems fine so far, I left some comments. The Motivation and Rationale seem a bit long, perhaps some of that could be split out into other sections like Related Work, Backward Compatibility, or just tightened a bit.
I’m wondering whether introducing four different signature schemes at once may be a bit too ambitious.
bip-p2qrh.mediawiki
Outdated
|
|
||
| Ordinarily, when a transaction is signed, the public key can be recovered from the signature. This makes a transaction submitted to the mempool vulnerable to quantum attack until it's mined. One way to mitigate this is to submit the transaction directly to a mining pool, which bypasses the mempool. This process is known as an out-of-band transaction. The mining pool must be trusted not to reveal the transaction public key to attackers. | ||
|
|
||
| Not having public keys exposed on-chain is an important step for quantum security. Otherwise funds would need to be spent to new addresses on a regular basis in order to prevent the possibility of a "long-range CRQC attack" recovering the key behind high value addresses. A long-range quantum attack can be considered one performed with chain data, such as that from a used address or one encoded in a spend script. A "short-range quantum attack" would be one performed on keys in the mempool, which is seen as impractical given transaction throughput and block time. As the value being sent increases, so too should the fee in order to commit the transaction to the chain as soon as possible. This makes useless the public key revealed by spending a UTXO, so long as it is never reused. |
There was a problem hiding this comment.
Is this not just a question of time? If the security of the DLP is broken, eventually it could be broken in the time between submission of a transaction and its confirmation. Anyway, an attacker could simply outspend the victim’s transaction to buy more time.
bip-p2qrh.mediawiki
Outdated
|
|
||
| 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%. Additionally, cryptographer Peter Wuille estimates even more might be vulnerable, for the reasons provided [https://x.com/pwuille/status/1108085284862713856 here]. | ||
|
|
||
| Ordinarily, when a transaction is signed, the public key can be recovered from the signature. This makes a transaction submitted to the mempool vulnerable to quantum attack until it's mined. One way to mitigate this is to submit the transaction directly to a mining pool, which bypasses the mempool. This process is known as an out-of-band transaction. The mining pool must be trusted not to reveal the transaction public key to attackers. |
There was a problem hiding this comment.
Relying on mining pools to keep transactions private does not feel like a viable security assumption.
There was a problem hiding this comment.
Agreed, which is why P2QRH is preferable. It's still worth mentioning, but I'll be sure to explain this is the entire purpose of P2QRH, to essentially keep the mempool trustless.
bip-p2qrh.mediawiki
Outdated
| |- | ||
| | Early addresses (Satoshi's coins, CPU miners, starts with 04) || Long-range | ||
| |- | ||
| | Reused addresses (any type, except bc1r) || Long-range |
There was a problem hiding this comment.
What is "bc1r"? It has not been introduced at this point.
bip-p2qrh.mediawiki
Outdated
|
|
||
| Should quantum advantage manifest, a convention is proposed in spending the full 65-byte P2PK key used by the coinbase output in Block 1 back to itself. It is proposed to call the address in Block 1 the [https://mempool.space/address/0496b538e853519c726a2c91e61ec11600ae1390813a627c66fb8be7947be63c52da7589379515d4e0a604f8141781e62294721166bf621e73a82cbf2342c858ee Canary address] since it can only be spent from by others (assuming Satoshi's continued absence) if secp256k1 is broken. Should the Canary coins move, that will signal that reliance on secp256k1 is presently vulnerable. Without the Canary, or an address like it, there may be some doubt as to whether the coins were moved with keys belonging to the original owner. | ||
|
|
||
| As an interesting aside, coinbase outputs to P2PK keys go as far as block 200,000, so it's possible there are between 1-2 million coins that are vulnerable from the first epoch. 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 incentive incompatible to capture until all of these are mined. |
There was a problem hiding this comment.
As of earlier this month, ₿1,723,848 were held in P2PK outputs.
bip-p2qrh.mediawiki
Outdated
|
|
||
| The Commercial National Security Algorithm Suite (CNSA) 2.0 has a timeline for software and networking equipment to be upgraded by 2030, with browsers and operating systems fully upgraded by 2033. | ||
|
|
||
| Lastly, it is worth noting by way of comparison that [https://ethresear.ch/t/how-to-hard-fork-to-save-most-users-funds-in-a-quantum-emergency/18901 Vitalik Buterin's proposed solution] in an Ethereum quantum emergency is quite different from the approach in this BIP. His plan involves a hard fork of the chain, reverting all blocks after a sufficient amount of theft, and using STARKs based on BIP-32 seeds to act as the authoritative secret when signing. These measures are deemed far too heavy-handed for bitcoin. |
There was a problem hiding this comment.
Some of this Motivation section could appear in "Related Work" or "backward compatibility".
bip-p2qrh.mediawiki
Outdated
|
|
||
| The proposal above also leaves a gap in case it makes sense to use version 2, or bc1z, for implementation of other address formats such as those that employ Cross Input Signature Aggregation (CISA). | ||
|
|
||
| P2QRH is meant to be implemented on top of P2TR, combining the security of classical Schnorr signatures along with post-quantum cryptography. This is a form of "hybrid cryptography" such that no regression in security is presented should a vulnerability exist in one of the signature algorithms used. One key distinction between P2QRH and P2TR however is that P2QRH will encode a hash of the public key. This is a significant deviation from how Taproot works by itself, but it is necessary to avoid exposing public keys on-chain where they are vulnerable to attack. |
There was a problem hiding this comment.
Does it then even make sense to base the new output type on Taproot rather than e.g. P2WPKH?
There was a problem hiding this comment.
There's already things that use taptrees where this kind of cryptographic commitment scheme would be adequate, such as for RGB. It would be nice to also be able to rely on Schnorr signature aggregation even in cases where its security has to be augmented by PQC. Do you know of anything that could be broken if the public key isn't known in advance? Like MuSig2 or FROST?
Co-authored-by: Mark "Murch" Erhardt <[email protected]>
SPHINCS and Crystals-DILITHIUM are approved by NIST. Antoine Riard specifically requested the inclusion of SPHINCS on the mailing list, and the alternative proposal implements Crystals-DILITHIUM. FALCON is likely to be approved as as a FIPS standard as well, but it's not yet official. SQIsign is very attractive for its small public key and signature sizes, but it is only just recently under review. |
jonatack
removed
the
PR Author action required
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.