BUIP064: Support Segwit2x with an official implementation

solex

Moderator
Staff member
Aug 22, 2015
1,558
4,693
BUIP064: Support Segwit2x with an official implementation
Submitted on 1st September 2017 by solex

Motivation

Segwit has activated on the Bitcoin network.
This is due to miners respecting the New York Agreement and part-fulfilling their side of it. Representatives of most miners and a number of major Bitcoin companies made this agreement to increase the block size limit to 2MB and activate Segwit. The increase to 2MB is scheduled to occur at block 494,784 (about mid-November 2017).

Bitcoin Unlimited must remain responsive to the collective will of its membership. The sense of its membership can be observed in ways other than BUIP votes, and one important signal is the ratio of deployed nodes where a subset of them are controlled by BU members. It is now one month since the advent of Bitcoin Cash, which is a pure large-blocks spinoff, and some 250 BUCash full-nodes are deployed. There are a further 690 BitcoinUnlimited full-nodes deployed still supporting the Bitcoin network, about 70% of all BU nodes (source: bitnodes.io). Those node owners are clearly anticipating potential success of the Segwit2x initiative.

Segwit was deployed as a soft-fork and one of the major drawbacks of these is that the larger the functional change in a soft-fork the more severe is the "zombification" of nodes which do not deploy the soft-fork. This applies to the 690 BU nodes which are now unable to mine blocks, as well as being unable to verify and propagate some witness data.

It is not acceptable for the BU organization to sit by and allow the increasing zombification of many full nodes which have been deployed by users of its software in good faith.

Authority to act already exists because Bitcoin Unlimited was launched as onchain scaling patch-set on top of Bitcoin Core. The guiding principle here is that BU members can veto Bitcoin changes (such as RBF) or vote for new changes (such as Xthin), but, in the absence of such direction the Developer has discretion to merge Bitcoin Core updates.

Objectives

The purpose of this BUIP is to upgrade the next version of the official BitcoinUnlimited implementation with the Segwit software in order to be fully compatible with Segwit2x, as per the New York Agreement.
The BU Developer will have the choice of constructing a client as follows:
(a) rebase upon a later version of the Core Project repository and preserve the Segwit functionaity.
(b) fork the BTC1 repository and apply necessary changes to make it consistent with BU's passed BUIPs i.e. remove RBF, add emergent consensus for block limit determination, etc.
(c) merging the SegWit patchset into the current BU (dev) tree​

Project Duration

Due to time pressures it may be only option (b) which is viable before the 2MB activation date. Ideally a new version should be available one month beforehand.

Funding

This version is to be funded as per historical funding for any upgrade.

Impact

A base-block size limit increase from 1MB to 2MB on Bitcoin may occur and be a new minority fork, or it may be the majority hashpower and the Bitcoin Core project forks itself off the network. The process may be protracted and messy or quick and clean. There are a lot of unknowns, but what is known is that the 690 Bitcoin Unlimited nodes currently deployed are unable to participate fully in this network, even if the 2MB is activated and larger blocks allowed. Ideally an official BitcoinUnlimited implementation, which is as fully featured, or even better than BTC1, should be offered to the users to help scale Bitcoin.
 
Last edited:

torusJKL

Active Member
Nov 30, 2016
497
1,156
I'm not sure resources are well spent on this.

Is there an estimation on how much time needs to be invested in order to include SegWit into BU?

Are BU users expected to use SegWit transactions? Do we have any data to support this?
 

solex

Moderator
Staff member
Aug 22, 2015
1,558
4,693
@torusJKL
Good questions. I do not think the effort is huge if BTC1 is forked. Comment from @theZerg is welcome here.
Also the use of Segwit will remain optional for a long time. Certainly, there is nothing to stop the BU members deciding in a future vote to discontinue support for the main BTC fork, however, while it has the most value per unit, and most proof-of-work it would appear very premature to focus on Bitcoin Cash only,
 
  • Like
Reactions: Zarathustra

freetrader

Moderator
Staff member
Dec 16, 2015
2,806
6,088
I wonder if consideration has been given to an implementation option (c) : merging the SegWit patchset into the current BU (dev) tree?

Given that SegWit is by itself quite a well-defined set of changes, this seems less painful than rebasing BU's unique functionality onto Core or BTC1.
 

solex

Moderator
Staff member
Aug 22, 2015
1,558
4,693
@freetrader
Happy to add option (c) as you describe.
The options are simply to give some high-level overview of the approaches available to the BU lead developer who will have to make the decision if the BUIP passes.
My understanding is that the SW functionality is a headache to retrofit onto Xthin, and it complicates a lot of the historical BU development around Xpedited, PV and Request Manager.
 
  • Like
Reactions: AdrianX

AdrianX

Well-Known Member
Aug 28, 2015
2,097
5,797
bitco.in
Personal I'd like to see 3 versions of BU.

V1. option (d) the existing implementation no segwit, I value the work that's been done independently of other implementations I want to keep it I don't want to run segwit code.

V2. similar option (b) it can just be a simple BTC1 fork with EC. - no Xthin.

the 3rd being BUCash.
 

torusJKL

Active Member
Nov 30, 2016
497
1,156
I could warm up to V2.
It would give people who want SegWit some of the BU features while keeping the original BU on the path it took for the last few years.

An alternative BUIP could be created for the next voting round.
 

adamstgbit

Well-Known Member
Mar 13, 2016
1,206
2,650
Personal I'd like to see 3 versions of BU.

V1. option (d) the existing implementation no segwit, I value the work that's been done independently of other implementations I want to keep it I don't want to run segwit code.

V2. similar option (b) it can just be a simple BTC1 fork with EC. - no Xthin.

the 3rd being BUCash.
i dislike this. I dont know, but i get the feeling BU doesn't have the manpower to maintain 3 versions that will undoubtedly diverge futher.

I think its better for BU to focus on ONE implementation. BU should be BU, not BU-Cash not BU-Segwit2x, Bitcoin Unlimited, should be dev.ing on the chain known as BITCOIN, period the end.

The point is.... "what is bitcoin?" ( Core or Cash or segwit2x ), there is no good reason for BU to remain neutral in the "what is bitcoin" debate.

I will vote against this BUIP because it has NOTHING to do with Bitcoin the peer to peer electronic Cash system.
 

solex

Moderator
Staff member
Aug 22, 2015
1,558
4,693
This BUIP did not pass. It received more "for" than "against" votes (13:8) but also required a 50% quorum due to the number of votes against being >25%.

Nevertheless, the Bitcoin Unlimited client is not yet a Bitcoin Cash only implementation. What has been rejected is the Segwit software, not the main fork of Bitcoin which has most PoW and market price at the present time.

So, this is an open question for the developers:
"How can BU support BTC1 without implementing Segwit, as mining or non-mining nodes"? Can it offer mining functionality which ignores Segwit txns and creates empty extension blocks? The latter seems do-able and viable long-term.

BTC1 will increase the block limit to 2MB, and this is completely in line with BU's vision for onchain scaling. It is possible that once this is done, the usage of Segwit will peak and decline, particularly if further limit increases occur after the 2MB.

Factors to consider.
BTC1's node count could do with BU's help. We have 660 Bitcoin nodes (excluding the 200 Cash nodes). Those nodes should be able to follow a 2MB fork.
The latest version of Core disconnects peers which do not send the extension block witness data (so much hypocrisy about the backward compatibility benefit of soft-forks grrrr :mad:)

Comments welcome....
 
Last edited:

AdrianX

Well-Known Member
Aug 28, 2015
2,097
5,797
bitco.in
Distilling my thinking down to the basics:

There is little reason to support multiple implementations however I see 3 distinct opportunities for BU to stay relevant in the short term.

BU's defining feature is user activated protocol changes.

Version 1) BU - referenced off the latest BTC1 client with user adjustable block limit added and user activated segwit on off switch (maybe maybe not depending on viability) this implementation is intended to minimizes developer resonators but give miners who want a centralized reference implementation BTC1 with the EC setting for block size. (no Xthin - possibly no parallel validation) long term this implementation has little value however it could grow.

Version 2) The original BU Legacy based off V0.12 with Xthin and Parallel validation. This is the BU implementation I value it represents a divergence in programing philosophy from Core and BTC1 this is the one I want to preserve as a member. I don't see any reason to implement segwit in this version as it undoes all the diversification that's happens since v0.12. (this version is S1X and S2X compatible so no need to change it significantly)

Implementing segwit undoes most of the Xthin development and testing and I can only presume many other fixes that have happened since v0.12 adding segwit to this implementation represents lots of work, testing and makes BU less robust than it is now begging the question why not just re-base of Core or BTC1 (both options I find rather obnoxious considering everyone in this community valuers decentralization so long as you follow a centralized reference client and centralized governance and re-base every 2 years to ensure centralized control of the bitcoin protocol.)

Version 3) BU Cash effectively sharing as much as is practical with BU legacy if BCH or BTC both survive then as these two grow more mature they will diverge over time as the years pass.

Segwit, I feel is not an upgrade to bitcoin, none of the feature sets presented to me warrant the protocol change, those who want it can use it can pick their favorite implementation. Should the block limit always remain higher than transaction demand I see no reason for BU to implement Segwit, and I think BU can grow without segwit.
 
Last edited:

Snokkom

New Member
Sep 30, 2015
7
34
I don't get it, why SW2X? I know there was an agreement . But do they want every year the same bs? Always fighting about the right direction with Bitcoin?

I want also only Bitcoin Cash. Without Blockstream and the ''NO2X Bitcoin'ers'' who sold all their bitcoin cash. Most NO2X Bitcoin'ers don't give a shit about Bitcoin. They want only short term profits. I'm in for the long run, like I always did.
 
  • Like
Reactions: torusJKL