BUIP098: (passed) Bitcoin Unlimited’s Strategy for the November 2018 Hard Fork

[Christoph Bergmann]

@reina BIP135 is merged in BU, and this BUIP is about enabling BIP135 voting bits for the features under proposed by ABC and SV. We are doing this in concert with XT. Its also about enabling manual override and/or emergent consensus for this same feature set. Obviously EC is the best option, but as others have said, there is limited time and much to do. Since it looks like this is going to pass, we hope to get a release out within a week or two that implements some of the features but most importantly enables the BIP135 voting.

Its ok to allow voting for a feature you haven't implemented yet. Doing it that way is actually an intentional part of the process -- BIP135 gives developers time between when its clear that a feature will be enabled and when it actually goes live to develop it.

However, we don't know who will be using BIP135 voting bits. I know ABC is not, but I hope to talk to nChain and convince them to signal their features using them. Regardless, the intent of this BUIP it to be ready to follow either fork even if its a surprise fork. The recent coingeek statement from Ayre implies that they will call bitmain moving hash power to BCH "unfair" and so we may see a minority coin split coming from them. In that case, you'll be able to configure BU to follow that fork.

If Bitmain moves Hashpower from BTC to BCH just to decide for CTOR, it will need to sustain this by mining at loss; otherwise Bitmain will tricked us into taking the shorter chain as the real thing.

As I said to you in private, I would be greatly disappointed if the new BU software defaults to a feature - CTOR - which was rejected with a clear majority by BU members. I know it is difficult for you, but there is NO technical excuse for this.

If you have no other choice as to give a binary vote between SV and ABC, BU should default to SV, because BU members did not reject the changes of SV, but those of ABC.

 

[reina]

@Emil Oldenburg
At present we assume that majority hash-rate lies with ABC, so the BU client will by default support the ABC change-set.

Such an assessment is not simple as there is already smoke and mirrors over which miners are using which implementations.

So, a vote for BUIP098 is a vote to continue tracking Nakamoto consensus on BCH, regardless of whether the most-PoW chain-tip has the ABC or SV change-set active, rather than risk being forked off. If this BUIP is passed, depending upon development time and effort needed, the BU client may offer a hot fail-over rather than manual config. Users will also be able to pre-select one change-set as an override if that is their preference.

I think maybe I may have misread it at first. By "pre-select one change set", does it mean I get to customise my own change set? Do I get to select something like "No CTOR, No banning tx under 100bytes, Yes DSV"? Like something that doesnt fit under all-ABC rules or all-SV rules?

Or does preselect mean I get window a button between "pick all SV rules" or "pick all ABC rules".

Does preselect mean signal for something in voting bits, and will remain on current ruleset (current as in the network rules right now) and wait for emergent consensus to do its thing before my node switch out of it's currrent ruleset (which is same as the network)?

Or does preselect mean "My node is autoswitching into ABC rules in november at that blockheight. I'll wait for the rest of the network to change my mind. If the majority of the network splits me off into a minority chain because they are following other rules, my node will be like 'Sorry ok ok, you win, ill follow your rules'"?
[doublepost=1539183418][/doublepost]@Christoph Bergmann I hope I just misread Solex at first. It would be best to do it via emergent consensus and have features voted for and locked in when majority of network wants it, seems smoother. ABC wont use voting bits as @theZerg mentions.

 

[theZerg]

We are entering a period of uncertainty so its important to give people options. The way we are doing it is that the BIP135 voting is orthogonal to the scheduled Nov HF.

Let's talk about the Nov "package" first. If you want the Nov "package", you'll be able to configure it like this:

consensus.forkNov2018Time=1535500000

If you don't want it, you can turn it off:

consensus.forkNov2018Time=0

@Christoph Bergmann is asking what the default is going to be, and the answer right now it IDK. There's a third option which is to FORCE a choice in bitcoin.conf (refuse to run with a nice error message). We don't have time to vote so we should start a debate about this and see what happens. Personally, I don't think that the default matters a whole lot. However, that BUIP where the voters rejected CTOR explicitly states that it does NOT authorize a chain split. It is asking us to resist CTOR as much as possible but ultimately follow the hash power majority. I believe that I have been one of the biggest critics of CTOR with lots of published work (I'm the top hit if you search for "CTOR scaling"). So I feel that I have fulfilled the BUIP. To ask me to make the default client fork off of the mainchain is going beyond the BUIP.


Now onto individual features.

@reina, If you want to use bip135 voting, you can configure your votes like this:
mining.vote=op_checkdatasig,tx_min_size_100,opcodes_mul_shift_invert

Here I am voting for some of the Nov changeset and some nChain features.

You can change it whenever you want like this:

./bitcoin-cli set "mining.vote=op_checkdatasig,opcodes_mul_shift_invert"

So how about we configure to follow the ABC fork but also vote for some SV features:

consensus.forkNov2018Time=1535500000
mining.vote=opcodes_mul_shift_invert,unrestricted_script_instructions

I hope that miners will start using bip135 voting to signal a desire to transaction away from the contentious semi-annual HF system (which I originally proposed in the hopes of moving a lot of uncontroversial features into the coin). Personally, I'll be pretty surprised if that happens before the Nov HF.

 

[imaginary_username]

@theZerg for maximum adherence to the spirit of the BUIP, an error message is probably warranted. Ideally even with a few presets that you can one-key choose at the error message, like "no BIP135 featureset chosen for November, do you want to continue on old rules (1)/follow ABC(2)/follow SV(3)/quit and manually choose in config(4) ?

 

[Christoph Bergmann]

Awesome. Much much much thank you for this.

It seems like a lot of options to configure in the bitcoin.conf. Every single proposed change. I would love to help you to document it, even if it is just to help me to get it

However, that BUIP where the voters rejected CTOR explicitly states that it does NOT authorize a chain split. It is asking us to resist CTOR as much as possible but ultimately follow the hash power majority.

Yes, that is a really difficult question, and a burden to decide. We don't know what the majority hashpower will do, I hope for Bitmain to act rational, while I don't expect it from nChain.

What outcomes are possible?
All are on the same chain, with or without CTOR.

Majority chain is CTOR.
We are part of it.
We are on nChains minority chain.

Majority chain is non-CTOR.
We are part of it.
We are on Bitmain/ABC's minority CTOR-chain? Is this possible?

Or ... wait ...
Since we have AD, we can't end on a minority chain? Do I understand this right?

CTOR forks, I stay on non-CTOR, but after AD blocks, I resync to the CTOR-chain?

If so, the question is not, how to protect the users ending on the wrong chain? But to protect the network from splitting? In this case, I have no hopes that anything we do can prevent nChain splitting when they want, while I have more hopes on Bitmain.