Topic: Bitcoin with Post-Qunatum Cryptography Feature (Read 207 times)

Okay, perhaps "decades" is indeed a bit too far away. The earliest estimation a quantum computer is expected to achieve hundreds of thousands of qbits (which would be necessary to break ECDSA keys in years) I've read about is around 2030 (that's an IBM estimation). That would be a very expensive device (more than a billion USD). Yes, that would be only five or six years away. But would such a device, a first of its kind, be used to crack Bitcoin private keys during years? I doubt it. It would take several years more for a device which would be accessible to criminals or even state-level actors (and I don't expect the US or China being likely to do that, but instead North Korea with far less resources). A decade is thus the minimum time I expect until really a threat emerges.

I think it is not out of place to start a discussion about a post quantum implementation on Bitcoin, but there is also no need to hurry and to push an implementation of a developer team who came out of nowhere and seems not to be familiar at all with the Bitcoin Core BIP/development process. I don't say the QbitsQ people couldn't learn, but criticism about fearmongering should be allowed. I think if around 2030 Core has a BIP ready to be implemented it would be reasonable.

There are of course several other proposals about achieving quantum safety in Bitcoin, like this one, and I have even read (several years ago) about the idea to use Simplicity (a more expressive scripting language) to implement different post quantum cryptosystems.

Thanks Saint-loup, that's why we said 'Time flies'.

You are a bit too optimistic in my opinion. In 2022 researchers in quantum computing estimated at 13 × 10⁶ physical qubits what was necessary to break a BTC public key within one day. And they've evaluated the time to reach this threshold at over 10 years. But what will happen if a team somewhere in the world decide to attack a public key during weeks or months instead of 24h only? They wouldn't need millions of qubits but much less than that. And if they manage to do it, people won't say it's just one single public key, and they took months to realize it, they will just think Bitcoin has been cracked and is not reliable anymore, its price will crash. So the issue could start to be critical in just several years, maybe less than 8 years actually if we consider this kind of attack.

https://pubs.aip.org/avs/aqs/article/4/1/013801/2835275/The-impact-of-hardware-specifications-on-reaching

A new issue under 'Feature Request' was submitted for review and feedback.

https://github.com/bitcoin/bitcoin/issues/31485

I don't agree that "time flies". I guess we should solve the post-quantum problem in the next decade, but Willow isn't even the start of a potential threat. While it improves on error correction for an ECDSA break still 4-5 orders of magnitude in terms of qbits are needed to solve P2PK in a few years.

My problem with your contributions here is not so much of technical nature, but of the communication. Aggressive marketing language like in the alt/memecoin world, and fearmongering like in the poll and in your last post does not improve the credibility of your project.

If you want to have any success with the pqc-Bitcoin feature you should really re-think about the way you communicate.

By the way, https://github.com/QbitsQ still doesn't work (mistercoins's first question), and I don't think you wanted to link to https://github.com/Qbits. I also don't see your proposal in the developer mailing list even if you claimed you added it there.

Thank you so much, the subject has been transferred to Bitcoin Developers conservation group!

[/quote]

---

Greetings again, you have valid questions if any doubts, we have suggestion, just simply contribute in this repo (https://github.com/QBlockQ/pqc-bitcoin) in terms of code and testing of the new integrated cryptography that will permanently eliminate the quantum threats and as you can see yesterday Google announced of Wilow which could potentailly break RSA as the responce of question on the largest semiprime that can be factored!.  Time flies, and this repo with Bitcoin developers consesus will put it safely & security forever!

Maybe start a new discussion on either https://groups.google.com/g/bitcoindev/ or https://github.com/bitcoin/bitcoin. But don't forget rules stated on those community.

I'm sorry, I'm still a bit skeptical, and I will still not remove the warning above. How can the Bitcoin Core community delete a fork if the fork is in the repo of another user? Or did you try to create a branch in the Bitcoin Core repo? This would be of course not the way they work, so it would be understandable if they removed it.

I would highly recommend to repeat the fork and re-apply the commits, so the code history gets preserved. Before you even think about a pull request in the Bitcoin Core repo I would also create a BIP, although of course, you should first try to get some comments.

At a first glance your main commit itself doesn't look suspicious, but I haven't looked deep into it nor into other commits, nor am I really an expert in the field. I'm only skeptic because your account is new and you probably made some mistakes regarding your communication, for example it is in the wrong subforum (and this could make one think that someone is trying to capitalize from the recent Google willow chip reveal) and the real character of your update wasn't really clear.

v28.0 then? Or the latest master commit? The exact Github commit would be nice to know.

Just to preserve integrity: is the initial commit of your repo exactly the Bitcoin Core version or does it already contains additions?

Okay, that makes more sense. Should have been mentioned from the start.

he SegWit-style PQC implementation has been successfully pushed. Here's what we've accomplished:

1. SegWit Integration:
PQC signatures now stored in witness area
Reduced impact on block size through witness discount
Backward compatibility with old nodes

2. New Address Format:
Added Bech32m support with witness version 2
New bc1z prefix for PQC addresses
Compatible with existing wallet software

3. Validation Updates:
Modified validation logic for witness-based signatures
Implemented proper weight calculations
Maintained hybrid signature approach

it is now addressing both the block size concerns and backward compatibility issues.  BTW, we need any comments in Github and we need also Bitcoin Core community consensus.

I don't like this approach. With small block size limit (1 vMB or 4 million weight units), it would drastically reduce Bitcoin TPS (transaction per second). I prefer SegWit approach where it's activated some time after 95%+ recent blocks signal SegWit support, where old nodes only see anyone-can-spend TX.

And looking at https://github.com/QBlockQ/pqc-bitcoin/blob/main/doc/pqc.md, there's no mention it would use Bech32m address with witness version 2 (a.k.a. address with bc1z prefix).

Codebase was forked previously but Bitcoin core community deleted it so we created a new repo.  Technically speaking, implementing this pqc as explained in this repo will eliminate the quantum threats forever!

[/quote]

---

1.  Already responded to mistercoin's question.
2.  Latest Bitcoin Core version.
3.  We provided the required integration of 3 post-quantum cryptograph namely keber, FrodoKEM, and NTRU which also support for hybrid key generation and signing
4.  HybridKey class for managing both classical and PQC keys and Integration with Bitcoin's existing key management system.
5.  Post-Quantum Cryptography (PQC) aims to address the vulnerabilities of current cryptographic systems like ECDSA, which are not secure against quantum computers.
5.  Soft fork was implemented to maintain backward compatibility, and below is simple explanation of how miners/nodes validate the new PQC transactions:

A.  Old Nodes (not PQC):
     1. Only see and validate the classical ECDSA signature
     2. Ignore the additional PQC data (they treat it as anyone-can-spend)
     3. Continue working as normal

B.  New Nodes (PQC):
     1. First validate the classical ECDSA signature
     2. Then validate the PQC signature
     3. Transaction is only valid if BOTH signatures are valid
     4. Reject if either signature fails

C.  Miners:
     1. Old miners: Mine transactions based only on ECDSA
     2. New miners: Mine transactions only if both ECDSA and PQC signatures are valid

This creates a soft fork where new rules are stricter than old rules.  This dual-signature approach ensures backward compatibility while gradually transitioning the network to quantum resistance.  This dual-signature approach ensures backward compatibility while gradually transitioning the network to quantum resistance.

[/quote]

@mistercoin: Indeed.

OP, please provide more information on mistercoin's question and also:

- which version of Bitcoin Core is the base for this one? (best practice would be to deliver the exact Git commit, so a diff can be done!)
- what changes were done to Bitcoin Core?
- what exactly can you make "quantum resistant" with this Bitcoin Core version?

There is the file pqc.md which provides some more info, but it is still not really clear how it works alongside the Bitcoin protocol. In my opinion, according to the description of the "hybrid" system, the keys would be compromised if one of both algorithms "break", so it would be even less secure than the "pre-quantum" ECDSA cryptosystem which is used today.

On the other hand, how would miners/core nodes validate the "new" kind of transaction?

Until this is not answered this may be possibly a wallet stealer, so don't install it until the OP hasn't answered the questions and detailed the changes!. I'm sorry OP but there are a lot of scams of this kind, and it could be possible that someone wants to capitalize from the fear of quantum computers.

The thread is imo also in the wrong subforum as this isn't a support topic, it should go into Project Development or Development & Technical Discussion.

Curious.. https://github.com/QbitsQ is non existent? Why is the codebase not forked from Bitcoin's core? People won't be able to view and review easily without all the commits you have created. Don't mean to be rude, but this is sketchy. Please prove me wrong.

Greetings all,

QBlock with the help of Qbits, implement PQC in the bitcoin core for your review and concuss.  Thanks


https://github.com/QBlockQ/pqc-bitcoin.

Implementation Status:
The core PQC algorithms (Kyber, FrodoKEM, NTRU) are implemented
The hybrid key management system is in place
Transaction signing with PQC is integrated
Configuration options are available

QBlock