The Segwit”2x” beta, review and thoughts
The changes in Segwit2x’s beta can be divided into 5 categories.
I’ll start with the simplest part: branding. “Bitcoin Core 0.14.1” has become “btc1 Core 1.14.3”. Not much to say about this (although it’s interesting to note it’s based on the old 0.14.1 rather than 0.14.2 — which fixed a number of bugs including a miniupnpc vulnerability).
Next up is “testnet5". It’s a new testnet, for reasons never made clear to me. It would seem if you wanted to test a change to Bitcoin, you’d test it as a change to testnet rather than make a new one. It’s not clear to me why a new testnet was created instead.
There are a few policy changes that take effect immediately upon switching to btc1, even before any softfork or hardfork activates. Most notably, transactions are now allowed to use up to 32k sigops, rather than the 16k limit in Core.
Additionally, pools/miners connected to a btc1 node that claim to support Segwit2x will be told the size limit is 8 MB, and the sigop limit 160k. This last part is probably a bug (it should wait for the hardfork to activate), but in practice, it doesn’t matter since the actual block template given won’t overflow the limit, and I’m not aware of any miner that will actually add transactions up to the limit.
btc1 includes the now-well-known BIP91, which reduces the Segwit activation threshold to simply 80% for a few days on bit 4. It’s essentially the same as BIP148, but allows miners with 20% hashrate (ie, Bitmain) a veto.
Finally, we get to the actual hardfork. It does not actually use bit 4 at all, but activates 12960 blocks (90 days) after Segwit activates, no matter how Segwit is activated; this means that even if Bitmain blocks Segwit2x, btc1 nodes will still hardfork 90 days after BIP148 activates Segwit. (Clarification: A hardfork wouldn’t happen if Segwit never activated at all, but BIP148 is happening, so Segwit will definitely activate.)
As for the hardfork itself, it includes an 8 MB max block size limit (with the code obfuscated to make it look like 2 MB), a 160k max block sigop limit (obfuscated to look like 20k), and an 8M max block weight limit (ie, typical block size around 4 MB). To address the sighash scaling issue, a new 1 MB limit is imposed on each transaction’s non-witness data. To avoid being at risk of the original Bitcoin overwriting its chain in a reorganisation, the first block under the hardfork rules is required to have more than 1 MB of non-witness data (a better way to do this would have been to use the hardfork bit, which would prevent reorgs from affecting “SPV” light clients also).
Now for my thoughts: 4–8 MB block sizes are not sane. Even 1 MB blocks are already clearly dangerous to Bitcoin. I cannot foresee myself consenting to the hardfork proposal under almost any circumstances, except perhaps with a softfork to limit the size to something reasonable. Even then, I would still not positively support this proposal: if we are going to hardfork, we should actually make some useful changes in it (for example, native merge-mining, as Satoshi suggested as the first hardfork many years ago), not to mention fix some outstanding bugs (such as the time warp vulnerability). I am certainly not by far the only person with these concerns, so I can say with a relatively high level of confidence that Segwit2x’s hardfork will fail.
Overall, Segwit2x seems to have one real purpose*: to try to stall Segwit longer. It is a distraction from the upcoming BIP148 softfork, which is already irreversibly deployed to the network. By promoting BIP91 and Segwit2x as an alternative to BIP148, what miners are really doing is another power grab to try to take back their veto, which has no purpose other than to be used by Bitmain to block the whole thing at the last minute. If too little of the economy has upgraded to BIP148 in time for August, it gives Bitmain the opportunity to perform a chain split attack, and fool outdated nodes into following their invalid chain, possibly becoming financially dependent on it before realising the attack has occurred.
The only solution to this is to spread awareness of BIP148 and ensure as much of the economy as possible has upgraded before August. This is true whether or not you support Segwit2x’s hardfork — in fact, even if you oppose Segwit, you should still help ensure everyone is upgraded to BIP148. BIP148 does not prohibit Segwit2x, nor does it require you or anyone else (not even miners) to even support or use Segwit themselves. The only thing BIP148 requires, is that miners can no longer stop others from adopting Segwit, and with enough support, that miners cannot perform a chain split attack against old nodes without taking a financial loss. If Segwit2x participants are honest, there are no risks to running BIP148; if they are dishonest, then BIP148 is necessary to keep your node secure.
* Re: Segwit2x’s one real purpose… I don’t mean to imply that all the participants to the NYA have this goal in mind! But rather that the design of Segwit2x is such that it fits this purpose. Bitmain may very well have done this intentionally, but it seems unlikely anyone else intended it.
