Bitcoin Fork Proposal (BFP) Process

[singularity]

1. Contents

1. Contents
2. Statement of Need
3. Objectives
4. Proposal - BFP Process
5. Example
6. Evaluation
7. Future Objectives
8. Risks
9. Support

2. Statement of Need

Finding consensus is hard, especially when using a decentralised development structure. Having multiple development teams, and therefore multiple streams of proposals, means that there is bound to be conflict and competition. This is a good thing though. Not only does decentralised development spread power and influence out so that there is no core, it also leads to a marketplace of competing ideas. More ideas means a higher probability of finding optimal solutions.

The downfall of this approach is the fact that it becomes difficult to decide what proposals gets implemented. Egos can flare up, and a split in the commmunity can occur if a debate gets too heated. Cryptocurrencies rely on network effect, therefore in almost all situations it is better for a network to remain in consensus. The only situation when a network split is justified, is when there is a fundamental idealogical disagreement within the community, like there was in Bitcoin for the past 3 years. In this situation it is better for a split to occur, and each group can go their separate ways, like in the situation of Bitcoin Cash and Bitcoin. This should be a rare occurance though, and therefore there is a need to implement an improved consensus finding process.

Consensus is not required for all software changes. It is only required for changes that will cause a split in the network. Development teams are free to make any software changes to their own code base that do not cause a split the network. Sometimes software upgrades will be required that can potentially cause a split in the network. It is important there is a basic framework that the network agrees in principle to follow, that allows upgrades to happen without causing a network split. Equally, it is important that anyone is able to offer up solutions to solving a problem, that may not necessarily be compatible with the solutions provided by others.


3. Objectives

• Unanimous consensus is no longer necessary.
• Development teams are able to offer up different proposals and the miners can decide which proposal is best.
• Miners are able to decide to make no change at all.
• The network remains in 100% consensus at all times other than in situations of extreme idealogical disagreement.
• Process can be implemented immediately.
• Process is loose enough that it can be applied to any upgrade that requires consensus.
• Does not conflict with other improvement proposal processes, such as BUIP.
• Provide confidence for network participants that community leaders (i.e. developers, miners and businesses) will support a process that aims to use free market principles but still keep the network in 100% consensus at all times.

4. Proposal - BFP Process - Bitcoin (Cash) Fork Proposal

4.1. Development Process

The development process stays as it is currently, where anyone can discuss, develop and test software solutions, and then propose them to the network. The only difference being that they will assign their proposals a unique BFP ID using the guidelines below.


4.2. Signalling

Signalling is done by miners in the coinbase by using the following format: BFPXX/YY.

XX represents a BFP 'batch' number. A batch number is a ID that represents a batch of proposals that all seek to fix the same problem. For example, all proposals that seek to fix the EDA problem.

YY represents a proposal number. The proposal number is an ID that represents a specific proposal in a batch of proposals. When YY = 0 then the miner is signalling that they do not support any proposal.


4.3. Voting Terms

A proposal must receive absolute majority support (>50%) by miner signalling over a period of time, for the proposal to become locked in.

One caveat to this is that the aggregate support of all proposals must be over 75% vs support for 'no change', i.e. YY=0 in the signal.

The signalling period and lock-in period are to be pre-agreed by the entities making the proposals before the voting starts.


4.4. Implementation

After the signalling period occurs, all miners switch to signalling the winner of the vote, and the lock-in period starts. The lock-in period allows time for the participants of the network to update their software (if necessary). After the lock-in period 100% of the miners fork the network at a specific block number/timestamp.

In this way, miners and developers have a gentlemen's agreement with each other, and the network that; if a proposal receives the required support over the signalling period, then all miners will switch to support that proposal. This allows the network to remain in consensus while also allowing different solutions to compete.


5. Example

There are three proposals. The proposals are given the IDs BFP1/1, BFP1/2, and BFP1/3. BFP1/0 is reserved for miners to signal for 'No Change' in a batch. The '1' in BFP1/Y is the batch number. The community can then discuss the merits of each proposal, and miners can then signal for them. The miners signal/vote with the following representation over the signalling period:

• BFP1/0 = 10% share
• BFP1/1 = 55% share
• BFP1/2 = 15% share
• BFP1/3 = 20% share

The proposal BFP1/1 wins with a 55% share of the vote. This is because it has a majority share, and BFP1/0 is less than 25%. After the voting period ends, all miners then shift their signalling to BFP1/1 for the lock in period. The Bitcoin Cash economy then updates their software to be compatible with the BFP1/1 proposal. Miners then fork at a specific block height/ medium timestamp.


6. Evaluation

I believe this proposal solves all the objectives specified but there is of course always room for improvement.


7. Future Objectives

• Make improvements to the details of the BFP process.
• Research the use of a coded BFP process for a more streamlined and automated process. For example, automate the switching of signalling after a BFP receives the required support over the signalling period.
• Research the use of synthetic forks.
• Improve communication channels between the developers, miners and network participants.
• Improve communication by developers (The BFP process incentivises good communication of BFP proposals because it must win a vote).

8. Risks

• Developers and/or miners do not stick to the agreed upon BFP process (already true).
• Miners do not educate themselves enough to make a decision on what the best proposal is (already true).
• Users do not have a way of signalling their preference (already true).
• Miners signalling falsely.

9. Support

This is a list of all people who support this initiative. Please reach out and say if you support this.

• FreeTrader (BitcoinABC)
• Shammah Chancellor (BitcoinABC)
  
• Tom Zander (Bitcoin Classic)
• Jonald Fyookball (Electron Cash)
  
• LocalBitcoinCash.org
• Ryan X Charles.
• Yours.org
• Robbot
• Rocketr.net
• Tippr
• AcceptBitcoin.Cash
• u/KoKansei
• Erik Beijnoff
• u/jessquit
• u/zquest
• Singularity

Github Link.

 

[singularity]

My intention is to make this into a BUIP submission once/if I get BU membership.

 

[Tom Zander]

My story;

Even back in February I pushed Jeff for a mailinglist, and we got one (co-moderated by many). I have since been pushing people to use it for communicating about their plans for network changes. Protocol changes etc.

The problem is that Amaury refuses to use the list. When I confronted him he got angry and stated that discussions were not needed. What is equally worrying is that he directs all code changes to his private site instead of somewhere industry interested people might actually see it. As Justus Ranvier said, where is the specification?

I think the proposal is nice, but I want it to be stronger. Less dependent on good-will. Because exactly that has been missing.

I also think the problem stems from the private communication with miners. The miners accept or reject changes, so you can see them like the voting part of the government (lower house or whatever its called in your country's democratic system). This was shortcutting the system..

What we saw was a decision for a hard fork with all the details ready made, agreed by miners and within 24 hours reported by a large number of professional sites, sealing the deal like a mined block. This obviously was the result of massive private communication and coordination. It was well-planned with a timing that makes is hard or impossible to reverse.

On top of that, the ABC guys wrote a press release that clearly is intended to make it seem that they are the stewards and specification writers of BCH. No spec anywhere other than in their press release!

The problem I observe is not that one team didn't want to talk to other teams. The problem is that miners decided on a technical spec before that was made public.

As I said, there is likely a lot of overlap in your proposal with this thinking. Sorry for being very verbose.

I think the main goal is not so much that we make the developers sign something (though I'm fine signing your doc), its more that we need most miners to agree they will not sideline process like this again.

Adding to the proposal; we would benefit from a structure and a timeline (minimum time for review etc) where protocol changes are made public for not just miners but also developers to comment on it. Maybe a week for comments and another 3 days until the miners votes have to be in.

 

[singularity]

Tom, thank you for taking the time to review the proposal and provide some feedback.

Even back in February I pushed Jeff for a mailinglist, and we got one (co-moderated by many). I have since been pushing people to use it for communicating about their plans for network changes. Protocol changes etc.

I have put in a request to join the mailing-list so that I can also make this proposal there. Maybe you can help get me accepted there?

I think the proposal is nice, but I want it to be stronger. Less dependent on good-will. Because exactly that has been missing.

One of the aims in writing the proposal was to make sure that the requirements are not too stringent. The more complex and restrictive the proposal is, the less likely it is to be agreed upon by everyone. Even if it is agreed upon by everyone, people are unlikely to follow it if it conflicts with the way they normally operate.

Ultimately, any proposal like this will have to come down to 'good-will' as there is no way to stop anyone from writing or running code. My hope is that this framework has so many benefits and so few downfalls, that everyone will have large incentive to use it, and will therefore freely choose to use it.

I also think the problem stems from the private communication with miners. The miners accept or reject changes, so you can see them like the voting part of the government (lower house or whatever its called in your country's democratic system). This was shortcutting the system.

This is certainly something that I hope the BFP framework will solve. There is no way anyone can stop this from happening, but I think there is clear agreement across the Bitcoin Cash community that there needs to be more transparent communication for forks in the future.

I think the main goal is not so much that we make the developers sign something (though I'm fine signing your doc), its more that we need most miners to agree they will not sideline process like this again.

You will be glad to hear that I not only intend to get all developers to agree in principle to this initiative, but also the miners. I think getting agreement from the developers first will make it a lot easier to get the miners onboard as well. My plan is to ask the miners signal BFP0/1 to show their agreement with their procedure.

Adding to the proposal; we would benefit from a structure and a timeline (minimum time for review etc) where protocol changes are made public for not just miners but also developers to comment on it. Maybe a week for comments and another 3 days until the miner's votes have to be in.

This is something I did consider when writing the proposal. Again, wanting to keep the proposal as simple and unrestrictive as possible, I decided that it would be better for developers to decide amongst themselves the signalling and lock-in period.

I don't know if it is sensible to include a specific stipulation for a delay between making a proposal and miner signalling. I think it could make sense to include a stipulation of a minimum miner signalling period (if there was agreement for this from all the dev teams). Having a minimum signalling time would give devs time to prepare their own proposal should a proposal come out of nowhere, and would allow time for time for proposals to be adjusted based on feedback. Would you be ok with this?

Is it ok if I include your name in support in principle of the BFP process?

 

[Tom Zander]

> Is it ok if I include your name in support in principle of the BFP process?

yes.

 

[singularity]

Thank you.
Tom Harding has suggested that something like BIP9 could be used for signaling. Do you have any thoughts on this?

 

[todu]

This proposal has been discussed on Reddit (/r/btc) and I am against this proposal. I'll include my first comment:


KISS. (https://en.wikipedia.org/wiki/KISS_principle)

1. Each node team (XT, Classic, BU, ABC) make their own proposals for changes to the Bitcoin (Cash) protocol, and assign a (BIP9) version bit for each proposal that the miners can vote on.
   
   
2. The miners vote and whichever proposal first gets 75 % of the votes, gets activated.
   
   
3. The Bitcoin (Cash) users vote by either buying or selling their BCC coins.

Let's not overdo the "collaboration" between the different node projects. It's good to have competition in this simple way. Otherwise we risk creating one big centralized node project instead of having multiple competing and decentralized node projects and development teams.

(I do not support this "collaboration" proposal.)

----------------------------------------------------------------------------------------------------------------------

Then after a while Thomas Zander posted a link to a blog post where Amaury Sechet was heavily criticized for how he announced the DAA fork. I'll include my reply in that post as well (Thomas deleted his own post shortly after having posted it):


Don't exaggerate. The Bitcoin ABC project has not forcefully taken control over Bitcoin Cash protocol development. It's good that Amaury has shown initiative and action (not just talk), to carefully select a better DAA and offer his solution to the miners. It's probably going to be very beneficial for Bitcoin Cash to have a much better DAA if and when the 1x/2x chaos activates just 2 weeks from now.

For less time critical changes, yes, making B(Cash)IPs and then having the miners vote on those BCIPs via BIP9 or something similar is a good idea.

This time that was not possible though because having the community debate the different DAA proposals, having BU vote internally via their BUIP process, and then letting the miners vote also, would take much more than 2 weeks and we would have to go through the 1x/2x fork with the problematic current EDA.

tldr: So I support Amaury in this particular case.

Also, why did you (/u/thomaszander) ban Amaury (/u/deadalnix) from your Bitcoin Classic Slack chat? I still haven't seen you answer that question. I'm sure that Amaury would never ban you from any Bitcoin ABC chat systems.

 

[singularity]

I like it. I would like to see guidelines about how a well behaved client proposes a hard fork change. This many days for feedback. This many days of frozen code, etc.

@theZerg Thanks for your comments. I think having a minimum signaling period and lock-in period may be enough to give time for feedback and counter-proposals. If everyone agreed to it, there could a 'discussion period' added to the agreement though. For example, minimum one-month discussion, one-month signaling, and one-month lock-in. Adding the one-month discussion period to the agreement would put extra requirements on developers, but it would obviously have the benefit of making the discussions public before a proposal is submitted for voting.

 

[Tom Zander]

I prefer a discussion period as well. The main purpose being that we delay the voting until everyone has had a chance to put their cards on the table.
For instance thezerg published his research on the DAA after the decision was made, had we had this period of discussion prior to starting any voting, he would have had the opportunity to share his experiences and perhaps an alternative before any vote was made.

I'd suggest a week minimum to avoid people sidestepping it under the guise of haste.