Crypto Developer Warns “Bitcoin Cash May Introduce Fatal Errors”

A new Reddit post published by a core developer at PascalCoin warns that new proposals being made by Bitcoin Cash could bring “fatal errors” to the BCH network. The developers name is Herman Schoenfeld, and he has taken to social media out of what he claims to be a “moral duty” to protect Bitcoin Cash holders from what he perceives to be over-ambitious, and even reckless changes being made to the world’s fourth-largest cryptocurrency.

Schoenfeld highlights 4 key problems in Bitcoin Cash’s proposed update, and his arguments are gaining a great deal of support on social media.

My warning to #BCH about recent proposals. https://t.co/B1WZlsNpJb

— Herman Schoenfeld (@SchoenfeldH) August 24, 2018

“As a full-time core developer at PascalCoin for last 18 months, I have dealt with DoS attacks, 51% attacks, timewarp attacks, mining centralisation attacks, out-of-consensus bugs, high-orphan rates and various other issues,” writes Schoenfeld. “Suffice to say, Layer-1 cryptocurrency development is hard and you don’t really appreciate how fragile everything is until you work on a cryptocurrency codebase and manage a live mainnet.”

Suggested Reading : Learn more about Bitcoin Cash in our beginner’s guide. 

Infinite Block Size

Schoenfeld’s arguments cite 4 major categorical issues with BCH’s proposed tech updates. The first is a proposal for infinite block sizes. Although agreeing that the laws of economics will incentivize miners to  to naturally regulate the size of minted blocks, Schoenfeld believes that influence from “economically irrational actors” like foreign attackers, competing coins, governments, banks etc. could cause serious disruptions to the BCH network:

“Allowing the natural limit of 32mb I think was a sensible move, but adding changes to the network protocol to allow 128mb blocks and then more, does not seem appropriate right now… Blocks are nowhere near the limit right now in BCH. There is plenty of time for security/technical/reliability analysis going forward. The BCH social contract has been established as ‘onchain’ so the risk of a ‘Blockstream 1mb attack’ arising again is far less than that of a serious network instability issue arising from some unknown attack exploiting 100mb blocks. It makes much more sense to leave the blocksize at 32mb until blocks reach ~16mb at which point the technical, security and reliability issues can be better understood and a more informed decision can be made by the BCH community.”

Re-Enabling Opcodes

Bitcoin’s opcodes were initially disabled by Satoshi Nakamoto while the project was still in its infancy due to ongoing bugs and instability arising out of the scripting engine. Scripts have since become standardized, and Schoenfeld believes re-enabling opcodes could be a good thing. However, in order to safely make this transition, Schoenfeld insists that BCH first fix presently unaddressed transaction malleability threats on the network:

“Transactions can be malleated through many areas, including the scripts. What are the consequences of malleability on smart-contract scripts that pay out money based on complex rules? If an attacker can flip a few opcodes, suddenly someone that shouldn’t be paid may get paid? I’m not aware of any such attack right now, but in my professional opinion, I believe such an attack would be possible and would not be convinced otherwise until a thorough security analysis was performed.”

Schoenfeld recommends that a testnet be deployed for a minimum of 3-6 months after these transaction malleability issues are addressed before fully incorporating re-enabled opcodes onto the BCH network.

Infinite Script Size

To compliment re-enabled opcodes, BCH is proposing to enable unbounded script sizes. The hope is that, like infinite block sizes, miners would work to ‘auto-regulate’ these infinite scripts. However, once again Schoenfeld warns that unbounded script sizes open channels for serious attacks made by malicious actors.

“One attack I can foresee here is the introduction of quadratic-hashing attack but inside a single transaction!” writes Schoenfeld.

Schoenfeld continues,

“You have to understand that Ethereum had this problem from the onset and this is why they introduced the concept of ‘GAS’. CPU power is a limited resource and if you don’t pay for it, it will be completely abused. From what I’ve seen, there is no equivalent to GAS inside this proposal.

To understand the seriousness of this issue, think back to Ethereum’s network instability before the DAO hacker. It went through many periods of DoS attacks as hackers cleverly found oversights in their opcode/EVM engine. This is a serious, proven and real-world attack-vector and not one to be ‘solved later’. The BCH network could be brought to a grinding halt and easily with unbounded script sizes that do not pay any gas.”

Voting/Singaling/Testnet

Schoenfeld’s final word of warning pertains to the apparent neglect on the part of BCH to hold itself to a process of group voting, well-defined PIP design, and careful testnet protocols before implementing major changes to the platform.

“There is no excuse for BCH! It is a multi-billion dollar network and changes of this magnitude cannot be released so recklessly in such short time-frames,” says Schoenfeld.

Rounding out his discussion, Schoenfeld says,

“I hope these comments are considered by stakeholders of BCH and the community at large. I am not a maximalist and support BCH, but the last week has revealed there is a serious technical void in BCH! The Bitcoin Core devs may not know much about economics, but they did know some things about security & reliability of cryptocurrency software.”