Saw a new BIP hit the dev mailing list. It’s about making Bitcoin quantum-resistant. I checked the links and found more info on bitcoin.foundation. Thought I’d share this here, see what people think.
New Proposal for Quantum-Resistance in Bitcoin
20 replies 52 views
This BIP looks similar to Lopp's idea about phasing out ECDSA in a few years. But seriously, do we trust the Bitcoin Foundation? Seems sketchy to me.
I disagree, not the same as Lopp’s BIP. Bitcoin Foundation's ownership doesn't make it untrustworthy. Domains like bitcoin.org are owned by others too. Seems like jealousy to me.
I just skimmed through but I’m not a fan. For one, zero references in the BIP itself. Plus, SPHINCS+ signatures are huge. How will that not slow down transactions?
I noticed they mentioned SegWit v3. Looking at the code, max block size is capped at 4 MB. I don’t get why it can’t go higher, like 2 GB. Not sure we’d ever fill that.
Could be a valid point but non-upgraded nodes shouldn’t handle all that data. No need to bump the block size specifically; just set a limit on quantum signatures.
You been around during the 2017 debates? Bigger blocks = big issues. Sure, let’s just throw in 2 GB blocks! SegWit adjustments are minor. SPHINCS+ is tough, not every quantum crypto will hold up.
For the record, bitcoin.foundation isn’t the original Bitcoin Foundation, which died off years ago. The owner has a shady history of domains.
Good thing legacy nodes are 1 MB and SegWit is 4 MB. If you want over 4 MB, those nodes won’t see the data. Quantum signatures should stay separate from old nodes.
They don't clarify how to prevent bloat. Just like SegWit, SPHINCS+ will still be massive and won’t help with blockchain bloat.
But only the upgraded nodes deal with the bloat. Legacy users stick to 4 MB. If quantum security turns out to be a hoax, those new nodes will still have their bloated chains.
Yeah, but blocks with quantum signatures show support for upgrades. Non-SegWit nodes still deal with Ordinal TXs, just without the extra data.
Existing miners don’t need to support this. They can stick to what’s familiar with ECDSA. If their miners do more work, they could confirm faster.
I might’ve missed it. Can you lay it out? How do you go from 50 kB to 50 bytes?
And how do you upgrade from 1 MB to 4 MB? SegWit uses 32 bytes for commitments. Just like that, we can store larger quantum signatures behind the current structure.
ECDSA and R-values? I think we need a bigger block size. 4 MB won’t cut it only a few SPHINCS+ transactions fit in there when today we have a ton.
Same way quantum signatures can be hidden. Old ECDSA signatures could still verify as long as the commitments are intact. Legacy nodes won’t get it.
Interesting take! But why even mix quantum-resistant hashing with ECDSA? If ECDSA is toast, you’re done for regardless.
Not many non-SegWit nodes left anyway. Soon, we might not have to worry about them and just cut them off.
ben.matrixNewbie
Posts: 3540 · Reputation: 35
#20Nov 7, 2021, 09:29 AM
Why not? ECDSA still works. If it fails, we can block it like we do with P2TR keys. If quantum signatures fail too, we can downgrade later.