[Bitcoin-segwit2x] August Status Report for SegWit2x

Good morning - SegWit will officially activate on the public blockchain today! Congratulations to everyone on the SegWit2x team, as it is clear this never would have happened without your efforts. As SegWit activates, this is a good time to send out a quick project update. You may have noticed that the SegWit2x team has been pretty quiet lately. That’s a good sign, as it indicates that the code is operating as expected. The goal of SegWit2x is to create a simple and stable codebase that is relatively “boring”. If you don’t hear much from the SegWit2x development in the coming weeks, it is a good sign. Nonetheless, here are few highlights of where we’re at now: - btc1 continues to grow. If you haven’t started running a node yet, you can find instructions here <https://github.com/btc1/bitcoin/releases>, or help beta-test our new AMI. - Release candidate #2 is now the official release. The software is working as intended and there have been no bugs or faults. - We activated BIP91 without issue, as expected.. - We handled the August 1st UASF and Bitcoin Cash chain splits as expected. - Hashpower continues to signal 90+% support for SegWit2x Also to note, the Bitcoin Core team has new code scheduled for the 0.15.x release that will disconnect all peers <https://github.com/bitcoin/bitcoin/pull/10982> that advertise NODE_SEGWIT2X. Fortunately, we don’t anticipate that this has any real bearing on SegWit2x. See below for tech notes. The Path Forward At this juncture, it may be useful to take a step back and understand why the New York Agreement was able to break through the scalability gridlock. The path to SegWit2x actually began in February 2016, when members of Bitcoin Core met with several Bitcoin miners in Hong Kong and signed the Hong Kong Agreement <https://medium.com/@bitcoinroundtable/bitcoin-roundtable-consensus-266d475a61ff>. Their proposal was to implement SegWit in summer of 2016 followed by a 2MB hard fork to release in approximately July 2017. Unfortunately, a year later, SegWit still had not been activated, and the hard fork had not even been implemented. In May 2017, a new group came together in New York to discuss how to address Bitcoin’s scalability impasse. Once again, the group came to the same conclusion: the best path forward was to implement SegWit followed by a 2MB hard fork. Within 2 months of the agreement, Bitcoiners observed unprecedented consensus levels- with 95% of miners quickly agreeing to deploy SegWit under the SegWit2x proposal. The grip which had choked Bitcoin for over 3 years was finally released. Although SegWit activation is imminent, we are still not done. The SegWit2x project now enters its quiet period as we prepare for the November upgrade. Only software changes absolutely necessary to ensure a safe November upgrade should be considered as changes. During this time, it may seem like nothing is happening or that we don’t need to persist. But we do. As of this writing, we continue to have over 90% agreement from miners to move forward with SegWit2x. SegWit2x is officially locked in and the plan is working. During this quiet period, it will be easy to forget about SegWit2x as not much is expected to happen. But we need everyone to keep spreading the word of what we’re doing and why it matters: we’re upgrading Bitcoin using Bitcoin’s long established upgrade mechanism, increasing Bitcoin’s scalability, and taking the unity path to keep the Bitcoin network united without a chain split. Please continue to tell the world how important SegWit2x is for Bitcoin, and help rollout more SegWit2x nodes. If you have suggestions on how to further increase SegWit2x support, please let us know. Let’s get to 100% consensus. Technical Notes1. Production code freeze btc1 v1.14.5 had no faults during the BIP91 and BIP141 activations. Formerly Release Candidate #2, it is now re-dubbed the SegWit2x Production Release. Per normal engineering practice, a new release candidate version is published until there are no more changes; the final release candidate becomes the release. The segwit2x branch is frozen. Only bug fixes and documentation changes that contribute to the success of the November upgrade will be included. Maximum stability and minimum changes are the goal. 2. NODE_SegWit2x peering Version 0.15 of Bitcoin Core, schedule to be released sometime in September or early October 2017, includes a change <https://github.com/bitcoin/bitcoin/pull/10982> that will disconnect all SegWit2x nodes. This is not anticipated to have much impact on SegWit2x, given that 0.14.x nodes and other nodes (btcd/bcoin/BU/BC) remain compatible and act as bridges. 3. Process for Raising Issues It is important that key technical decisions are discussed and recorded, either on the mailing list or on github. The most recent example is the community discussion around anti-replay protection. Given the matter’s importance, a github issue <https://github.com/btc1/bitcoin/issues/34> was created months ago to track this issue and find a solution. 4. Opt-in Transaction Avoidance (aka anti-replay) Pull Request #117 <https://github.com/btc1/bitcoin/pull/117> was created to implement Gavin’s anti-replay method and gain wider peer review among the community, especially bitcoin exchanges. Issue #34 <https://github.com/btc1/bitcoin/issues/34> discusses anti-wipeout (done <https://github.com/btc1/bitcoin/pull/50>) and anti-replay scenarios and solutions. There has been much debate in the community about anti-replay methods, in particular. Some opt-out replay protection schemes have been proposed, that require all wallets to upgrade. These are naive suggestions, as they will exacerbate the chain split we are trying to avoid. Opt-in replay protection are therefore preferred. Opt-in replay protection offers the greatest amount of user choice as well as a higher level of compatibility with deployed SPV wallets. 5. Opening Dev Branch btc1 as a project will continue after the November hard fork. We will welcome community changes outside the scope of the SegWit2X project in a new dev branch at btc1 github. There are several exciting changes that will be pushed there in the coming months, including some performance improvements, expanded wallet capabilities—the bitcoind wallet really is ancient tech—, expanded functional tests, and a few fun surprises. If you wish to contribute to the dev branch, please mark github pull requests with ‘outside SegWit2X scope’ or similar language. 6. btc1 AMI at Amazon An AMI of btc1 including fully synchronized blockchain data and leveldb indices is available at Amazon. The EBS volume is ~400 GiB, cloned from a clean 64-bit Ubuntu LTS 16 AMI. This is a public AMI that Bloq sponsors and maintains on behalf of the btc1 project. It is free to use. Details: AMI-id: ami-4b437e30 AMI-name: btc1-bitcoin-Aug2017 Region: us-east-1 (n. virginia) Instructions 1. Start AMI. 2. Log in using your normal EC2 keypair and security parameters. 3. cd repo/btc1/bitcoin/src ; ./bitcoind -daemon to start up. 4. Everything is under the default `ubuntu` account that is created with a vanilla Ubuntu LTS 16 instance. Notes This is a beta version. Feedback is welcome. We will make a production version of this AMI available soon, incorporating feedback already received (“start at launch”). The production release snapshot will be made available across multiple Amazon regions; us-east, us-west, EU and Seoul (nearest to Beijing) are planned, at a minimum. This AMI was prepared using the security guidelines including in this guide <http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/building-shared-amis.html> . -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/attachments/20170823/5f543048/attachment-0001.html>