BIP 360 - Pay to Tapscript Hash (P2TSH) #1670
Conversation
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. |
performance and failure tests.
… that parity bit is always 1
ariard
left a comment
ariard
left a comment
There was a problem hiding this comment.
Thanks for the efforts on this proposal, answered back most of my previous comments, of which most can be resolved (still see long vs short exposure attack wonder) and added more. I’m in the “Design” section so far.
Seeing that the idea is to have CRYSTALS-Dilithium and SPHINCS++ proposed as the concrete signature algorithms. I might start to hack on an implementation for FALCON, of which the sigs size are smaller than Dilithium while being also lattice-based cryptography. It’s an interesting thing to hack on. Libbitcoinpqc is in C, so perfect.
bip-0360.mediawiki
Outdated
|
|
||
| This document is licensed under the 3-clause BSD license. | ||
|
|
||
| === Motivation === |
There was a problem hiding this comment.
By comparison BIP340 is reasonably wordily on the security properties of the standardized signature scheme:
https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki
See the arguments on provable security, non-malleability and linearity.
I’m not sure if you’re really familiar with post-quantum cryptography (e.g https://arxiv.org/pdf/1710.10377 is a good starter), though there are really few papers doing cryptanalysis of quantum signature scheme in the Bitcoin setting. While of course one can object why it matters to do cryptanalysis i_n the Bitcoin setting_, one should remind itself that some argued property in ECC literature (e.g signature non-malleability) might have tremendous downsides if not well understood (e.g breaking BIP141 “trust-free unconfirmed transaction dependency chain”).
That’s the “motivation” section is for now very drafty and over-verbose, sure but that why it’s still a draft.
bip-0360.mediawiki
Outdated
| * 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 |
There was a problem hiding this comment.
See comments there on trying to define “long exposure” vs “short exposure” attacks:
https://github.com/bitcoin/bips/pull/1670/files#r1966885340
bip-0360.mediawiki
Outdated
|
|
||
| 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 |
There was a problem hiding this comment.
For a small side-note, SWIFT network also uses asymmetric cryptography for its operations:
https://www.swift.com/myswift/services/training/swift-training-catalogue/browse-swift-training-catalogue/swiftnet-public-key-infrastructure-pki
So in case of CRQC becoming a reality, it’s not only Bitcoin who is in shit, neither also central banks, but also the worldwide traditional payment system.
Mostly, it’s just making the observations that analyzing the economic impact and attacker (economical) rational is far from straightforward, as soon as we get out of our Bitcoin bubble.
There was a problem hiding this comment.
SWIFT network itself typically lives on top of a VPN secured by symmetric keys (and some alrdy using PQC). So a bad actor needs to be one of the SWIFT whitelisted participants.
There was a problem hiding this comment.
Most banking and national computer networks are now starting projects to move to quantum resistant algorithms for KE and later for signing. They know it will take them a long time, but they are taking it seriously and inch by inch moving to mitigate it.
bip-0360.mediawiki
Outdated
| Taproot internal key, as it is not needed. Instead, a P2QRH output is just the 32-byte root of the tapleaf Merkle tree as defined | ||
| in [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP 341] and hashed with the tag "QuantumRoot" as shown below. | ||
|
|
||
| [[File:bip-0360/merkletree.png|center|550px|thumb|]] |
There was a problem hiding this comment.
The P2QRH scriptPubkey is saying SegWit version 3 ?
Shouldn’t be this SegWit version 2, given that BIP141 is SegWit version 0 and BIP341 is SegWit version 1.
Unless there is a social community convention somewhere, that we reserve SegWit version 2 for other purpose.
There was a problem hiding this comment.
We have already switched this to SegWit version 2, the updated BIP is just waiting on other revisions and hasn't been pushed yet. Sorry about that.
| key in P2QRH the root is hashed by itself using the tag "QuantumRoot". | ||
|
|
||
| <source> | ||
| D = tagged_hash("TapLeaf", bytes([leaf_version]) + ser_script(script)) |
There was a problem hiding this comment.
This could be tagged with “QuantumLeaf” or “QuantumBranch”.
Domain separation is a good thing.
Even in the case where a tapleaf validation is — all others things equal - the same between a P2TR and a P2QRH, preventing accidental misuage of a tapleaf by wallets or other bitcoin softwares among SegWit versions would be a good thing IMHO.
This is debatable, but somehow I think it’s good practice (— you wish to avoid a P2QRH spends being accidentally replayed on a P2TR and note the same signature digest than for BIP341/342 sounds to be proposed).
There was a problem hiding this comment.
I appreciate this question, let me give you my take and see if you agree.
If we could completely get away without domain separation I would do it, since P2QRH is tapscript and Tapleaf composed with a different output type. Ideally they should be swappable and the output type should not influence internal details like this. The intent of SegWit version should be specified in the SegWit version, having multiple places it needs to be specified does not enhance security but makes it more likely that someone will make a mistake since they need to get two things right rather than just one. A mistake here doesn't mean the user gets an error message, a mistake in mixing the Merkle tree domain separator with the wrong SegWit version means the output is probably unspendable.
Unfortunately P2QRH and P2TR are functionality different at the Merkle root and thus already we have domain separation there with "TapRoot" vs "QuantumRoot".
you wish to avoid a P2QRH spends being accidentally replayed on a P2TR and note the same signature digest than for BIP341/342 sounds to be proposed
I don't think such replays are possible with BIP-360 as currently written because the signature covers the domain separator at the root. Even if the Merkle trees were exactly the same, doesn't the signature cover the SegWit version as well?
bip-0360.mediawiki
Outdated
| 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. | ||
|
|
There was a problem hiding this comment.
Rational footnotes at the end of the document sounds good, like done for BIP340 or BIP341.
bip-0360.mediawiki
Outdated
| prudence dictates we take such risks seriously and ensure that Bitcoin always has at least two secure signature algorithms built | ||
| on orthogonal cryptographic assumptions. In the event one algorithm is broken, an alternative will be available. An added benefit | ||
| is that parties seeking to securely store Bitcoin over decades can lock their coins under multiple algorithms, | ||
| ensuring their coins will not be stolen even in the face of a catastrophic break in one of those signature algorithms. |
There was a problem hiding this comment.
A contrario, this is more cryptographic consensus code that have to be integrated, where any implementation bug might be fatal….
Personally, I think it’s worth the risk to have multiple signature schemes in case of advances in post-quantum cryptanalysis (it’s all quite unchartered paths here…), but I believe it might be more debatable among the community and the industry…
There was a problem hiding this comment.
Thanks for asking this @ariard It made me write up some ideas that have been motivating my work on BIP-360.
Which is worse for Bitcoin:
- Accidental hardfork due to bug in consensus critical code,
- Inability to authenticate ownership of the UTXO set due to signature forgery attack (maybe via a Quantum Computer, maybe because of a new development in number theory or maybe something else entirely)
I'd argue that Bitcoin can recover from an accidental hardfork, while some funds might be lost due to double spending on the different forks, there is a clear path to recovery: deploy a patch and reestablish consensus. However if there is break in ECC whereby anyone can forge Bitcoin signatures a large chunk of the UTXO set can not be authenticated as being owned by anyone. This is really really bad. How do you recover from this? Sure you can do proof of knowledge of public keys in P2SH outputs as long as those public keys haven't been used before, but an enormous chunk of the UTXO set is rendered unauthenticatable and we will never be able to cryptographically determine who owns those UTXOs. This includes outputs that reuse a public key or have otherwise leaked a public, all P2TR outputs, all P2PK outputs. This problem gets worse the more people adopt P2TR. As far as I can tell, this is the only security vulnerability that if discovered could actually destroy Bitcoin. The only defense is to implement a failover signature algorithm before the attack happens.
Bitcoin could survive SHA256 collisions or PoW being broken, simply port the UTXO set to a new protocol via a softfork that enforces a new PoW/additional hash function by rejecting blocks that doesn't include this additional data. A break in the signature scheme currently provides no easy recovery mechanism.
If we want to maximize the probability Bitcoin survives the next 50 or 100 years, providing a built in mechanism whereby Bitcoin can recover from a break in a single signature algorithm is the most effective security upgrade on the table. We need multiple signature algorithms to do this.
We already have two signature algorithms, ECDSA and ECC Schorr, but they are similar enough that break in one is likely to result in a break in the other as is the case for quantum attacks.
|
When can we review the updated version of BIP-360? As I understand, this is very outdated as is. Any plans to allow for some form of "Post-Quantum cross-input signature aggregation"? |
|
@moonsettler Working on it, should have updates soon
This BIP just describes a PQ output type, so this BIP should neither allow nor disallow cross-input signature aggregation. It is an important topic to consider for BIPs specifying the PQ CHECKSIG opcodes, but I'm not sure how exactly to handle it. More thought is needed. |
|
Same script (address) aggregation could be handled on this level more efficiently instead of in script.
|
| |- | ||
| | [[bip-0360.mediawiki|360]] | ||
| | Consensus (soft fork) | ||
| | Pay-to-Tapscript-Hash (P2TSH) |
There was a problem hiding this comment.
Why the new title (that is also different from the PR title)?
There was a problem hiding this comment.
We've completely rewritten the BIP and added another co-author
Those changes will be coming soon
|
Given that you say that the content of this BIP is still in flux and will be completely overhauled soon, I’ll convert this PR to Draft for the time being. Please set it back to Ready for Review after pushing the changes. |
* Start with NotMike contributions from #31 * Integrate changes and updates from the collaborative Google Doc for the rewrite. * Mediawiki formatting updates. * Grammar fixes * Update bip-0360.mediawiki Co-authored-by: Ethan Heilman <[email protected]> * Remove links from header preformatted text. * Apply suggestions from code review Co-authored-by: Ethan Heilman <[email protected]> * merkletree.svg: correct size of Merkle path in control block Updates the vector file merkletree.svg. * Render SVG to update merkletree PNG * Apply suggestions from code review Co-authored-by: Ethan Heilman <[email protected]> Co-authored-by: notmike <[email protected]> * Consistency on ellipses and hyphenation. * Remove redeem script language. * Address @notmike-5 feedback. * Formatting and consistency fixes for Script Validation * Language, consistency, and formatting fixes. * Standardize terminology around taptree vs tapleaf Merkle tree. * Add clarity to P2TSH Trade-Offs section. * Update with more accurate language --------- Co-authored-by: Ethan Heilman <[email protected]> Co-authored-by: notmike <[email protected]>
|
The BIP 360 team is excited to share the following revisions aimed at enhancing clarity, readability and defining new terminology related to Bitcoin Quantum Resistance. Key changes include:
We'd love your feedback! Please review the latest version of the BIP: Rendered view and details: https://bip360.org/ (will be updated soon!) Please share your thoughts, suggestions, or concerns. Your input is invaluable in shaping this proposal. |
cryptoquick
changed the title
|
Just noticed that the test vectors have not yet been updated with the new P2TSH nomenclature. Most of us are taking time off this week but @jbride can get to it next week. Contributions welcome, as always. The BIP itself however should be final and is ready for review. |
|
ACK, this is great work! I would highlight it earlier in the BIP that P2TSH is useful outside of the quantum-security context for script-only outputs. You could mention Taproot 2-of-3 multisigs as a concrete example. |
20 participants
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.