This assumes the existence of another asset that provides equivalent or superior properties. For example, a fork of bitcoin that disables DL opcodes could be perceived as inferior due to the precedent it sets with respect to property rights. In addition, the effect of millions of stolen coins is speculative. Bitcoin has survived many extreme drawdowns and it can likely survive them again, and we don’t know what buyers might step in if a flood of coins hits the market. We also don’t know if CRQC attackers would choose to flood the market.
This is a cool idea, though I rather make as few changes in P2QRH as possible.
If I understand you correctly this would prevent long exposure attacks on reused public keys, but not solve short exposure attacks.
You don’t need to change P2QRH to get this. Simply require a preimage and a signature (H(x) == y AND VER(pk, sig, m) == 1) to spend and have a different preimage per leaf. This prevents long exposure attacks even if the public key is reused since the attacker doesn’t know the preimage x. This seems like not reusing a public key but with extra steps.
In P2SH you can do slightly better using the techniques from Signing a Bitcoin Transaction with Lamport Signatures (no changes needed). Though as pointed out by Adam Borcany this scheme functions more like a speed bump since due to the 201 opcode limit in pre-tapscript the key space is small enough to be vulnerable to bruteforce.
You should write this up more concretely. It is an interesting idea.
You don’t need to change P2QRH to get this. Simply require a preimage and a signature (H(x) == y AND VER(pk, sig, m) == 1) to spend and have a different preimage per leaf.
Fair point, more efficient that way, I hadn’t considered that. The other benefits of dynamic script endorsement still stand. I’ll try to write up a draft BIP when I have some free time
1 Like
Whether or not DL opcodes are disabled, users will need somewhere to move their funds to once they become aware and concerned about quantum attack - Whether that occurs in a year or a decade or longer, we need an option ready.
Disabling key-path spending on P2TR is just as technically viable an option as BIP360, but if our long-term plan is P2TR without key-paths, this comes with some UX and DX problems:
- Once QCs are around, how do wallets prevent users from sending funds to quantum-vulnerable addresses, if they look exactly the same as quantum-resistant addresses?
- Before QCs are around, how do users know if their P2TR wallet actually has quantum-resistant leafs attached? A legacy P2TR wallet would mostly look and act exactly the same as a P2TR wallet which has post-quantum leafs. Users would need assurance from the wallet maintainers or to read the source code themselves.
- Naive users who have funds in P2TR may hear “P2TR is now quantum secure” and falsely believe their UTXOs are safe and that no action is needed.
- Bitcoin client authors must now maintain secp256k1 code indefinitely - tap-tweaking the internal key becomes a required step to spend bitcoin even in a post-quantum world.
As for disabling EC opcodes, I am personally in favor of eventually placing a temporary restriction on them, pending a ZK-STARK soft fork which re-unlocks them. See this mailing list thread for info. But certainly that kind of change should not be concurrent with BIP360’s deployment, as it would prevent people from migrating to P2QRH, and as Ethan hinted, it’d also needlessly embroil a perfectly valid BIP in a contentious debate.
Whatever your stance on freeze/not-freeze/zk-starks, we can all agree we need addresses people can migrate towards which are definitively quantum resistant.
2 Likes
“Given that, the current proposal achieves nothing in my mind. No quantum protection is achieved until DL spending is disabled through a separate consensus change, and it can disable that for P2TR just as well as inside BIP360 scripts.”
That’s not quite true though, right? P2TR is vulnerable to long exposure attack via the key path spend. P2QRH disables that, making TapScript safe to use for committing to PQ PKHs. This then gives wallet users the option to spend their coins with either ECC or PQC, depending on which script path they choose. P2QRH makes Taproot useful in a PQ context. Right now it simply isn’t. And if CRQCs never manifest, it’s good that we still have the ECC path.
The alternative is to disable key path spends in P2TR, which could confiscate funds. Personally I’d be very against breaking people’s existing usage of bitcoin even if a quantum threat were active or imminent. There’s not as many coins using P2TR yet anyway in comparison to coins held in P2PKs or reused addresses… 150K vs. 1.7M.
Yes. And I don’t think it’s all that relevant that individual users can choose to migrate their coins if there is no expectation that everyone will (all assuming a CRQC actalually appears). And without widespread agreement that EC spending will be disabled (for P2TR, but much more for the many other types of outputs whose pubkeys are known), I cannot imagine that enough coin owners (many of whom are dormant) will.
Millions of BTC likely will remain in EC-protected outputs even if the option of migrating to something else is possible. In such a situation, nobody’s (value of their) holdings are safe until such time that (nearly) all EC spending is disabled.
1 Like
This seems like a false sense of security at best to me.
If a CRQC appears, I don’t see how BTC can retain any value at all, if EC spending is not disabled. This is not an argument in favor of freezing; it is pointing out that we can ignore potential timelines/blockchain forks in which (crqc exists AND NOT ec is disabled). A chain in which millions of BTC are believed to be stealable fails at its primary function. In such, value is lost anyway, so nothing being discussed here matters.
Thus, for the point of discussion, we can treat any CRQC-having timeline as being one in which EC is disabled, regardless of how, when, why, or in which fork that happens. It doesn’t need to be discussed now even, but we can still assume it happens somehow in such timelines, because the alternative is simply not relevant.
If EC is disabled, P2QRH being available independently of PQC locks seems irrelevant to me, because nobody should be using it without PQC locks. For mixed EC-or-PQC spending conditions, P2TR is strictly better in functionality, privacy, and (typically) cost. For pure-PQC spending conditions, something like P2QRH may be relevant, but there is no way to judge that without an actual PQC scheme (e.g., maybe the scheme supports taproot-like tweaking).
And I could see relevance to P2QRH if it disabled EC from the get-go, because that would mean an observably-PQC output type, which makes it susceptible to policies/consensus rules that mandate at some point that PQC outputs must be used. I don’t think that’s a particularly attractive idea (I feel outputs should reveal as little as possible), but this is what I assumed P2QRH was aiming for when I saw the name and your ML post. However, this appears to not be at all what BIP360 is aiming to achieve, and thus, I fail to see the point.
Lets say tomorrow we wake up and it turns out there has been a breakthrough either a classic algorithm to break EC or a breakthrough that enables quantum computers of the size needed to break EC.
Case 1 (long-exposure vuln, but no immediate short-exposure vuln): This breakthrough allows an extremely well resourced attacker to break a EC public after 1 week of computation, with attack time being halved every two months.
Users can protect their P2TR coins by moving them to P2SH. The LN shuts down since P2SH is pre-tapscript and it will take months to move the protocol away from tapscript. Exchanges which moved to P2TR have to rapidly switch all their wallets to use P2SH. Fees spike as everyone rushes to more their coins away from vulnerable outputs like P2TR.
A soft fork is proposed to disable P2PK, P2PKH, outputs whose public key is known and disable key-spend in P2TR. Maybe it succeeds, maybe it doesn’t. If it succeeds, lots of people lose their money because they didn’t manage move it from P2TR key spends. If the softfork fails, someone will propose a hardfork that freezes these outputs. The coins on the hardfork will likely be more valuable than Bitcoin because there will be much less than 21 million coins on the hardfork.
P2QRH mitigates a some of the harm in case 1 since exchanges and whales will likely have transitioned away from P2TR due to the stronger security of not being vulnerable to long-exposure attacks on EC.
P2QRH + PQ sig opcodes algorithms makes case 1 even easier to deal with since a large number of active users will have P2QRH and a PQ signatures in a tapleaf. Wallets, exchanges and LN will have built out support for it. The main question is to freeze coins or not. If the freeze softfork happens, the coins in P2QRH outputs are protected. If the freeze softfork doesn’t happen and instead there is a hardfork, the coins in P2QRH outputs are protected in both forks.
Case 2 (long-exposure and short-range attacks): This breakthrough allows an extremely well resourced attacker to break a EC public after 1 second of computation.
Total chaos as early Satoshi and modern P2TR coins are stolen. No one can tell between attacker theft and users spending their coins. There is no safe way to secure coins unless you do something like commit reveal but there is not wallet support for that. Bitcoin is no longer able to authenticate ownership of most coins, RIP.
P2QRH does not help much here, but P2QRH + PQ sig opcodes does help. Even in this nightmare can still authenticate ownership of coins for those users that moved away from vulnerable outputs and uses PQ signature opcodes. This makes a freeze softfork or freeze hardfork worth doing since Bitcoin can be saved.
Case 1 is much more likely than Case 2.
However, this appears to not be at all what BIP360 is aiming to achieve, and thus, I fail to see the point.
A PQ-only output is unlikely to get wallet and exchange support because very few people want to pay the much higher fees to spend using a PQ signature algorithm. An extra 32-bytes is fine, an extra 2,000-bytes is not.
There are two ways to do this:
-
P2TR with PQ opcodes with the idea that we freeze all key-spends when EC is broken. This pretends a risk that the freeze doesn’t happen.
-
P2QRH with PQ opcodes which has no key-spends, so it is opt-in. We can start encouraging user’s to move from P2TR to P2QRH.
The PQ opcodes are designed to be in tapscript and work with P2TR as well as P2QRH such that if the community prefers to have core pinky promise they will disable P2TR key spends, then it works with P2TR as well. I just can’t imagine core wants to commit to a controversial promise like that.
For mixed EC-or-PQC spending conditions, P2TR is strictly better in functionality, privacy, and (typically) cost.
If EC is not vulnerable then P2QRH is the NUMS point feature of P2TR in functionality and privacy, but slightly better in cost.