[Bitcoin-segwit2x] August Status Report for SegWit2x

Mike Belshe mike at bitgo.com
Wed Aug 23 15:14:15 UTC 2017 

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>

More information about the Bitcoin-segwit2x mailing list