BUIP 166: Launch a Chain for Proving Next Generation Features

I am a little shocked, and dismayed, to read this. Again, I find it to be far from reality.

My position in BCHN does not let me decide what goes into BCH.
At all.

I am one of several maintainers with the same effective powers to commit to the BCHN repository, and BCHN is but one of several node projects in BCH, from which users are able to freely choose.

Are you expecting some kind of central committee to approve what is accepted into consensus and deployed in the Bitcoin Cash network?

Such a thing does not exist, and I will continue to work towards ensuring that Bitcoin Cash development is able to follow a more open, decentralized and evidence-based course. The thinking and kind of process which I espouse there is very well described, generally, by a series of articles which I highly recommend reading:

I would say this has generally been working well in the fledgling CHIP process.
Obviously, your take on that is radically different.

Delegate authority to do what, exactly? You are misguided in your belief that I wield some kind of special power. I am a Bitcoin user, a developer, a BU member. I happened to take up the responsibility for the BCHN project when ABC leadership failed the Bitcoin Cash project.

I have fought, since entering into BCH development, for the vision that the Articles in BU represented. Not for a monoculture under one project or foundation, but of a diverse community, held together by a common vision for p2p electronic cash. What we used to refer to as Satoshi’s vision before a group of frauds misappropriated that terms.

So please don’t patronize me about delegating authority to anyone. We all run the code we want to, participate voluntarily in this. And occasionally re-read the Letter from the CEO of Bitcoin Cash.

I must read this as your personal rejection of the CHIP process.
How else am I to understand this?

Work is ongoing on the Group CHIP, the projects were working well with bitcoincashautist, it is a long process because it started out as a complex proposal but has since been simplified.

One of BCHN’s maintainers has already written code and we are planning to evaluate it.

Should we discuss whether that needs to continue?
You are sending very mixed signals here about BU’s commitment to work together with us - and also the other projects - who are trying to follow and establish sound process for getting consensus changes into the protocol. A process that does not and should not depend on the whims only of lead developers or maintainers, much less in a single project, but tries to involve the wider set of stakeholders, unlike before under ABC, or Core, where such stakeholders interacted more or less with their designated development team. That didn’t always work out too well.

P.S. The role of maintainers in BCHN is simply one of stewards of the code base and to interact with the other contributors to the project and make sure that developments are moved along where they can be.

If I hold any special powers within BCHN, I am not aware of them but welcome instruction. I hold a more or less symbolic role as “lead maintainer”, but in reality this doesn’t amount to special privileges, rather it confers some duties to account for the project, which I try to do best I can. (I can link you to our most recent Financial Report, if you wish. Can I request you link me to BU’s? This topic interests me greatly, and has for more than 1 year, speaking as a member.)

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.

This BUIP laid it out clearly. If BU passes a BUIP, it goes into the new chain. If I add a feature, it goes into the new chain. Its a “white ball” approach – neither party can block the other’s features. Its an OR not an AND. So it doesn’t really make sense to speak about this as “half” of the decision making responsibility. Its more like we both have all of the decision making responsibility.

What I said was entirely fair and accurate. I said “… running BCHN without any process that binds you to a process”.

A process is like an algorithm. It needs to be clearly defined. And “binding” means a commitment to follow the algorithm.

We can’t detangle the entire chip process here. But in its very title it says it is “guidelines”. Not rules. The majority of it talks about “community members”, etc. I can run the entire top portion with the some community members since who they are is undefined and someone else can call the entire process invalid because I was missing somebody.

The only portion concretely identifies a process that can be exactly followed is the “Dispute Resolution” section. But that section explicitly says:

“It should be noted that this dispute resolution process still cannot, in the strictest sense, coerce any given node team into implementing any change.”

However, I will admit that I was not aware of the more detailed process document. If that and any similar statements are removed, and if BCHN committers make a publicly stated commitment to follow the document, then I agree that this “dispute resolution section” constitutes a clear process. The rest of the document (the portion that ideally we should follow 95% of the time) still is, as titled, “guidelines” – more of a general strategy to get something adopted, and not an actual process.

What happens if you put in a feature, but a BUIP is passed to remove it?

Or if a BUIP puts in a feature, but you put in some changes that override or alter it?

Who will be committers to this new coin?

its a white ball, not a black ball, so the feature goes in if EITHER a BUIP is passed or I want it in.

Although this is algorithmically impossible to determine, I think all of us humans can figure out the real intent behind a change and nobody will be fooled by an “addtion” that actually turns off a feature. Frankly I think it extremely unlikely that there be conflict since the philosophy will be to encourage the safe deployment of new features rather than to require that such a feature be proven useful or valuable before it exists. Of course, someone will have to actually deliver the feature – remember that passing a BUIP does not enjoin BU to run off and implement something. Someone still has to do the work. This has been shown to be a pretty good deterrent to frivolous features. But yes, there will likely be quite a few features that people thought were going to be useful but just ended up not as useful as we thought. And this cruft may cause problems for the chain and require extra maintenance.

This is the point of deploying things on this chain first before BCH, and proving a real growing use case and user base before merging to BCH.

Nobody commits to a “coin”. But the source in the BU repository will be what BU releases and so follow the normal rules for our source. For your review, the President is the ultimate owner of the BU repo, and he delegates commit authority to the Developer and those people that the developer authorizes to commit. If someday I am not the Developer, the next developer will need to merge my commits, or be breaking this BUIP agreement (or in the case of BU abandonment, something else can be worked out).

I don’t think “mind reading” Andrew’s intentions is useful at all. Clearly the guy has invested tons of energy into making BCH the best crypto around and frustration that he doesn’t feel like he’s made the progress he would have liked is understandable. Especially after having been in the space for so long.

I have a similar perspective. I was involved with BTC since it was announced and left it for a long while when I saw technical decisions going in a direction that didn’t seem to align it with its ultimate potential and the focus of most conversations became how much it was worth rather than what we can do with it. I’ve since been heavily involved with Stellar and Ethereum which had rapid - then none - then stuttered innovation issues as well until last year when I discovered BCH.

So our time line horizons and perspectives of progress for BCH are drawn from different experiences. There is no question whatsoever that the (otherwise attractive) idea of a fresh start as proposed will absolutely not help BCH in my mind. I myself have grandiose plans for a cryptoledger ecosystem that will revolutionize our economic lives and social/political ones as well. I’m quite satisfied that BCH is set to fulfill a key role in that vision and am invested in building upon it even though I realize that the BCH we have today is not yet adequate. But I can see that it is going in the right direction - perhaps not as fast as I would like - but the right direction nonetheless.

We may have different ideas on what the ultimate destination should be - but there shouldn’t be any disagreement that we’re all looking in generally the same direction in terms of how to get there from here. I judge BUIP 166 not on its specific destination but rather upon the direction that I think it takes BCH. I’ve raised specific concerns about how this proposal can possibly align with the direction I think BCH should go and that I think it overlaps considerably with Andrew’s intended direction as well. Those issues have not been addressed adequately at all so I am convinced this BUIP takes us the wrong direction regardless of whatever intentions he has and should be rejected.

Even more importantly, however, it is my sincere hope that after this BUIP is rejected that Andrew will give the CHIP process a chance and work with me and the community to improve the issues I raised in the forum so that the kinds of improvements that both him and I clearly want can come to BCH.

The personal attacks do not help at all. But Andrew should recognize that his proposal clearly raises the spector of recent circumstances of damaging splits within the community despite his (entirely inadequate) assurances to the contrary.

We need more people trying to figure out how to work together to improve BCH rather than looking for divisive opportunities due to fear from prior events. Looking forward is the only way to proceed and I don’t want to lose key people because we couldn’t debate a proposal in a civil manner. That’s the most likely outcome of this situation right now and it must be corrected immediately.


This whole thread is a consequence of the impossibility of decision-making without a decentralized voting mechanism.

A centralized forum, slack, telegram or reddit cannot be the solution to The Byzantine Generals problem.

No matter how hard you try.
Only hashpower voting can decentralize the development of the Bitcoin Cash blockchain.

@AndrewStone You have the right to do what you want. And Bitcoin Unlimited has the right to make its own cryptocurrency. But I ask you to please postpone this initiative until 2022 or some months. There is no rush to consummate irreversible acts.

In 2019 I wrote 3,000 code lines open-source that no one has reviewed, for a decentralized voting system that meets the needs that now are already obvious (three splits are enough, okay?).

@freetrader I formally request that BCHN deploy a independent BMP node in:

@AndrewStone I formally request that BU deploy a independent BMP node in:

You can participate right now by mining with low hashpower in P2Pool.

Like a blockchain explorer, all nodes will display the same content in real-time.
Out of my control, and yours.

I have to admit that I alone do not have enough influence to accomplish this.
But if all of you request it in unison, the miners will listen to you and participate by delegating hashpower to the devs (zero cost). And so, you will be able to resolve any dispute, big or small, in a civilized, peaceful and professional manner. Talking and voting with hashpower.

If I am right, keeping us together and skyrocketing Bitcoin Cash development to a new level.

I can’t guarantee what will happen next. No one knows. I’m trying to discover it.
But I guarantee that the BMP code is 100% decentralized.


1 Like

I would like to throw my support behind this BUIP. I became involved in this space back in 2013 with the goal of putting control of our global financial infrastructure into the hands of the people. In that time, I’ve come to realize that digital cash is not a sufficiently versatile tool for achieving this end. IMO, the market has also validated this view.

In terms of blockchain loyalty, I believe that we are too early to call a winner and drift into maintenance mode; innovation is critical. Many new projects will begin and end before this financial revolution is complete. They do not need to be mutually adversarial. The project proposed by this BUIP is an attempt to inject new features into the space. @AndrewStone can correct me if he disagrees, but I see it as an entirely new blockchain, one with real value, that is also friendly with BCH (i.e., if the BCH community sees value in the features delivered to this project, then this project will help to port them to BCH). If BCH is the platform that ultimately completes the financial revolution, then I will be quite satisfied. And if this new project contributes some subset of those features, then I will be proud to have participated.


If you want to formally request BU do something, a BUIP is the process through which to do it. Because BUIPs can only be submitted by BU members, you should

  1. Write a BUIP for the action you desired to be taken.
  2. Find a member to sponsor your BUIP.
  3. Submit the BUIP by starting a new thread on this forum with the idea and include which member is sponsoring the idea.

I am not interested in participating in devs labyrinths (Neither in BU nor in BCHN).

I lead a team of 13 programmers as CTO in a multi-national company.
I have no more free time for this.

I think I have contributed enough with 3000 lines of code.

Please, solve the BU bureaucracy yourself.

1 Like

Hi all,

just want to put out my 2 cents on this BUIP.

Like I said else where (mainly on reddit) I think this BUIP won’t cause the havoc that has been forecasted in this thread and that I’m going to vote in favour of BUIP 166.

I’m saying this with my “BCH/electronic cash system” developer hat on. Let me explain what my reasoning is.

This proposal is not an hostile split, it is not a chain/utxo fork, BU will continue to develop BCH and lastly the PoW will be different. I really think that there’s a significant probability that every one will gain from this, surely BCH in case a feature is going to be deemed good enough to be back ported to it.

Lastly I just want to add a question related to this tweet by @imaginary_username


I suppose you are referring to this BUIP in this tweet of yours.

I would like to know how voting for this BUIP 166 is going to “reset BCH back into the land of doubt and chaos”? Thanks in advance.


As said, BU is for all intents and purposes a BCH organization. Launching a competitor from it, no matter how much you twist it, peels off the network effect - whether that peel is significant solely depends on how much people care about BU in the aftermath. It also immediately invites doubt, chaos, and comparison to BCH’s repeated almost-yearly fuckups, each has champions swearing up and down how “our split is different from the last one because of X”.

Again it doesn’t matter what you or I think, it only matters what the coin-buying and coin-using public thinks. You guys really need to get out there and take a long hard look at the real world sometimes.


I’ll put down my own final thoughts about this BUIP.

Frankly I’m surprised at the amount of push back on it. If it’s unlikely that this new coin will gain much traction or become of great value then I don’t get why the big deal about it. Surely it’s not because of this argument about the funds being BCH’s funds (which is obviously not true, they are BU’s funds). No, I suspect the real and un-talked about issue is that in the back of their minds some are afraid that it “may/will” become a big deal and that’s going to effect them in some way. So, in a nutshell, it seems to me that some people don’t want the new tech being proposed but they don’t want anybody else to have it either, which seems a bit antithetical to crypto.

In my mind, the idea of NextChain is simply a place for rapid development (hence Andrew’s extra discretion about merges) but also to spur the uptake of new dev into BCH once it’s proven in the real world. BCH typically
takes the good parts of tech developed elsewhere, Schnoor is a good
example. So It doesn’t make sense that they wouldn’t take something good if it’s proven on NextChain to have value. NextChain will do two things, keep our devs interested (and very importantly keep them around which is a consideration often overlooked) while at the same time allow for new and interesting ideas to emerge in the real world. Unleashing the creativity of our devs can only help BU do it’s part to bring crypto to the world and perhaps in ways you could never have imagined!

So I’ll say it again, I’m 100% in favor of this BUIP.

1 Like

I see.

Well then I guess we can agree to disagree on that one.

You think that “coin-buying and coin-using public” will see it as a bad think, whereas I don’t share the same grim outlook.

edit: with “it” in the above I meant BUIP166, that again It is not a split.

Now that the issue has exploded among the BCH community, the feedback has been almost universally negative.

Again, you guys really need to get out there and take a look at the real world sometimes. You can’t argue your way out of reality.

1 Like

It possible, even common, for a community to be wrong about something.

Since 2017, we (the BU devs and officers) have a history of being right, and unfortunately this larger community has been in general wrong. We predicted the failure of ABC and price descent of BCH and decided to wait it out.

But of course there could be a conflict of interest here. I could be right for myself and wrong for you. So ask yourself “what do we gain?” Where is the premine or founders’ tax on this coin? Answer: it doesn’t exist.

I stand to gain nothing from this proposal, and am risking community ire.

So why the fuck? You have to be asking yourself that. Because we believe that its the only way forward to success. Not to a zombie coin that leaks value like 2017 to 2020, but to success. BCH price and adoption is painful. Kim dotcom marketing has literally been the only pop.

Meanwhile technically agile coins are eating our lunch in the marketplace, and delivering services on top of their infrastructure that is grabbing users. Look a what’s going on out there!

We CAN be both technically agile and stable with this hybrid approach.

I know of two other persons who have a habit of claiming themselves as “having a history of being right”. I will humbly recommend that you do not put yourself even deeper into their company.

Don’t fall into that same logical fallacy I pointed out above that previously you jumped right into (if A implied B, and A is similar to C in any arbitrary way then C must imply D).

I have quantitative proof of being right which is the BU funding. Both CSW and Amaury split to be grubbing for money. They are looters in the Ayn Rand sense.

I have no personal motivation to spawning this chain (other than actually trying out the features BU has developed), and there’s no provisions in it that benefit me. In fact, it’ll be a lot more work.

Yes, I’ve heard that before as well. Each time the reason changes as to why this attempt is virtuous and the previous ones are done by charlatans. The last one had objective track records that he could write code, and was therefore different from his predecessor.

I don’t know who you are talking about but the intention of both CSW and Amaury to loot the coin was clear in the outset. CSW talked about writing code to take Satoshi’s coins and in Amaury’s fork the ONLY change was to award him money.

So no, you’ve demonstrably NOT heard this before.

1 Like

Discussion about this BUIP has included this, which I wasn’t previously aware of (thanks Zarathustra) .

What is Kusama?
Kusama is a scalable network of specialized blockchains built using Substrate and nearly the same codebase as Polkadot. The network is an experimental development environment for teams who want to move fast and innovate on Kusama, or prepare for deployment on Polkadot.
Kusama was founded in 2019 by Gavin Wood, founder of Polkadot and co-founder and former CTO of Ethereum.

Kusama, Polkadot’s Canary Network

Kusama is a scalable multi-chain network for radical innovation and early stage Polkadot deployments. Expect Chaos. No promises.

kusama.network kusama.network

Polkadot/Kusama is arguably out innovating us, with Polkadot growing from nothing to #9 in market cap while BCH moved from #3 to #13.

1 Like