Dr. Pieter Wuille: Current Bitcoin Protocol Is 'Not Quantum Secure'

William Casarin, a Haskell and Rush computer programmer, has suggested not using taproot (or at least carefully considering the implications), a recently published Bitcoin Improvement Proposal (BIP) that aims to enhance the leading cryptocurrency’s privacy and overall network efficiency.

Casarin, a Vancouver-based game developer, pointed out via Twitter that taproot is “pay to pubkey, not pubkey hash.” He also questioned why the Bitcoin (BTC) protocol developers would integrate the “complicated script validation logic” associated with BIP-Taproot as the cryptocurrency’s codebase “might be insecure in 30 years” from now.

In response to Casarin’s comments, Mario Gibney, the Customer Support Team Lead at Blockstream, said that he was surprised as he had not heard about it before. Casarin also asked:

Is it possible to have a pay to pubkey hash version of taproot?

According to prominent Bitcoin Core developer Dr. Pieter Wuille, hashing public keys “doesn't add any security.” Wuille, co-founder at Blockstream, added that “the widely repeated claim that it protects against quantum computers is nonsense.” He also clarified that “anyone who ever reused an address, or shared an xpub (or used Electrum) has their pubkeys already public.”

“Bitcoin Outputs Aren’t Secure Against a Quantum Computer Even When They’re Hashed”

Responding to Wuille’s statements, Casarin noted that there are “theoretical proposed algorithms for quantum attacks on pubkeys, but not hashes.” The physics enthusiast then questioned Wuille’s claim regarding hashing public keys not being able to enhance security.

He acknowledged that pay to script hash (p2sh) may have “reduced” security “due to collisions”, however he asked Wuille to point out the the main arguments that suggest “pubkey attacks impossible.”

Wuille remarked:

Taproot, a “Neat Idea”

Casarin then argued that you could “buy yourself some in the inflight case.” He also mentioned that if he we was operating a QC, then he’d focus on “the already exposed outputs.” Casarin further noted:

I can't imagine ever using taproot for that reason. Pretty neat idea otherwise.

In response, Wuille stated:

If there's ever evidence of theft due to a QC, and 5M BTC are readily available for the taking to such a hypothetical machine, do you think BTC will still have any value left?

According to Casarin, the only way Bitcoin would manage to survive is if users were aware of the fact that they can “at least move to quantum secure outputs.”

Current State of QCs: IBM Has 50 Qubits, Google 72

Meanwhile, Wuille mentioned: 

Any unconfirmed transaction in flight exposes public keys, so if a QC exists, at least moving coins around safely becomes impossible. Further, a massive fraction of the currency supply can be taken. Lastly, you likely have exposed your own pubkey already.

He added:

Given all those hypothetical attack models that pubkey hashing doesn't help with at all, I think it's fair to say that Bitcoin as it exists today is not quantum secure, period.

Confirming that QCs exist today and elaborating on their current state of development, Twitter user Noclone3 pointed out “QCs do already exist in a primitive form, namely, not error corrected. IBM has 50 qubits, Google 72, Rigetti should deliver 128, IonQ 160. The burden of error correction depends on the number of needed operations (gates) and should be of the order of 1000 qubits x logical qubit.”

Block.one CEO Responds to Coinbase’s Complaints About EOS Network’s Performance

Siamak Masnavi

On Tuesday (February 25), Brendan Blumer, Co-Founder and CEO of Block.one, (the company that develops the EOSIO protocol that powers the EOS platform), responded to Coinbase's concerns about EOS network's "degraded performance levels."

Here is how it all started...

On February 20, Coinbase said via a system status report that "EOS network has degraded performance" and that it was "investigating this issue".

Then, on February 22, Coinbase Support tweeted about the EOS network's "degraded performance levels", linking to the aforementioned status report:

One of the leading EOS block producers, EOS Nation, sent the following reply to Coinbase Support's tweet:

Earlier today, the Block.one CEO sent a series of tweets to explain that the performance problems being experienced by Coinbase were not because EOS was too slow, but rather the opposite, i.e. that the most likely explanation was that the architecture Coinbase's applications for regulatory reporting needed to be improved to so that these applications could keep up with the speed and volume of EOS transactions:

He also said that Block.one is trying to help Coinbase with "their performance issues":