In a message distributed to the bitcoin-dev mailing list, he criticized the controversial scaling proposal, which is rapidly approaching its August 1 deadline for implementation:
I am utterly appalled by this proposal both technically, ethically, and by the process which it has adopted. Hard forks require consensus from the entire ecosystem in order to prevent a fork, funds loss, confusion and harm to the robust guarantees of the Bitcoin system has thus far displayed.
BTCDrak slammed SegWit2x developers for rushing to implement the proposal, which he said fostered centralization:
For all the talk of how important “alternative implementations” are, how does this rash and rushed action promote an ecosystem of multiple implementors? By encouraging fast upgrades, you are actually centralizing the ecosystem even further.
He contrasted this process with BIP141–the original SegWit–which he said has a higher level of detail and thus results in more testing and confidence. It is offensive, he says, to treat a system that has a $40 billion market cap in such a callous manner as SegWit2x proponents have.
BTCDrak concluded his message by accusing supporters of using coercion to force their agenda on the Bitcoin community.
I cannot support this proposal in the current form and timeline, nor do I support the coercion that has been used behind closed doors to try and gain more support (not limited to, but including approaching company investors to twist arms and veiled threats of blacklisting companies from further funding/collaboration).
He warns that their plan will not succeed.
I think the best you can hope for this hard fork proposal is for it to be quietly ignored.
Other Core Opposition to SegWit2x
BTCDrak is not the first core developer to fire shots in the “Bitcoin Civil War.” Luke-Jr recently composed a blog post analyzing and denouncing SegWit2x. In particular, he criticized the hardfork for including an 8 MB block size limit–which he said was “not sane”–while also obfuscating the code to make it look like 2 MB.
Luke-Jr concluded that the design of SegWit2x fits the purpose of “stall[ing] Segwit longer” and “distract[ing] from the upcoming BIP148 softfork, which is already irreversibly deployed to the network.” However, he clarified that he does not believe all SegWit2x supporters have that nefarious purpose in mind.
Featured image from Shutterstock.