Be notified of new releases
Create your free GitHub account today to subscribe to this repository for new releases and build software alongside 50 million developers.Sign up
This is the first public beta based on Bitcoin Core 0.15.x series.
- segwit2x, forward ported to Bitcoin Core 0.15.x
- The -advertise2x option: Option to disable NODE_SEGWIT2X advertising
Version 1.14.5, aka segwit2x Production Release, has been released.
Per normal software engineering practice, we keep making Release Candidates until the software is ready for production release, at which point the most recent RC becomes the production release.
This is more than one would like to see in an RC. However, it is not anticipated that any more notable changes will occur, and that RC2 will become final (pending any fixes for bugs found in testing, if any).
Advertise NODE_SEGWIT2X to peers and DNS seeds via a service flag in the p2p network protocol. Additionally, btc1 clients will preferentially peer with segwit2x and segwit nodes. The
prefpeeringoption - default:on - is added in case admins wish to disable preferential peering. Journey began with issue #42
Merge Bitcoin Core 0.14.2, to import fixes from the latest BC point release. Nothing notable.
Miners should use the default BIP9 feature signaling - 0x20000012 - to ensure their blocks are not orphaned when BIP91 enforcement becomes active this weekend.
The shortlog follows. It is separated into two sections for easy reading: (1) btc1 changes, and (2) changes between BC 0.14.1 and BC 0.14.2 that were merged into btc1.
The shortlog of changes from btc1 v1.14.4 to v1.14.5 follow:
Ismael Bejarano (1): Split hard fork test after segwit activation Jeff Garzik (6): Advertise NODE_SEGWIT2X service flag by default. segwit2x node preferential peering policy Merge pull request #90 from btc1/2017_segwit2x_merge_0_14_2
The shortlog of the changes from BC 0.14.1 to BC 0.14.2 follow:
Alex Morcos (2): Populate services in GetLocalAddress Note preexisting bug in display of fee calculation in coin control Cory Fields (3): build: remove wonky auto top-level convenience targets build: fix bitcoin-config.h regeneration after touching build files net: only enforce the services required to connect Gregory Sanders (1): [Wallet] unset change position when there is no change on exact match Jonas Schnelli (5): Reduce cs_main locks during modal overlay by adding an atomic cache Update the remaining blocks left in modaloverlay at init. Declare headers height/time cache mutable, re-set the methods const Set both time/height header caches at the same time Add missing <atomic> header in clientmodel.h Matt Corallo (1): Check interruptNet during dnsseed lookups Russell Yanofsky (1): Fix importwallet edge case rescan bug Shigeya Suzuki (1): Minor fix in build documentation for FreeBSD 11 Wladimir J. van der Laan (8): doc: clean out release notes Merge #10484: 0.14 Backports build: bump version to 0.14.2 doc: Preliminary release notes 0.14.2 qt: 0.14.2 pre-rc2 translations update doc: Update manpages for 0.14.2 doc: Fill in details about miniupnp CVE-2017-8798 Merge #10588: doc: Note preexisting bug in display of fee calculation in coin control fanquake (1): [depends] miniupnpc 2.0.20170509
The diff from 1.14.3 - the beta released 17 days ago - is very
small. No consensus changes. Included are Cleanups, tests, and new DNS seeds
which are planned to be segwit2x aware and fully operational by the
July 21 target date.
As per the July 14 milestone, we are asking all WG members to be
actively testing Release Candidate 1 on testnet5 and mainnet.
Sergio Lerner has been working on a segwit2x BIP (specification):
Understand that this is in draft form and may see minor revisions.
Based on recent feedback and criticism, (a) NODE_SEGWIT2X service
bit and (b) addressing lack of an explicit attachment from bit-4 to
the 2M HF are under consideration for Release Candidate 2.
4a. It was suggested very early on by several folks to use a
NODE_SEGWIT2X service bit. There was initial pushback both from folks
who feared nodes being targeted. The btc1 major version (1.x.y) was
always visible on the network, therefore, it can be fingerprinted and
targeted anyway, rendering moot this criticism. Given that, and also
the utility of node discovery in and around SegWit-active and HF
phases, using a NODE_SEGWIT2X service as proposed a while ago seems
additive for users & network.
By way of background, NODE_xxx service bits are gossiped around the
network, exchanged between P2P peers, alongside node addresses. In
theory, segwit2x nodes can more easily find other segwit2x nodes on
the wider network via NODE_SEGWIT2X.
4b. The activation sequence is bit-4 -> bit-1 -> time passes -> 2M
hard fork. There is the valid criticism that, in the (IMO unlikely)
event of "bit-1->time passes", without bit-4 activation per NYA
agreement, that the btc1 node would still activate the 2M hard fork
after 144x90 blocks. It seems both prudent, in the spirit of the NYA
agreement, and addressing an edge case to ensure that bit-4 activation
did indeed occur, before triggering the 2M after 144x90 blocks.
Usefully, we have time to polish this.
- July 21 is the target for the next release.
btc1 Core version 1.14.3 is now available from:
This is a beta version release, including various bugfixes and
Please report bugs using the issue tracker at github:
btc1 Core is extensively tested on multiple operating systems using
the Linux kernel, macOS 10.8+, and Windows Vista and later.
Microsoft ended support for Windows XP on April 8th, 2014,
No attempt is made to prevent installing or running the software on Windows XP, you
can still do so at your own risk but be aware that there are known instabilities and issues.
Please do not report issues about Windows XP to the issue tracker.
btc1 Core should also work on most other Unix-like systems but is not
frequently tested on them.
Release notes and comments for version 1.14.3, aka "the beta release"
The charter and goal of the segwit2x effort has always been tightly
focused on a "SegWit + 2M HF" safe network upgrade, and
producing/testing/auditing software to accomplish that. Milestones
are intentionally labeled "alpha" or "beta" per normal software
engineering practices, and expectations should be set accordingly.
For this beta release, we can expect that network and consensus
protocols meet the design goals, but may be tweaked based on field
testing and feedback from the general public. Bugs are an expected
part of the public beta testing process.
Consensus Rule Overview
The over-simplified summary of the network upgrade sequence is:
bit-4 SegWit activation + 144*90 blocks
This matches the goal outlined in the kickoff Project Mission: "Segwit
will start being enforced shortly after lock in, whereas as 2mb blocks
will be a bit farther out to ensure people have plenty of time to
upgrade their nodes."
Consensus Rule changes
Two issues addressed in this release relate to consensus,
This change tightens the predictability of the network upgrade. The
traditional approach is a two-step sequence of (1) rules change, and
(2) zero or [many] more blocks later, a large block is mined. This
release requires a large block - greater than 1M - precisely at rule
change time. Although the primary motivation is predictability, an
additional motivation is wipeout protection.
See the github issue for additional background and discussion.
Consensus Rule review phase
From the standpoint of the segwit2x charter, the software matches the
two points of the NYA agreement. No further rule changes are
This is the best phase for wider public review of both the consensus
rule changes, as well as the software changes themselves. "Given
enough eyeballs, all bugs are shallow."
https://en.wikipedia.org/wiki/Linus%27s_Law Feedback is actively
solicited and considered.
Now that the core rule changes and activation are frozen (pending
community review), the next step is wider review and testing by the
working group and general public as mentioned.
To assist that process, specifications will be drafted in unnumbered,
IETF draft-style form at https://github.com/btc1/specifications
Multiple BIPs will be produced very soon, documenting the segwit2x
changes. These drafts will be PRd to
https://github.com/bitcoin/bips after a wider round of feedback from
the specs posted at /specifications
Testnet test plan
In addition to individual WG members and developers who have been
testing (thanks!), a sub-team inside the working group has been
auditing bitcoin libraries/stacks/apps as well as helping test plans
and test scenarios.
The public testnet5 will be taken through several test scenarios, and
some of these activations will be baked into updates of the btc1