On June 16, Jeff Garzik announced the Alpha release of SegWit2x. After all, miners who have signed the agreement started to signal for its activation, SegWit2x is nearly instantly backed by more than 75 percent of the hash rate. The activation of SegWit, it seems, is safe – while the hard fork, which is part of the packet, is not.
Jeff Garzik announced in the SegWit2x mailing list the alpha release of SegWit2x on June 16; this is a fork of Bitcoin Core, developed to solve the scaling debate, after an alliance of miners and companies, which represent around 80 percent of the Bitcoin ecosystem, agreed in New York on a path forward.
At the time of writing the client only exists on GitHub; files for auto-installation are not available yet. As Garzik points out, the official branch of the btc1-repository is the release. In it, you find the code for the increase of the base block size to 2MB, as well as the SegWit activation plan BIP91. Now the SegWit2x working group tests the software on testnet. In late July, so goes the plan, it should start. Then the following will happen.
If SegWit reaches a miner support of 80 percent of the hash rate during a period of 336 blocks, the software will activate SegWit 336 blocks later on all SegWit2x nodes. These clients will start to signal the activation on bit1, with which they help old Core Nodes, which are waiting on a threshold of 95 percent, to also activate SegWit.
Not earlier than September 21, but at minimum 12,960 blocks or roughly three months after the SegWit activation, the SegWit2x nodes will automatically increase the block weight limit from 4 to 8MB, equivalent to a hard fork to a 2MB base block size. If the hard fork reaches 75 percent hash rate support, it will force every other node in the network to upgrade to a client compatible with SegWit2x.
Only four days after the Alpha release SegWit2x already enjoys more hashpower support than any other earlier capacity upgrade. All the big mining pools, BitFury, Antpool, F2Pool, btc.top, ViaBTC, Bixin, BTCC signal support for SegWit2x. However, the miners only write “NYA” in the coinbase transaction but do not trigger activation of SegWit with a version bit in the block. This might actually happen mid or end July.
When this happens, SegWit might be activated in less than a week, after which everybody can start to use the new transaction format. Until now the implementation of SegWit in the wallets is relatively poor, but Trezor’s SegWit integration for Litecoin shows that there are paths available which might allow for a smooth, but fast transformation of inputs.
After the upgrade to SegWit is done, however, there is no guarantee that the participants of the agreement of New York stand by their word and run with SegWit2x in a hard fork. There is also no guarantee that sufficiently enough other companies and users will follow SegWit2x to make the hard fork a success story. If it is done and if it is successful depends fully on the integrity and firmness of the involved miners and companies.
You can assume that all those fights and discussions, which have become part of Bitcoin for two years, will continue after SegWit is activated. There will be fights against the agreed hard fork. Right now the Core developers nearly unanimously reject this hard fork, and only a few of them support even the activation plan for SegWit which the working group developed. If SegWit2x does not succeed in convincing the influential Core developers to support the hard fork, it might be difficult to maintain the majority of miners, companies, and users, to push the hard fork through without splitting the chain. If the support of the agreement sinks and signers do not hold their word, it is possible that the SegWit2x hard fork will mimic all other earlier hard fork attempts – and will not happen.