Bitcoin Core Dev: SegWit2x Will Fail, Its Goal Is to Stall SegWit
Bitcoin Core developer Luke Dashjr claims the goal of SegWit2x, a move to provide a minimal patch to resolve the conflict over activating SegWit and increase the block size to allow faster transactions on the bitcoin blockchain, is to stall SegWit.
Writing in Medium , Dashjr says SegWit2x’s beta can be broken into five categories. He begins with branding, the simplest part. Bitcoin Core 0.14.1 has become btc1 Core 1.14.3. The most interesting observation here is that it is based on the old 0.14.1 instead of the 0.14.2 that fixed a number of bugs, such as miniupnpc vulnerability.
Dashjr also does not understand the reason for testnet5, a new testnet. If one wanted to test a bitcoin change, they would do so as a change to testnet instead of making a new one. He does not see why a new testnet was developed.
Some policy changes take effect immediately upon switching to btc1, even ahead of activating a hard or soft fork. Transactions can now use up to 32k sigops instead of the 16k Core limit.
New Size and Sigop Limits
Miners and miner pools linked to a btc1 code claiming to support SegWit will be advised the size limit is 8 MB and the sigop limit 160k. This last part is most likely a bug since it should wait for the hard fork to activate. In practice, this does not make a difference because the block template provided will not overflow the limit. Dashjr is not aware of any miner who will add transactions reaching that limit.
Btc1 has the well-known BIP91 that limits the SegWit activation to 80% for a few days on bit 4. This is primarily the same as BIP148, although it gives miners with a 20% hashrate, such as Bitmain, a veto.
What The Hard Fork Brings
Then comes the actual hard fork. It does not really use bit 4, but it activates 12,960 blocks, 90 days, following SegWit’s activation, no matter how it activates. So even if Bitmain blocks SegWit2x, the btc1 nodes will still hard fork 90 days after SegWit is activated by BIP148. A hard fork will not occur if SegWit does not activate, but BIP148 is going to occur, so it will activate.
The hard fork itself includes an 8 MB maximum block size limit, with the code obfuscated to look like a 2 MB block, a 160k maximum block sigop limit (made to look like 20k), and an 8 M maximum block weight limit (compared to a typical 4 MB block size). As for the sighash scaling, a new 1 MB limit gets imposed on each transaction’s non-witness data.
The first block under the hard fork rules calls for more than 1 MB of non-witness data. Dashjr believes this could have been better accomplished using the hard fork bit to prevent reorgs from also affecting “SPV” light clients.
4 to 8 MB block sizes, according to Dashjr, do not make sense. Even 1 MB blocks have proven dangerous to bitcoin. He does not envision consenting to the hard fork under any circumstances, other than with a soft fork to keep the size reasonable. But even then, he would not support the proposal. If there is going to be a hard fork, some useful changes should be made, such as native merge mining, something Satoshi suggested as the first hard fork years ago. Or fixing some outstanding bugs like the time warp vulnerability.
Also read: Chinese bitcoin roundtable forum affirms support for SegWit2x
SegWit2x Hard Fork Will Fail
Dashjr notes he is not the only one raising these issues, and he asserts that SegWit2x’s hard fork will fail.
SegWit2x’s real purpose, according to Dashjr, is to stall SegWit. He sees it as a distraction form the upcoming BIP148 soft fork that has already deployed irreversibly to the network. In promoting BIP91 and SegWi2x to be a BIP148 alternative, miners are really making another power grab to reclaim their veto, something that only exists as a way for Bitmain to block the whole initiative at the last minute.
If not enough of the economy upgrades to BIP148 by August, Bitmain gains the chance to execute a chain split attack and trick outdated nodes to follow their invalid chain, becoming financially dependent on it prior to grasping the attack’s occurrence.
The only answer is to create awareness of BIP148 and assure as much of the economy as possible has upgraded prior to August, Dashjr claims. This is true whether or not one supports SegWit’s hard fork. Even those opposed to SegWit should make everyone upgrade to BIP148, which does not prohibit SegWit2x or require anyone, including miners, to support SegWit.
BIP148 only requires miners can no longer stop others from adopting SegWit. With sufficient support, miners cannot execute a chain split against old nodes without paying a financial loss. There are no risks to running BIP148 if SegWit2x participants are honest, according to Dashjr. If they are not honest, BIP148 is needed to keep one’s node secure.
Featured image from Shutterstock.
