BUIP114: (passed) Drop support for the BSV HF Config Parameters in BUCash

[Griffith]

BUIP114: Drop Support for the BSV HF Config Parameters in BUCash
Submitted by: Griffith
Date: 2019/3/27
Revised 2019/4/14

Summary
The purpose of this BUIP is to determine if BU is to continue to release clients supporting BSV HF of BCH

Proposal
BSV HF should no longer be supported by BU in future releases in the BCH client.

In the event that this BUIP passes, I will be charged with the task of making a PR that will remove BSV specific features from the BUCash client on Github.
Before my PR removing BSV specific features is merged, a new branch should named BSV should be made to preserve the current release with the BSV features. The new BSV branch will be a snapshot of the current dev branch unless it is deemed unstable by The Developer in which case the snapshot will be of the current release branch.

 

[Griffith]

after receiving feedback i have changed the buip. if all 3 buips fail no changes are made

 

[theZerg]

@Griffith, you need to restate the BUIPs like "if accepted then this happens". If rejected nothing happens. A no vote rejects your BUIP, so you are not allowed to redefine its meaning.

Basically if the BUIP does not pass, your redefinition of "no" is itself rejected! Does that make sense?

If you do not have edit privileges in the OP to fix this, post a reply to each of your BUIPs with them properly stated and I will update the OP with exactly what you put in your reply. Please don't tell me to "change such and such a line like this" because that is error prone.

Since we are currently supporting each of these clients, I think a BUIP to "drop support for XXX" would be the right way to do it.
[doublepost=1553713524,1553712612][/doublepost]And another thing that everyone must understand: BUIPs written in this form only require the Developer to merge relevant pull requests provided that they exist and are high quality. Basically the Developer is authorized to make an official release for this coin. For example, we haven't released a BTC client in a while although we do technically support it because nobody has stepped up and made pull requests for new features, or done the work to conditionally remove BCH features from a build. And other things have been a higher priority for our developers. So community members need to step up and do this work.

Next, you could encourage community members to do this work by allocating some resources to the task. For example, you write a BUIP that authorizes the developer to make a payment of up to X dollars at a competitive rate for work that enables releases over the next year.

If you do this, it is understood that if developers who are currently being paid by BU take the work on, they are not allowed to double-dip.

 

[Griffith]

@theZerg 113, 114, and 115 have been reworded to fix the issue you stated. i have made it clear that they essentially end developer authorization to make an official release for each coin.

 

[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 114:


BUIP114: Drop support for the BSV HF configuration parameters in BUCash
Submitted by: Griffith
Date: 2019/3/27
Revised 2019/4/14
Summary
The purpose of this BUIP is to determine if BU is to continue to release clients supporting BSV HF of BCH

Proposal
BSV HF should no longer be supported by BU in future releases in the BCH client.

In the event that this BUIP passes, I will be charged with the task of making a PR that will remove BSV specific features from the BUCash client on Github.
Before my PR removing BSV specific features is merged, a new branch should named BSV should be made to preserve the current release with the BSV features. The new BSV branch will be a snapshot of the current dev branch unless it is deemed unstable by The Developer in which case the snapshot will be of the current release branch.

 

[solex]

@Griffith
I have updated the OP with this revised text.

 

[Griffith]

Thank you

 

[theZerg]

I have always been treated professionally by the BSV engineers who work on the day to day code. And I can respect a different vision and goal for a blockchain than my own, which is what both the BSV and BCH chains have done to a small degree, while still focusing on the overriding goal of mass adoption.

But although a blockchain should be leaderless, nChain-affiliated individuals have taken on the mantle of leaders of the BSV effort. When do we let statements by these self-appointed leaders affect what should be a decentralized, peer-to-peer, leaderless blockchain?

The litigation by Craig Wright over tweets has personally tipped me over the edge. He was one of the worst tweeters in my opinion.

And there is a generally accepted method to prove you are Satoshi -- sign statements either with Satoshi's GPG key or with a lot of early unmoved coins. Anyone who claims to be Satoshi but does not do this or provide any explanation why he's not doing this should realize that there is great reason to doubt such a claim.

Not doing so is in essence a rejection of core blockchain philosophy, which is inaccurately summed up by its detractors as "code is law". A more accurate but dry description of the philosophy is perhaps "the blockchain can avoid the need for legal recourse in many situations." Like international payments. Or low value escrow. Or proving identity.

And just as importantly, I believe that people have the right to express their opinion on unsubstantiated claims without fearing litigation.

So I believe that we should drop BSV support in a small protest against this behavior, until the situation changes.

 

[Christoph Bergmann]

Thanks for stepping out of the nebula Andrew, although your post makes me very sad.

As I said: I don't think that BU membership can decide upon what you do with your time. If you don't WANT to build on BSV, no membership vote will change it, and it should not change it.

But excuse me for this comment:

> And just as importantly, I believe that people have the right to express their opinion on unsubstantiated claims without fearing litigation.

Nobody ever can disallow people to "express an opinion on unsubstantiated claims" by law. Every opinion is allowed, as stupid and wrong it be. But it is not allowsled
- to campaign an opinion in a way that it destroys someone elses reputation
- to state opinions as a fact

I can say: "I believe Andrew is a scammer".

But I can't do this all day long on all social media and encourage other people to do the same. This would be campaigning.

I also can't state: "Andrew is a scammer". This would be no opinion, but a statement of fact.

What happened on twitter was both: Campaigning and statements of facts. I sincerely believe that it must be the right of every single person on earth, no matter how bad they are, to use law to fight such thing. If we don't allow the worst scammer to defend against campaigning of unsubstantiated statements of facts, we will all fall pray to reputation killing troll mobs.

--

Anyway, I don't believe I can change your mind on those things, and it is not what I want to do. But I can't resist to state this:

By dropping support from BSV you drop support from the only implementation of Bitcoin which represents the vision with which Bitcoin Unlimited did start. And I think you know this.

Beside this you get in total addiction of someone who disrespects you much more than Craig would do and will take any chance to block all you do. You give away every single strategic trump you have, just for free.

 

[79b79aa8]

i also understand theZerg's discomfort. but fwiw i think the conclusion reached:

>So I believe that we should drop BSV support in a small protest against this behavior, until the situation changes.

is ineffective, and as CB points out, probably counterproductive.

BU dropping BSV support affects their plans not one bit. even if the protest registers, they move right on.

meanwhile, will BU keep up with BSV's focused scaling efforts if not maintaining a BSV client? what for? things might be different if BU had a bigger say in the BCH roadmap, but it does not.

i also doubt the situation will change. if anything, it tends to get worse.

 

[freetrader]

BU scaling efforts appear substantially more focused to me than SV's.
Perhaps that's only from what one can see publicly, but that is still the SV crowd's shortcoming.

I'll give a few examples:

- parallel validation and ATMP optimizations already implemented in BU, BSV catching up
- Graphene implemented on BU, haven't seen BSV mention plans regarding huge-block propagation plans

BU's GTI tested utilization levels which have never been seen on BSV yet, and they're preparing to exceed them in the next run of tests.

I suspect there is anxiety that BU will continue to outscale BSV clients while SV is not willing to finance developers to maintain a compatible BU version for their network.

 

[79b79aa8]

hey @freetrader, what's your view on these questions:
will BCH post 128 MB, 512MB, 1GB blocks within the next year?
will it be a battle to lift the limit for each successive increase?
do you think a dynamic blocksize limit effectively counters the fidelity effect?

i read BSV is not planning to implement graphene, but i don't know why or what their proposed alternative is.

 

[freetrader]

will BCH post 128 MB, 512MB, 1GB blocks within the next year?

I'm assuming you mean mainnet? Impossible to predict, since I doubt BCH miners would conduct mainnet test runs simply to max out a possible limit. They would do so on a testnet. I believe the BUCash is reach of demonstrating ~256MB sustained blocks with realistic transaction load within the next 12 months. That would be ~1000 tx / sec with a bit of math fuzziness, which is a near term goal that BU devs have hinted at.

I'm not sure what advancements other client projects will roll out in that period, so it's hard to estimate what BCH overall could reach in that timeframe. I'd be positively surprised if we reach 1GB block capability, or well over 5000 tx / sec. It's a lofty goal. I don't see any other chain reaching anywhere near that on currently open sourced software.

will it be a battle to lift the limit for each successive increase?

I don't know in what sense you mean.

Technologically there will be challenges.

But the limit could be lifted by individual clients as they deem safe, and people considering to run those clients should look at the test evidence and conduct their own verification of the client performance.

do you think a dynamic blocksize limit effectively counters the fidelity effect?

Depends on the proposed algorithm. Removing the limit completely is not an effective counter in itself, since effective capacity does not simply depend on that.