There’s a fresh BIP proposal up on the Bitcoin Development Mailing List: check it out here.
While browsing through the link in that BIP, I stumbled upon the domain bitcoin.foundation and found another link that leads to quantum-resistant-bitcoin.bitcoin.foundation.
I gotta say, I think this new BIP is a step up from the previous ideas floating around about making Bitcoin post-quantum secure. Thought it’d be cool to start a discussion here, in case others are curious about it.
That BIP is essentially the same than J. Lopp's BIP regarding timelines and a deprecation of ECDSA within a short timeframe (2/5 years).
In addition, the "Bitcoin Foundation" which has posted the BIP doesn't really look trustworthy.
The only really notable change is that they propose a cryptosystem based on SPHINCS+, which has a signature size of 49,856 bytes - more than 20 times the current ECDSA signatures. Imagine each input of a transaction having to carry that weight ...
So no, I don't think this is really worth discussing.
I don't see how this BIP is the same as J. Lopp's BIP. I also don't see any problem with the "Bitcoin Foundation" because for example Cobra-Bitcoin owns bitcoin.org and Matt Corallo owns "bitcoin.ninja" (while he is not a "ninja" he use that Bitcoin domain) this by no means makes him less trustworthy.
I see the domain https://bitcoin.foundation and its BIP related subdomain https://quantum-resistant-bitcoin.bitcoin.foundation nothing more than another Bitcoin website. Probably when someone speaking like you are simply jealous. If bitcoin.foundation is not trustworthy than none of the bitcoin.tld's are. But this is just my opinion, you free to have other opinions on this matter. It's just not fair to claim that who owns such a domain is not trustworthy. Well, if I look at bitcoin.tld domains in any registrar I see that all domains that is in the format of bitcoin+tld are taken already. I don't understand how this would make all of them "not trustworthy". Again, this is just my opinion...
Regarding the signature size I actually found on the website https://quantum-resistant-bitcoin.bitcoin.foundation a very simple solution and that is called SegWit. SegWit can be used easily for this large signatures. Currently SegWit has a "block size" limit of 4,000,000 bytes and it can be increased as well with a soft fork to any size really.
Regarding Jameson Lopp's BIP proposal; you should read the header of that BIP because there you can see that he is not the only one who has interest in pushing for that BIP but also some Canadian corporation that selling Bitcoin wallets that claim to be quantum-resistant. Basically, if they succeed they will flow the market with their Bitcoin wallet for which you must pay. I got this information from another post here on BitcoinTalk: https://bitcointalk.org/index.php?topic=5550298.msg65666459#msg65666459
Also it appears that Jameson Lopp's wikipedia page is deleted: https://en.wikipedia.org/wiki/Jameson_Lopp No wonder why... He claiming to be a "cypherpunk" and other things without ever contributing to Bitcoin any meaningful way. He well deserved to be deleted from wikipedia in my opinion.
I only skimmed it, but don't like it due to few reasons.
1. Both BIP and details on GitHub have zero references.
2. They chose SPHINCS+ which have 49,856 bytes. Without also proposing to increase block size, it would massively reduce TPS (transaction per second).
I recall Bitcoin Foundation had major internal and external issue many years ago and i almost never hear about them afterwards.
Do you mind telling us what makes you think this BIP better than other proposal/BIP?
On the website https://quantum-resistant-bitcoin.bitcoin.foundation they mention SegWit v3+:
When I look at this: https://raw.githubusercontent.com/bitcoin/bitcoin/refs/heads/master/src/consensus/consensus.h I see that the max "block size" is limited to 4 MB
I don't see why it cannot be increased to the extreme, let's say to 2100000000 bytes (2.1 GB). I don't think there will be ever so much transactions in the block to take up all that huge space.
Example, calculate with let's say 55 KB (SPHINCS+-SHAKE256f signature + other transaction data).
Currently in one block there are approximately 2-5000 transaction the max.
So:
5000 x 55000 bytes = 275,000,000 bytes or 275 MB (With a connection speed of 50 Mbps it would take approximately 46 seconds to download the block, if the network speed is 1 Gbps then the download of the block would take around 2.2 seconds)
So even if the 4000000 bytes is changed in Bitcoin's SegWit to just 275000000 bytes, it would handle up to around 5000 transactions / block.
This is why I think this BIP is much better than other proposals. It is proposing a new version of SegWit (SegWit v3+) as a solution to the large signature size that SPHINCS+ produces with SHAKE256f. To implement it wouldn't need to change much in Bitcoin and far as I see it wouldn't be a "hard fork" either.
It could be. But: non-upgraded nodes should not process all of that data. And, you don't have to increase maximum block size specifically. Instead, quantum commitment size can be restricted.
For example: if quantum signatures will take 50 kB per signature, then let's make it as a commitment limit per sigop. Then, for a block sigops limit of 80k, we would have 4 GB limit per block. And if there would be any need to do a downgrade, then coins could be moved in a way, which would be understood by old nodes.
In this case, each and every OP_CHECKSIG call will check two things: one, which is ECDSA correctness, and another one, which is quantum proof correctness. Then, private keys can stay as they are, and R-value of a given ECDSA signature can contain SHA-256 commitment to any quantum signature, which would be handled only by quantum enthusiasts, while everyone else could enjoy 4 MB limit, and see just regular ECDSA signatures.
If hashrate majority will run quantum-resistant version, then the block size limit would be just 80k sigops * max quantum signature size. And then, for different quantum proposals, that limit can be different, while keeping the same sigops limit per block, so handling roughly the same number of individual on-chain users per block.
Lol. Decentralization vs. big blocks, were you around in 2017 and did you actually understand what the whole debate was about? Yes, let's create a second Bitcoin SV with 2 GB (or 275 MB, doesn't matter) blocks, but with quantum safe signatures ...
Using Segwit or not is a tiny detail. I think even Lopp has written about that possibility of a change in weight. Hash-based cryptography like SPHINCS+ would be a stronger argument, as some devs have stated that other quantum safe cryptosystems may not be safe enough. (edited)
About Jameson Lopp's conflict of interest, I have no idea about that, but honestly I would not be surprised if there was one. But a BIP should be decided upon by strictly technical and game theory related reasons. (Yeah, my remark about the "Bitcoin.foundation" may conflict a bit with that, but it simply doesn't look good if you try to pretend to be someone who you aren't. I guess for these reasons this "BIP" has got not much attention.)
Just for the record, the bitcoin.foundation domain has nothing to do with the actual Bitcoin Foundation, which hasn't been relevant since 2015, and whose tax exempt status was revoked in 2022 (meaning it no longer exists in any meaningful form). Here's some background info on the issue (tl;dr: the owner has a history of registering domains similar to those of well-known organizations).
Fortunately, the maximum block size for legacy nodes is 1 MB, and for Segwit nodes is 4 MB. If someone wants bigger blocks than 4 MB, then by running the current version, you simply won't see their data. And in general, I think no matter if block size will be bigger or smaller than today, quantum signatures should not be processed by existing nodes, because they don't know, how to handle it (and different quantum proposals may have different needs). Unless you know, how to re-write any quantum signature as a bunch of OP_CHECKSIG operations, along with other Script opcodes, then it could be visible by non-quantum nodes.
Also, I guess if OP_CHECKSIG will be really broken, then it could be possible to activate quantum signatures on top of OP_CHECKSIG directly. Because then, if quantum signatures use some 256-bit numbers internally, then OP_CHECKSIG can be used as their 256-bit calculator, and then, any public keys could be used anywhere, because going from public to private key can be just part of the process. Because even in Shor's algorithm, going from public to private key doesn't have zero cost: even if it is solvable, then it still require N quantum operations. Which means, that by creating dependencies between public keys and signatures, it can be made much harder, than just "<pubkey> OP_CHECKSIG".
They don't explain how it prevent bloat. But it works just like SegWit, it means SPHINCS+ signature data still have size 49,856 bytes while have less size if you use unit weight or virtual byte which doesn't prevent blockchain bloat.
No, it would open gateway to massively bloat Bitcoin blockchain at relative low cost. Ordinals hype in past have proven this. There are other technical issue such as time to verify and propagate block with such massive size.
And that cost will be paid only by upgraded nodes, so they can do that, if they want to. The rest of the users will still enjoy 4 MB limit. And then, if it will turn out, that all quantum FUD was unjustified, and there is no danger, then these new nodes will have their own bloated version, which they voluntarily picked, so they can leave legacy traffic unaffected.
Only Segwit nodes are affected by Ordinals. Old, legacy nodes, see smaller blocks in practice, when witness space is fully filled. And the same will happen, if Ordinals will move their data into quantum signatures: we will see smaller than 4 MB blocks in witness space, which is good.
It is possible to use more than one layer of verification. Currently, there are at least two: one is legacy data verification, and another is witness data verification. If we would have a third layer of quantum commitments, then Segwit nodes will be unaffected, and process only ECDSA signatures, without checking, what is behind R-value of each and every signature.
So, to sum up: if quantum enthusiasts want to have enormously huge blocks, then it is their choice. If they raise it by too much, then only their nodes will suffer, so we shouldn't stop them from shooting themselves in their feet. And if one quantum proposal with big signatures will lose competition with another quantum proposal with smaller signatures, then again, it is their choice, if they want to consume more space, or if they want to spend more time on verifying smaller signatures. They should compete with each other, so that Segwit users will be unaffected, and they will pick the final winner, if we will see, who did it in the best way.
I get your point. Although the fact there are blocks that contain QC-resistant signature means some mining pool support the upgrade.
It's not fully true though, since non-SegWit node still store TX created by Ordinal without witness data.
They don't have to get support from existing miners, focused on mining 80-byte block headers. They can do that behind Proof of Work on DER signatures, so legacy nodes will check only the size of the signature, and nothing else. And all other rules can be executed only by quantum nodes, and nobody else. If their miners will produce more Proof of Work, that any attacker will do in 10 minutes, then they will get it confirmed on-chain faster, than it will be attacked by anyone. And if their quantum proofs will be good enough, then nobody will even discover a public key behind the puzzle, before it will be broadcasted on-chain. It can be unknown for all participants, even behind quantum nodes, if done correctly, and Proof of Work can protect them from short exposure attacks, as long as ECDSA is still strong (and even later, SHA-256 will still protect them, even if ECDSA will be broken, just Proof of Work will raise accordingly).
Yes, there is some data, related to a particular address. But: seeing OP_TRUE, and some 32-byte data push for Taproot address, is not that much. And similar things can be done here: a small signature on-chain, which would take for example 50 bytes, is a small price to pay for committing to some 50 kB signature, which would be visible only by upgraded nodes, and which can be ignored by anyone else.
And how you make 4 MB out of 1 MB? You have 32 bytes for Segwit commitment in the coinbase transaction, and this is all you need, to go from 1 MB legacy space to 4 MB witness space. Here, it is similar: you have 32 bytes for R-value of ECDSA signature, and you can store everything behind it, including a quantum resistant 50 kB signature, for each and every R-value you currently have, when OP_CHECKSIG or its equivalent is called in the Script.
Of course, all old nodes won't notice block size increase, in the same way, as non-Segwit nodes still think, that the maximum block size is 1 MB.
I don't understand how ECDSA and the R-values comes here into play. I think "block size" need to be increased to accommodate larger signatures. 4 MB is not enough at all. 4 MB can only include approximately 70x transactions with SPHINCS+, while currently there are 3-5000 transactions in a block. See what I described previously: https://bitcointalk.org/index.php?topic=5553484.msg65677531#msg65677531
In the same way, as quantum-resistant signatures can be hidden behind P2TR.
https://gnusha.org/pi/bitcoindev/ZVcdKupXU+wjawRI@erisian.com.au/
In general, if you have ECDSA signature, then you have some public key Q, and signature (R,s), which can connect public key R with public key Q. If ECDSA is broken, then still: "data" behind a given commitment will still be possible to verify. Knowing private key won't invalidate old signatures: if some hash was confirmed on-chain, and hidden behind R-value of some signature, then it will be still possible to verify later.
Old nodes won't understand it anyway. Which means, that only quantum resistant nodes will see it. And for that reason, ECDSA verification can be just extended: first, ECDSA signature will be checked normally, and after that, quantum data can be hashed, and checked, if it matches R-value of a given signature. And then, new limit don't have to be based on block size, but on commitment size instead, and based on existing sigops limit.
Interesting, but if someone attacking ECDSA with a quantum-computer doesn't make much sense to use quantum-resistant hashing along with ECDSA (which is very likely getting broken) because the attacker can take everything regardless.
Regarding the old nodes: There isn't much nodes that are not segwit compatible. I think in a few years (like it is proposed to switch to quantum-resistant algorithm) we can completely ignore old nodes and simply "kick them off" from the network.
Why not?
1. As long as ECDSA is safe, it will work, and will take small amount of on-chain bytes.
2. When it will be unsafe, then spending only by ECDSA can be blocked, in exactly the same way, as spending only by key in P2TR can be.
3. If some quantum proposal will be broken classically, it will be possible to downgrade it, and old nodes will still understand it.
4. It is strictly connected with sigops limit, so you can handle the same number of signature checking operations, as old nodes did.
Sure, but it shouldn't be your starting point, but rather your end goal. First, things should be optional, because if they will be mandatory from the start, then it will be quickly turned into hard-fork, and will end in the same way as BCH, and other forks. So, the first thing to do, is to get a compatible client, which will work on the same chain, as existing clients. And because they cannot understand bigger blocks than 4 MB, then new signatures should be somehow attached to the existing ones. And it is much easier to attach them through R-value, than through additional OP_RETURN, because then, it takes less on-chain bytes, and can provide the same security (if someone can fake R-value, then that person can fake OP_RETURN entry as well).