BUIP113: (closed) Support Bitcoin SV with an Official Implementation

[Griffith]

BUIP113: Support Bitcoin SV with an Official Implementation
Submitted by: Griffith
Date: 2019/3/27
Revised: 2019/4/14

Summary
The purpose of this BUIP is to officially add BSV as a supported coin with equal status as BCH instead of considering it a HF configuration option.

Proposal
BSV should be officially supported by as an independent coin from BCH by BU in future releases.

In the event that this BUIP passes, BSV will be considered officially supported by BU as a viable chain that will one day fulfil BU's collective vision for peer to peer electronic cash that can scale to meet global usage.

For reference, BTC was officially supported on the birth of the organization, BCH support was officially added with BUIP 063, BSV HF configuration changes support was added in BUIP 098, and BUIP 113 would officially recognize BSV as a coin and add support for it.

 

[Jonathan Silverblood]

Can we extend this to make a 3rd regarding BTC as well?

 

[Griffith]

yeah. that makes sense to do. its not the release on the website anymore but we do technically still fully support it. i will make a new one for that

 

[torusJKL]

In the event that 113, 114 and 115 fail to pass, the decision for which coins to continue to support is moved out of the hands of members and is given to the elected board members[...]

I don't think this is possible.
You would need a BUIP to change the Articles in order to change the voting process.

@solex what do you think about this part?

 

[Griffith]

@torusJKL i didn't change the voting process. if all 3 fail then we cease to support any coin. This doesnt make sense so someone needs to be the tie breaker to make the decision. It would make sense that it would be the elected board members since the BU members all voted to elect them into those positions.

 

[torusJKL]

If all 3 BUIPs fail than the status quo remains.
Meaning we continue to support all 3 chains.

It might make sense to have a tie breaker rule but such a rule would need to be introduced to the Articles first.

 

[Griffith]

the status quo wouldnt remain in the case of a no. a no vote would indicate specifically to drop support for that coin. a yes vote is required for any coin that is to have continued support. this was intentional by design.

 

[torusJKL]

A no means the BUIP is rejected in its entirety.

 

[freetrader]

EDIT: the comment below was for a previous revision of the BUIPs, and no longer applies.

If all 3 BUIPs fail than the status quo remains.
Meaning we continue to support all 3 chains.

It might make sense to have a tie breaker rule but such a rule would need to be introduced to the Articles first.

The idea of continuing with the status quo if all 3 BUIPs fail seems better to me than having the decision made by a small committee. I agree with @torusJKL here in principle, as it relates to the current set of BUIPs 113,114,115.

 

[Griffith]

after feedback from others i have updated the proposal. it now states if all 3 buips fail no changes are made.

 

[torusJKL]

EDIT: the comment below was for a previous revision of the BUIPs, and no longer applies.

Your BUIP still creates two clauses and assigns them arbitrarely to Yes or No.

Casting a YES vote is a vote to continue to support BCH in the BUCash client.

Casitng a A NO means that support for BCH should be discontinued and any BCH specific code be removed from the code base.

But a BUIP is not a traditional poll and needs to have a single and definitiv outcome when accepted.

e.g.
Discontinue BCH support:
When accepted BCH support is discontinued, when rejected BCH support is continued (status quo).

 

[Griffith]

i am going to stick with it as it is until solex (or another board member) reviews it and tells me it is invalid. My stance on this is firm. The way it is set up right now makes it harder for a coin to remain supported when only a minority of the group wants it. This is because it is harder to get BUIPs passed than rejected and essentially ensures that for a coin to continue to be supported it requires a majority of the groups support.

 

[Griffith]

this buip has been reworded

 

[solex]

OK. Lot's of BUIPs to consider.
@Griffith @Christoph Bergmann
I am going to take a short time to think about the details of them, the implications of any effect that they have on each other in order to suggest possible changes / clarifications.

@Griffith, would you please update yours to reflect the informal formatting standards seen on past BUIPs, especially heading information, and more clearly separate the exact proposal from the background and consequential overview.

 

[Griffith]

will do

 

[Jonathan Silverblood]

> In the unlikely event that BUIPs 113, 114, and 115 all pass BU would have voted itself into a situation where we currently support no coins. Please keep this in mind when voting.

If we were to vote ourself into a position of supporting no coins, it just means that with the current wording of the BUIPs, the BU devs are not authorized to make a release. The wording technically implies that they could continue to build in whatever direction they feel like.

Furthermore, voting ourself into this position is not as bad as it would seem, as all it takes to change it is to add new BUIPs and vote again. Meanwhile, there'd simply be no releases.

 

[Griffith]

@Jonathan Silverblood that is correct. However, this can be problematic if an issue arises with a bug or emergency fork where we need to push out a fix but cannot due to restrictions put in place by BUIPs. IMO it is very unlikely that BU would vote to drop support for all three coins it is still possible

 

[Griffith]

It has been mentioned to me by others that BUIPs 113 and 114, while they seem to make sense, actually don't. At no point in time did BU ever vote for BSV as a coin to be supported so how can we vote to no longer support it?
Reference: BUs' support for BSV stems from the vote for BUIP 098 which stated

The Bitcoin Unlimited client will incorporate features from both organizations and allow these features to either be activated via BIP135 (a generalized form of BIP9 miner voting via version bits), explicit configuration, or (development time and feasibility permitting) emergent consensus. By allowing BIP135, we move to a miner voting process that allows individual features to gain agreement before activation. By allowing explicit configuration -- that is, allowing a user to force the feature “on” or “off” -- people running the BUcash full node can quickly react to any hash-power surprises.

.

This invalidates BUIP 114 in its current state, it should specify the dropping of BSV as supported HF features. This also changes the meaning for BUIP 113, by voting to drop BCH support, it would also drop BSV HF configurations for BCH. This clearly needs to be cleaned up.

The following is a revised BUIP 113:

BUIP113: Support Bitcoin SV with an official implementation
Submitted by: Griffith
Date: 2019/3/27
Revised: 2019/4/14

Summary
The purpose of this BUIP is to officially add BSV as a supported coin with equal status as BCH instead of considering it a HF configuration option.

Proposal
BSV should be officially supported by as an independent coin from BCH by BU in future releases.

In the event that this BUIP passes, BSV will be considered officially supported by BU as a viable chain that will one day fulfill BU's collective vision for peer to peer electronic cash that can scale to meet global usage.
[doublepost=1555248805][/doublepost]For reference, BTC was officially supported on the birth of the organization, BCH support was officially added with BUIP 063, bsv HF configuration changes support was added in BUIP 098, and BUIP 113 would officially recognize BSV as a coin and add support for it.

 

[Griffith]

@solex can you update the text for this one as well?

 

[solex]

@Griffith
Done now.