Search content
Sort by
Showing 11 of 11 results by nameisnotknown
Re: Bitcoin must upgrade or fall victim to quantum computing in 5 years
Do you think that an average person will have access to quantum computer? They'll have access to it when everything will be quantum resistant. Good luck building a quantum computer yourself and good luck stealing or selling US, Russia and Chinese intel.
I believe we are on the same set of mind. If the internet will be ready by the time quantum computing reaches hands of average people then I highly, HIGHLY doubt Bitcoin will not be secured against it. If it is not secured within the right time, clearly Bitcoin will either die or at least a ton of us will lose faith and get out.Considering it is being worked on however, I do not see why it should be a scare. If quantum computing will be announced to be ready for consumer end in less than 6 months, I also highly doubt there will be no group of people who will work hard on making Bitcoin secure against it in two to three months, way before any thing bad can happen to it.
Actually there are many companies with quantum-computers offering free use. You can use IBM, Google, and after approval even D-wave (has about 2000 qubits, they claim).
Re: [Draft BIP] Quantum-Resistant Transition Framework for Bitcoin
⭐ Merited by vjudeu (1)
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 simple "kick them off" from the network.
Quote
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.
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 simple "kick them off" from the network.
Re: [Draft BIP] Quantum-Resistant Transition Framework for Bitcoin
Quote
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.
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
Re: [Draft BIP] Quantum-Resistant Transition Framework for Bitcoin
⭐ Merited by vjudeu (1)
Quote
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.
Maybe I didn't read everything well. Can you explain this in details? How you make 50 byte from 50 KB?
Re: [Draft BIP] Quantum-Resistant Transition Framework for Bitcoin
⭐ Merited by vjudeu (1)
Quote
2. They chose SPHINCS+ which have 49,856 bytes. Without also proposing to increase block size, it would massively reduce TPS (transaction per second).
On the website https://quantum-resistant-bitcoin.bitcoin.foundation they mention SegWit v3+:
Quote
SegWit v3+ witness structures efficiently accommodate large signatures without blockchain bloat, while priority mempool treatment for QR transactions during transition phases creates economic incentives for adoption.
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
Code:
/** The maximum allowed size for a serialized block, in bytes (only for buffer size limits) */
static const unsigned int MAX_BLOCK_SERIALIZED_SIZE = 4000000;
/** The maximum allowed weight for a block, see BIP 141 (network rule) */
static const unsigned int MAX_BLOCK_WEIGHT = 4000000;
/** The maximum allowed number of signature check operations in a block (network rule) */
static const int64_t MAX_BLOCK_SIGOPS_COST = 80000;
static const unsigned int MAX_BLOCK_SERIALIZED_SIZE = 4000000;
/** The maximum allowed weight for a block, see BIP 141 (network rule) */
static const unsigned int MAX_BLOCK_WEIGHT = 4000000;
/** The maximum allowed number of signature check operations in a block (network rule) */
static const int64_t MAX_BLOCK_SIGOPS_COST = 80000;
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.
Re: [Draft BIP] Quantum-Resistant Transition Framework for Bitcoin
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 it's 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.
I see the domain https://bitcoin.foundation and it's 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.
This topic is related: https://bitcointalk.org/index.php?topic=5553484.0
Re: If BIP360 is accepted, will people with no seed phrase wallet be able to recover
This topic is related: https://bitcointalk.org/index.php?topic=5553484.0
Re: Bitcoin must upgrade or fall victim to quantum computing in 5 years
How a "puzzle" is related to "Bitcoin must upgrade or fall victim to quantum computing in 5 years"? You just spamming now. Open a new topic somewhere else with your "puzzle".
[Draft BIP] Quantum-Resistant Transition Framework for Bitcoin
⭐ Merited by ABCbits (2)
On the Bitcoin Development Mailing List there is a new BIP proposal: https://groups.google.com/g/bitcoindev/c/2mQEyxHUskc
While I was looking at the link in the BIP (https://github.com/bitcoin-foundation/Quantum-Resistant-Bitcoin) I found the domain https://bitcoin.foundation and in there today I found another link that points to https://quantum-resistant-bitcoin.bitcoin.foundation
Personally, I think this BIP is better than what is proposed previously regarding "post-quantum in Bitcoin". I decided to open a topic on BitcoinTalk, maybe someone is interested in this.
While I was looking at the link in the BIP (https://github.com/bitcoin-foundation/Quantum-Resistant-Bitcoin) I found the domain https://bitcoin.foundation and in there today I found another link that points to https://quantum-resistant-bitcoin.bitcoin.foundation
Personally, I think this BIP is better than what is proposed previously regarding "post-quantum in Bitcoin". I decided to open a topic on BitcoinTalk, maybe someone is interested in this.