BUIP 166: Launch a Chain for Proving Next Generation Features

BUIPs
21

@solex I don’t think there’s a single person who doesn’t share the desire to improve BCH. What the right price should be, however, isn’t anything I much worry about. You’ll note that this “poor performance” is better than 100% gains in one year. I’ll take that all day long. I think it’s a positive thing that BCH is one of the few cryptos that isn’t strongly correlated to BTC - for better or worse. It means its value is coming from actual use more than purely through speculation. But the only time we can say we’ve “won” is when prices of goods and services are denominated in BCH rather than fiat. Naturally I’m happy when the value of BCH goes up but it’s not a key target.

Completely agree. But this BUIP isn’t the way to go about it for all the reasons I specified earlier.

I’m fine with 2 minute blocks if someone writes up a CHIP for it and it gets accepted. I see ZERO need or utility for launching a new blockchain to show BCH how a 2 minute block works is the point I was making.

FWIW BCH is responding to the market faster than any other established operational crypto from what I can see. That is precisely why my company has adopted it. And I do want it to go faster which is why I pointed out the things in my prior comment on how that can be accomplished. I don’t think the market is asking us to launch a new block chain and I’m confident that it will do the opposite of increasing velocity of BCH innovation…

1 Like
22

@scherry. OP_RETURN is a poor venue for trying things out because it:

  1. cannot deliver critical features causing users to go elsewhere. This causes the value of the full feature to be underestimated.
  2. creates “cruft” on the blockchain if the chain moves the feature from OP_RETURN, because you can’t remove the feature on OP_RETURN, possibly EVER without destroying someone’s value.
  3. requires MORE code changes to the ecosystem. This may be unintuitive. But consider the easiest case where BCH takes a feature verbatim. In that case, the code changes constitute just indicating a different genesis block and port! For real examples, look at group in NextChain and group as proposed in BCH. The changes are removing some features, flipping the attribute order in scripts, and changing how the hash is generated. These are trivial changes to implement given group’s Nextchain implementation, and are isolated in the lowest layers. Now consider moving from SLP to group (group is architecturally similar at low levels so this is a fair comparison). Its a complete rewrite. The lowest level parsing engine is totally different. Entire functionality does not exist like merkle proofs. This missing feature requires an entire architecture change, that affects the full ecosystem, notably at the user/wallet level, where SLP nodes create and keep track of the SLP UTXO and wallets must access those nodes.
  4. There’s lots of things that you simply can’t implement in OP_RETURN.
23

That’s a bold conclusion that ignores the fact that OP_RETURN can and does allow you to build some quite innovative features.

And people building on OP_RETURN knowing its temporary aspects will plan ahead for migration options when/if their capability gets adopted to the core protocol as is obviously possible with SLP and also our auction protocol.

May or may not. Doubtful that the difference is a significant factor in the feature being adopted by BCH or is enough that the time required grows to be an impediment for one option over the other.

Your response seems to come down to OP_RETURN can’t do everything I want so I need a new blockchain. You’ll note that I also pointed out SmartBCH as another mechanism for experimenting with BCH features. I’m neither looking for nor proposing a panacea solution. That’s what you’re doing.

Shall I take your silence on the rest of my points in my prior comment to be confirmation of my understanding of your positon?

24

@JonathanSilverblood We already and have always wanted different things. Opening this sandbox won’t change this. My history in BCH has been to push it forward with new features against MANY people who believed that scalability would be enough. This was the prime argument against group tokens. This latter view has been proved wrong in the last few years, but we are still moving too slowly, and a nontrivial minority still hold this view. We need to SHOW people what can be done.

Jonathan, this BUIP is actually in part inspired by something you wrote on Reddit:

“It also took this exact approach: things that was tested and proven in other ecosystems (like schnorr signatures) have ended up getting implemented on BCH.”

If our approach is to only take things that are tested and proven in other ecosystems. We will never have the first mover advantage. This new chain will address this problem by allowing us to test AND PROVE (as you point out that is very important) ideas in a low-value chain. BCH can then be the first mover for any major chain.

25

I’d like to address the elephant in the room that I think is scaring the naysayers but nobody will admit it:

What if this chain grows to be greater than BCH?

Let’s look at what really happens. Let’s look at BCH and Bitcoin. What about ETH and Bitcoin? The first mover advantage is HUGE. Even a coin as amazingly functional as ETH hasn’t flipped BTC in years. Sure it might in a decade because Bitcoin utterly refuses to scale or innovate, but is that what BCH will do? I do not think so. And to really grab the bull by the horns: a new coin will only flip BCH if BCH actively rejects the area that this coin innovates in, like BTC is doing with respect to ETH by focusing solely on store-of-value use cases. In this case, is it really a problem that this new coin is popular in an area that is uninteresting to BCH?

Let’s look at LTC and Bitcoin. How many times have you heard the coretards say “use LTC for now until Bitcoin get’s its lightning scaling going”. This was a super-effective argument. It directly damaged BCH adoption because our story is that people should use BCH due to scaling problems with BTC.

We will be able to use the SAME argument: “just use NextChain now, and the feature is likely moving into BCH soon.” This will be an extremely effective argument.

This chain could do for BCH what Litecoin has done for Bitcoin.

Rather than imagine a worst-case scenario that’s never happened, I ask all member voters to really look at the history of crypto and what has worked (for us and our competition) and what has not.

1 Like
26

A common theme around all major falls in BCH rank has been artificial internal strife caused by malicious actors not getting exactly what they want. First CSW, then Amaury, we’ll see how much damage this one causes yet - hopefully not as bad.

1 Like
27

What do you mean with BCH resources?

28

@imaginary_username It is beyond insulting to equate me with those individuals. One wanted to freeze all development, the other could only steal innovation from elsewhere. BU and I have been a major innovative force making the RIGHT decisions. This is why our finances are solid. And technically, CDS is arguably the ONLY feature in the history of BCH that has enabled major new use cases and it’s directly stolen from my original DSV proposal, including the name. I am making the right decisions both in business and technically.

And both individuals looked for personal power beyond anything else. On the other hand, when I founded Bitcoin Unlimited, the FIRST thing I did was create the articles that delegated my power.

If your statements are so completely the opposite of demonstrated history, you need to reassess the entire chain of logic that got you where you are. And frankly, your publicly claimed “went all in BCH early” is massively coloring your judgement, making you conservative and afraid to make the very changes that will make BCH successful.

By equating me and this proposal with those people, you also end up making bad choices because your choice is not based on rational thought. Its based on a logical fallacy: if A is like B and resulted in C, then D being like E implies F. But A,B and C are completely different than D,E and F which is why this oh-so-human way of thinking is totally flawed.

I have a history of both making positive contributions to BCH (some stolen and reworked), encouraging and working on other people’s positive contributions (lots of stuff from the ptschip and the other BU devs, the BCH documentation proposal, etc), supporting the leveraging of 3rd party work (sickpig’s explorer port and dagur’s electrs) and making the right choices in both business decisions and my own technical vision (even though many did not make it into BCH, they have been proved to be a good idea based on industry trends).

This is the right choice for BCH, because it allows us to innovate and to prove usefulness of a feature and then bring that to a much broader cryptocurrency (BCH), along with active companies providing services and additional users, who would be financially motivated to do move to a more widely used crypto and so be the drivers and funders of the required work.

For example, subgroups were eliminated from the group proposal. But they make great NFTs. They have unique attributes that other NFTs don’t have. We need to have a place where subgroup NFTs can prove their value so that they make it into BCH eventually. And if some NFT company was successful with them, then they would have the finances and incentive to shepard subgroups through the BCH proposal process.

SmartBCH (for example) cannot do that because its technology, its architecture, is completely foreign to that of BCH. If a company has a service on smartBCH there is little value to putting the time and effort into moving it to native BCH (if that would even be feasible), because its already kind of “on” BCH. But there is tremendous value in moving to ETH!!! Where do you think a successful company on smartBCH will put its resources?

SmartBCH, if successful, is a black hole that will eat the BCH ledger and spit it out as Ethereum (and let me credit @griffith for first making this observation), but more likely it will just go zombie, since any startup will begin on ETH in the first place. If you don’t understand this, you don’t understand the crypto environment.

29

I’m not sure you’re correct about that.

30

I have multiple criticisms to this proposal. I will probably submit them as individual comments, this one being the first, so people can respond more easily to each one.

if I, Andrew Stone, OR you the voters pass a BUIP, then the feature will go in (subject to the normal BUIP rules of providing an implementation, undergoing code review and security analysis, etc)

In my view, this is clearly a proposed development activity which bypasses the rules of procedure of the Articles set around BUIPs.

This alone would merit my voting against this BUIP. If someone feels that the framework of the Articles is insufficient for their innovation, they should strive to amend the Articles OR separate their work from their BU activities, but not try to bend the rules and sidestep membership direction.

1 Like
31

In my view, this is clearly a proposed development activity which bypasses the rules of procedure of the Articles set around BUIPs.

This IS such an amendment (ONLY for this new chain) which is why it is stated here. There are 2 purposes. One, and the most important, is to white-ball and fast-track features into this more experimental chain. The second is to provide assurances to users that the chain may continue if BU votes to abandon it.

Note also that this isn’t a huge change to how its done for the BU BCH client. Today, I have the power to put features into BU’s BCH client without a BUIP. The difference is that the membership can raise a BUIP that would prevent that feature from being part of an official release, if passed. I also have the power to create unofficial releases on the BU downloads page…

1 Like
32

to provide assurances to users that the chain may continue if BU votes to abandon it.

The difference is that the membership can raise a BUIP that would prevent that feature from being part of an official release, if passed.

Thank you for confirming that the proposed clause would sidestep BU membership direction (and essentially: views) on the technical development and merits of existence of this new coin.

I stand by my opinion, and I am also not impressed by the proposal’s attempt to change the articles without so much as a formally proposed set of differences against the existing Articles, yet expecting the membership to vote on it in this state.

2 Likes
33

I’ve said it elsewhere, but perhaps it’s useful to reiterate here: BU is generally expected to be a BCH organization, to most of its supporters, people who operate BU nodes, and people who contribute funds to it. It gains almost all its current relevance as an organization that maintains a widely used BCH client, organizer of BCH events, and a venue for BCH research and development. Hence I’ll consider the organization itself to be a “BCH resource” for all intents and purposes. It is reasonable for the organization and its officers to disagree on BCH development/procedural directions and attempt to change that through various means, pleasant or not…

…it’s not reasonable to launch an altcoin from that position. The only other major example I can think of, Parity, at least had the decency to formally quit Ethereum before launching Polkadot.

2 Likes
34

I see, thanks for the clarification. Speaking of Parity, I have a vague memory of them developing a BTC/BCH client back in 2017, but maybe I’m misremembering.
Just want to add that at best of my understanding BU will maintain and develop a BCH client even in the case BUIP 166 (in its present or future amended forms) will pass.

35

this BUIP allocates 40000 USD annually to acquire and deploy hardware associated with this new blockchain – full nodes, explorers, web properties, and mining nodes.

I would ask for a further detailed breakdown of these estimated costs just as a matter of course.

  • how many full nodes and what sort of processing capacity per node?
  • what sort of mining nodes, given that the precise POW seems not to have been decided yet? is there a target for share of hashrate do you expect to achieve and maintain?
  • would the above infrastructure need to be permanently acquired? what other options have been considered? Were the projected costs of alternatives quantified somewhere?
  • explorers, web properties - can you list up what would be required here per year, in more detail, both for acquisition and maintenance costs?
36

All such development activities will occur within and as part of existing BUIP budgets.

Can you please list the existing BUIPs under which this development will occur, and their total available budgets which would hereby at least be shared with this new coin.

All prior BUIPs (such as Group Tokenization) can be satisfied by being initially deployed on this new blockchain.

In layman’s terms, and correct me if I understand it wrong:

If an existing BUIP is implemented on this alternative coin, then the BUIP is considered to be completed, even if it has not been implemented on Bitcoin Cash.

Extrapolating this, I would expect that any further activity to “backport” changes from this new coin to BCH, would need to have new BUIPs opened and passed by membership, even though they may have already voted to implement a BUIP on BCH - is that correct?

37

this BUIP allocates 40000 USD annually to acquire and deploy hardware associated with this new blockchain – full nodes, explorers, web properties, and mining nodes.

I would ask for a further detailed breakdown of these estimated costs just as a matter of course.

This budget was meant to be a maximum value and so no details have been made. I will try to answer your questions as to my opinion on them:

how many full nodes and what sort of processing capacity per node?

About 5 and very minimal processing capacity since there will be very little onchain activity for years.

what sort of mining nodes, given that the precise POW seems not to have been decided yet? is there a target for share of hashrate do you expect to achieve and maintain?

They will need to be CPU nodes. There is no target hashrate. The only intention is that BU ought to have some coins on the chain. The intention was to grow the mining to the budget specified, minus the other costs.

would the above infrastructure need to be permanently acquired? what other options have been considered? Were the projected costs of alternatives quantified somewhere?

Not considered. Permanent tends to be cheaper over the long term…

explorers, web properties - can you list up what would be required here per year, in more detail, both for acquisition and maintenance costs?

An explorer, an an info page like is found in www.nextchain.cash. I have not considered the amount in detail, these are not high costs.

38

All such development activities will occur within and as part of existing BUIP budgets.

Can you please list the existing BUIPs under which this development will occur, and their total available budgets which would hereby at least be shared with this new coin.

The intention is that any development activity could use this nextchain as a stepping stone.

All prior BUIPs (such as Group Tokenization) can be satisfied by being initially deployed on this new blockchain.

In layman’s terms, and correct me if I understand it wrong: If an existing BUIP is implemented on this alternative coin, then the BUIP is considered to be completed, even if it has not been implemented on Bitcoin Cash.

Extrapolating this, I would expect that any further activity to “backport” changes from this new coin to BCH, would need to have new BUIPs opened and passed by membership, even though they may have already voted to implement a BUIP on BCH - is that correct?

This wasn’t my intention at all. The problem is we have no control to “close out” or “finish” hard fork dev BUIPs since we cannot control whether they get into BCH. At a very minimum this means it looks like we’ve made no progress… but in the worst case if there is financial or people attached this could be an unending drain when the project is going nowhere.

A proposal to add the feature into BCH should absolutely be part of each BUIP. I sort of considered a deployed working feature in this coin to be implicitly a proposal, which is why I worded it that way. Let me change it.

EDIT: OK, I’m not sure if I can change the original post yet in this forum. Let me talk about the wording here:

CHANGE:
All such development activities will occur within and as part of existing BUIP budgets. All prior BUIPs (such as Group Tokenization) can be satisfied by being initially deployed on this new blockchain.

TO:
All such development activities will occur within and as part of existing BUIP budgets. All prior BUIPs (such as Group Tokenization) can be satisfied by being initially deployed on this new blockchain, and being proposed for BCH via the CHIP system and supported throughout the BCH evaluation.

39

Thank you for confirming that the proposed clause would sidestep BU membership direction (and essentially: views) on the technical development and merits of existence of this new coin.

I stand by my opinion, and I am also not impressed by the proposal’s attempt to change the articles without so much as a formally proposed set of differences against the existing Articles, yet expecting the membership to vote on it in this state.

This proposal in no way changes the BU Articles. This clause refers ONLY to development of code on this new chain, allowing me to maintain it. It does not change anything about BUIPs or the BUIP process.

I realize that this might be stirring the hornets nest, but in clear conscious I cannot listen to the above comment without noting that you freetrader are running BCHN without any process that binds you to a process and by extension, BCH follows the same.

Even though people have produced a proposal process, I am unaware of any formal, process-and-schedule-based way that such a proposal is accepted or rejected and unaware of who has power or influence to do so.

So the decision of what goes into BCH ultimately rests on you. You have had a year now to delegate authority to a system or process and you have not done so. This decision of yours has massively influenced our decision to write the BUIP, since there is absolutely no clear way to see how to drive features that BU wants accepted (or even rejected). There’s just an unclear and undefined idea of “consensus”, without even any idea of WHO needs to agree.

So it is extremely disingenuous for you to take this stance.

40

This IS such an amendment (ONLY for this new chain) which is why it is stated here.

This proposal in no way changes the BU Articles.

Two statements from you which I find contradictory.

How should BU be expected to carry half the decision making responsibility for this new chain if it is not going to be reflected in the Articles.

Sorry Andrew, it makes no sense to me.

Perhaps the (proposed) governance documentation of the new chain should be part of this BUIP, so that members can more fully appreciate the situation.

This characterization is both inaccurate and unfair. First of all, maintainers in BCHN have bound themselves to documented rules and guidelines. Secondly, to say that there is no process we are following in BCH development itself is grossly misrepresenting the state of BCH development. No matter that you disagree with the CHIP process, it is following the principles of emergent consensus and open collaboration that first attracted me to BU, but which seem to have been somewhat eroded under its current leadership.

There is good discussion on this on the BCR forum, for example in this thread:

We are working in a CHIP process which has been shaped in significant part by BU developers/contributors, and in which no party gets to finally prescribe to others what the process is, but we nevertheless follow and refine a common process (CHIPs) which presently includes some scheduling in the form of milestones etc.

It does seem from your comments that BU leadership is not aware or not on board with this process. I hope I’m wrong. Speaking as a BU member.

Anyway, you can find more details here:

I hope it’s clear that a criticism of complete lack of a process in BCH are not well founded. BU developers have been already actively and positively participating.

I will need to continue my reply in a second post since the forum is limiting me to two links per post, as a “New User”.

1 Like