BUIP108: Support for the BCH and BSV chains

[torusJKL]

BUIP108: support for the BCH and BSV chain
(names in alphabetical order
Submitted on 30 December 2018 by torusJKL

Background
On November 2015 the BCH network split into two (noteworthy) chains.
BCHABC with the ABC rules (hereafter BCH) and BCHBSV with the SV rules (hereafter BSV).

The BU community is split and no clear preference in regards to which chain should be supported henceforth can be identified.

Motivation
Because of the split in the community BU will most possibly not be able to decide with a majority which chain should be supported in the future.
Thus the motivation of this BUIP is to keep BU compatible with both until a new vote will overrule this BUIP.

Goal
Until a new decision is made, every future BU release most be maintained for both chains in a way that none of them are neglected in favor of the other.
Security updates and consensus changes should be implemented as required to be compatible with the respective chain.

A release which does not support the above musn't be endorsed by BU and musn't be made available using the official channels.

Timetable
Ungoing until canceled by a new BUIP.

 

[torusJKL]

@solex please add this BUIP to the index.

 

[Griffith]

can someone (maybe @solex) clarify how a NO vote on this BUIP gets interpreted? Does that mean that we are voting for the client to not support both chains in the future? Or does it just mean that we are voting that we dont keep supporting both (even though that is what we are doing now and in the case of a NO vote winning, is confusing)

edit: if a no vote does mean we are voting to not continue to support both clients does this mean a new vote on which client to support is triggered immediately/automatically? or is it up to the newly elected lead dev to select which chain(s) we continue to support?

 

[solex]

Hi @Griffith,
Indeed. It can do with clarification.
@torusJKL
Would you please add a paragraph as to exactly how this BUIP is interpreted as a change from the current situation, in the cases of BUIP108 being a) passed or b) rejected.

 

[Griffith]

@torusJKL can i request a more straightforward BUIP where the voting options are "bch only", "bsv only", "both chains", and "abstain" instead of your current system? im pretty sure thats what we all want to know at this point anyway

 

[theZerg]

BUIPs do not have the contrapositive property. In other words, if this BUIP does not pass it absolutely does not imply that we will not support both chains.

If a BUIP doesn't pass, it only means that the membership gives no direction to the officers in the matter.

If the BUIP is rewritten as @Griffith suggests, doing so effectively rolls several BUIPs into one vote. This means that the option with the largest number of votes does not necessarily win. The option must garner enough votes to pass as per the BUIP voting rules...

It might be simpler to have 2 separate BUIPs: support BCH chain and support SV chain.

 

[Griffith]

Alright, then if the BUIP as it currently stands is closed with a vote of no, that means we aren't obligated by communal vote to support both clients but doesn't mean we cant continue to do so. This makes sense.

@torusJKL ignore my previous suggestion about specific chain options in the vote. @theZerg is right, my suggestion adds unnecessary complexity where a vote for both would have to be counted as one for BCH chain and one for BSV chain during the tally. Separating this BUIP into two new BUIPS, one for bch, one for bsv, would be better

 

[solex]

I agree that this BUIP makes more sense to request the support it wants just for the SV fork. Why is BCH even mentioned?

BU will most possibly not be able to decide with a majority...

This premise looks strange. BUIPs are normally passed by a majority with some opposed, or a few are unanimous with none opposed. I don't think it can go up for vote while it disputes the ability of the BU membership voting to achieve a majority result.

BUIP098 approved compatibility with SV. A main plank of SV is the "protocol lockdown" meme, which then begs the question of why SV would introduce a protocol change potentially kicking BU and other implementations off their network?
So, it does not seem to be an urgent matter anyway.

@torusJKL
This BUIP needs more of your input, please.

 

[solex]

It is proposed that this BUIP be separated into two for simplification purposes. The membership needs to be clear what it is voting about. One BUIP for BCH and one for BSV will add that clarity. In the absence of further feedback and revision, I will defer this BUIP until the next BU vote.

 

[torusJKL]

Why is BCH even mentioned?

BU votes do not mandate any developer to do anything.
Would this be about only supporting BSV without mentioning BCH and no developer would be willing to do the work than BSV would effectively be left behind, like many BUIPs have in the past where no volunteer was found and no devpool ressources were allocated.
(The same would go for BCH if all volunteer work is done on BSV)

The idea of this BUIP is to lock those two releases together in resources.
It would not be possible to release either version without also releasing an equaly maintained version of the other chain.
With a vote for this BUIP the members enforce their will and not just ask for it and hope for the best.

If no volunteer devs can be found than BU could use the devpool to pay for the maintenance needed to support this if it wishes.

 

[Griffith]

@torusJKL thanks for the clarification.

This essentially means that in the event of a highly morally controversial consensus change on one of the two chains (example: BSV miners claiming coins that meet a certain condition like being too old or being split with DSV), we are bound by this BUIP to continue to maintain said chain until this BUIP is replaced with a future one.

This will be a hard no from me.

 

[solex]

@torusJKL

Unfortunately, I am not seeing any clarification to the BUIP. None of the feedback given to you above has been used. This BUIP disputes the ability of the BU membership to reach a majority decision, which is clearly false.

At present, compatible full-node implementation support for BCH is authorised via BUIP055, while BSV is authorised by BUIP098. This position will remain ongoing unless new BUIPs are passed to change the nature of the support, or remove it completely. So there is no clear need for a further BUIP on this point.

consensus changes should be implemented as required to be compatible with the respective chain

We also cannot easily give a blank cheque to any future consensus change. That is a very significant membership decision so it should be the focus of a BUIP with an appropriate name, so members are clear what the BUIP is about.
The first consequence of this would be immediate compliance with the rolling 11-block checkpoint change.

I take issue with the assertion that most BUIPs are not actioned. Most BUIPs are actioned. It is just necessary to understand that someone taking 10 minutes to write a BUIP, as a high-level request, can also take someone else 10 months of work to make it happen, after it is passed by vote.

 

[torusJKL]

@solex
I respect your position and accept that this BUIP is not going to be voted upon in the next vote.
I might take the liberty to change the BUIP in the future and request a re-evaluation.

 

[solex]

@torusJKL
I appreciate your view above and agree it is the best course of action. This BUIP warrants having more time to consider the details ahead of a subsequent vote.