BUIP 166: Launch a Chain for Proving Next Generation Features

[AndrewStone]

Abstract

This proposal calls for the creation of a new blockchain, initially supported by Bitcoin Unlimited with its direction determined by its membership. The principal goal of the new blockchain is to Prove Features, i.e. demonstrating new functionality on a real-world blockchain with some unit coin monetary value. These additional software features will be theoretically deployable in Bitcoin Cash, however, because of the conservatism required in rollout on BCH (now worth $20 billion) there is a major benefit in first seeing major changes piloted separately. BU support for BCH and its regular upgrades remains unchanged. A modest budget is required for launch and maintenance of the new blockchain with its principal characteristics outlined.

Background

Every cryptocurrency must choose a path that embodies its fundamental philosophy. Often this path navigates a compromise between conflicting requirements, and this philosophy may deviate between the cryptocurrency as a whole, and individual or group participants. In particular, I have always believed that to be competitive against the first mover advantage of Bitcoin and against the versatility of Ethereum, the blockchain architecture Satoshi left us requires a phase of dramatic innovation followed by continuous improvement. This philosophy causes greater risk and uses blockchain space differently, and so is inherently in conflict with Bitcoin Cash’s vision of a stable, massively scalable, universal currency.

Over the last few years the Bitcoin Unlimited members have emphatically agreed with and supported a focus on innovative research. I am not aware of a single BUIP that was defeated on the grounds of being “too innovative”. The result of this is a series of technologies, many of them requiring consensus changes, that are both envisioned and completed. For example, some of these technologies are deployed on the “NextChain” testnet located at (www.nextchain.cash).

Motivation

However, it should be completely obvious to all that there is minimal to zero use of and interest in testnet features that have no roadmap to deployment. Investing the time and effort to deliver even a simple “minimum-viable-product” based on these technologies will not happen. The most obvious barrier to such an effort is finding the venture capitalist willing to risk such an uncertain deployment. But the second is probably more important: displaying such a product on a testnet simply invites competition that can be fully ready by the time the required consensus changes are deployed in BCH. This defeats the first mover advantage that is essential to the success of most startups.

Without such products it is impossible to effectively communicate the value of consensus changes to the general public, and it is impossible to achieve the levels of use (and black-hat interest) that give individuals confidence in the underlying implementation. And even for those who can understand the proposed change at a technical level, any assessment of value is simply guessing at the future. So technology assessment remains a “crystal-ball gazing exercise” – some people will see value and some will not. In fact, some of the features will have value and some will end up as useless “cruft” complicating the blockchain. It’s very difficult if not impossible to determine a priori which category a particular feature will fall into.

Proposal

Therefore, I propose that Bitcoin Unlimited create its own blockchain containing these features and allow it to gain whatever value the market gives it. This blockchain will NOT be a fork of Bitcoin Cash and it will follow a very different philosophy of dramatic innovation. To begin with, we will use a “white ball” approach to feature inclusion – if I, Andrew Stone, approve a feature, or you, the voters, pass a BUIP enabling a feature, then said feature will go in (subject to the normal BUIP rules of providing an implementation, undergoing code review and security analysis, etc). So this blockchain will fill a different niche than Bitcoin Cash.

Despite being forward-looking, this new blockchain will maintain the same high standards expected of Bitcoin Unlimited. In particular, we will continue to take great care in implementation with regards to security and usability. But since the underlying token has value, it will allow startups to build products and services with the certainty of deployment on a blockchain with value. This will allow these companies to gain revenue, users, and the first-mover advantage before a possible transition to the more-broadly-adopted BCH blockchain. And this will allow the BCH blockchain to prove the value of a feature before making consensus changes.

Some of the initial deployment features will likely be:

1. A different POW algorithm (to prevent the chain from competing for ASIC capacity with BCH)
2. Smart contracting features: transaction introspection, OP_EXEC, OP_TEMPLATE (see the nextchain work around these) etc.
3. Tokens
4. A different block header
5. A different UTXO database structure which will allow UTXO commitments
6. Sound money
7. Fair launch – no premined coins go to Bitcoin Unlimited, the blockchain’s creator, or its developers, and there will be no coinbase tax.
8. 2 minute average block interval

Specifically, this BUIP authorizes Bitcoin Unlimited to “officially” create, develop, and support such a blockchain, with the genesis block happening within a year, with a minimum of a 1 month advance notice.

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.

Budget

Furthermore, this BUIP allocates 10000 USD annually to acquire and deploy hardware associated with this new blockchain – full nodes, explorers, web properties, and mining nodes. This money shall be provided solely from BTC donated prior to the creation of BCH. No funds donated after the creation of BCH and by implication no BCH will be spent on this new cryptocurrency.

This BUIP further creates a consulting position within BU with the task of sheparding new features through the CHIP process and into BCH, and allocates 30000 USD annually towards the payment of this individual’s time. The goal of this position is to engage with key BCH stakeholders to increase the likelihood of BU developed features becoming part of the BCH protocol.

Any additional funds requested for additional activities around this blockchain will require a separate BUIP, following normal Bitcoin Unlimited processes.

Precedent

Since the introduction of this BUIP, individuals have brought to my attention other coins that appear to benefit from similar system of a fast-moving experimental chain and a more stable high value chain. Here is a (possibly incomplete) list:

Polkadot and Kusama

From Kusama’s description:

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.

Polkadot has a serendipitous interaction with us in that it was announced and presented in the same BU Arnhem Conference as Bitcoin Cash. In the interim, Polkadot has moved from a nascent (0 value) coin to exceeding Bitcoin Cash in market cap (according to coinmarketcap.com) and doubling Bitcoin Cash in exchange volume (according to cryptowat.ch). At the same time, Bitcoin Cash has dropped in market cap rankings from #3 to #13, and its price has dropped from a trading range of .2 to .1 BTC (I am including a range to be conservative – to ignore the new coin “pop”) to a recent trading range of .0088 to .018 BTC.

Bitcoin and Groestlcoin

Groestlcoin has preceded the delivery of Bitcoin features throughout its history. It deployed segwit first, and and it launched Taproot first on its testnet. It uses a different POW algorithm and a 1 minute block time, which is a mirror of my choices. If you’ve developed in crypto, you’ll have realized that a shorter block time is great for experimental services since it reduces the time a developer needs to wait around. Sure there is regtest and testnets where blocks can be produced faster, but at some time you still need to move to something with real money and it is essential to watch those initial transactions to make sure they are correct. This happens not once, but every time a new release or bug fix goes live on a value-carrying network.

https://www.reddit.com/r/groestlcoin/comments/kics9f/groestlcoin_dec_2020_release/

Bitcoin and Litecoin

Any long time BCHer should know very well how Litecoin was used competitively against BCH as the Bitcoiner’s temporary answer to scalability. “Just use LTC for your daily use now and BTC will deliver lightning soon.” Although unquantifiable, I feel that this argument was extremely damaging to BCH since our story centered on scalability. Why is this relevant to this BUIP? Because we can use a similar argument for various forward looking features such as miner validated tokens and smart contracts: “deploy on this new chain now, while waiting for BCH to complete its integration”.

[ptschip]

I fully endorse this approach. It’ll be great to battle test these new features which can then be ported into BCH if they’re deemed worthwhile. And I think it would just be plain fun to get back to CPU mining with a new POW algo.

[Singularity]

I also endorse this BUIP. I believe BCH seems to have solidified around a conservative approach to development, and I personally believe this has occurred too early before the network has enough features to compete against other cryptocurrencies and fiat.

My hope is that with the BUIP, BU will be able to efficiently apply resources to accelerate innovative blockchain technologies. This may in-turn allow BCH to adopt these technologies after they are production-proven on this new cryptocurrency.

Because this is not a split, or a hardfork, this should not cause any negative consequences for BCH. The end result should simply be one extra chance at peer-to-peer electronic cash. It is my personal belief that a more permissive approach to new network features is needed to overcome the existing financial system, and this BUIP aligns with this belief.

[AdrianX]

@AndrewStone

– if I, Andrew Stone, OR you the voters pass a BUIP,

This BUIP appears to be proposed by Andrew Stone, the “you” in this BUIP is understood, but that could read diffidently leaving the question who is the reference “I” if “I, Andres Stone or you” implies there could be 3 people, the author in that sentence, could be Andrew, or it could be someone else, @AndrewStone could you qualify?

Also if this cryptocurrency was to have a monetary value it would also need a governing structure that would outlast the division makers.

What would the governing structure look like if the leed developers were to give up on the project leave or pass in time?

[griffith]

@AdrianX is right.

The use of commas to delimit nonessential information is not correctly applied and can lead to confusion due to the proximity with the “or”. There are only 2 people mentioned. The “I” refers to himself and the “You” refers to the reader. The specifier “Andrew Stone” is comma delimited nonessential information used to provide information about who “I” refers to. The commas are needed around the information that elaborates on “You” as well. Without them it is unclear that the use of commas in that sentence indicates additional information rather than separating items in a list. The sentence should be corrected to:

“if I, Andrew Stone, OR you, the voters, pass a BUIP,”

[AndrewStone]

Yes, @griffith’s interpretation is what I meant. I don’t seem to be able to edit the original post BUIP like I could in the other forum, so we will have to apply griffith’s change when we move the text to github.

@AdrianX, since BU is part of the governing structure, it will outlast “the decision makers”, because BU can admit new members. The purpose of this clause is primarily as stated (white-ball decision making) and secondarily in case either BU or I leave the project, decision making can move to the other party.

If some day in the future BU wanted to delegate its authority to a separate governing body, it could also do that by BUIP of course.

Note that the code is also FOSS so any dev group can pick it up.

So I think that this is actually a pretty robust structure that is very succinctly described because it leverages what already exists in BU.

[jQrgen]

This looks like a very exciting proposal!

I endorse it.

[imaginary_username]

This is an extremely misguided and cynical attempt at plundering BU coffers to launch a self-dealing alternative currency that will inevitably cause serious conflicts of interest. I’ll like to call into question the soundness of keeping the involved officers on BU’s payroll - they are free to explore whatever endeavor they like in their free time, but disguising this direct attack at BCH’s network effect as something “friendly” that deserves funding is disingenuous.

If BU ends up funding this, it’ll lose all credibility and become a joke to what’s left of its supporters. As a longtime BU supporter who wants to see it succeed as an organization, I urge the membership to reject this and censure the officers who are involved in attempting it.

[solex]

It is disappointing to read a response to the BUIP which does not engage with the proposal, but instead launches unwarranted accusations and ad hominem against the officers of the BU organisation.
Hitherto, @imaginary_username, I valued your commentary on many matters, but this is a major departure from the standard of considered thinking you have shown until now.

It is good to know that you want to see BU succeed as an organisation, but what kind of success is it when this is the only development proposal raised by the BU membership this year? BU is structured to give democratic (microcosm) community feedback to Bitcoin development ideas, but it is sitting in neutral, when ideas are not forthcoming. It also sits in first gear when development ideas have been proposed in the past, documented, funded and implemented on the BU testnets, but functionality still does not reach the BCH mainnet.

Recall that @AndrewStone designed and coded OP_Group by March 2018, over three years ago. It was stalled primarily by Sechet instead of engaged with in a constructive, collaborative manner. If that had happened, BCH would have supported some form of miner-validated tokens from 2018. It would have been in pole position to seize a good chunk of the NFT market which has since exploded into global prominence, massively boosting Ethereum. In my view, the BCH price should be double what it is today. Instead, ETH is riding high and may grab #1 rank in the next year or two.

I conduct the voting sessions in an impartial manner, and count as just one vote on any org proposal including BUIP166. I will give my view since it is clear that this BUIP triggers some emotional response.

This proposal deserves a considered level-headed evaluation in the wider context of BCH striving to advance against many other coins. To be clear, the wide context is that BU has vigorously supported onchain scaling for well over five years. It has supported and advanced BCH since before it was launched. BU funded the conference where BCH was announced and has spent many hundreds of thousands of dollars on BCH development ever since. Just take a look through the BU twitter feed. See what has it said consistently since day one.

The proposal for a value-chain which can prototype new functional developments in a real-world environment has real potential to help BCH. Consider the opposite case, of LTC and BTC. LTC leeches off BTC copying its code and relying on an effective 4x block capacity to grab some market-share. It is the same model Sechet saw for BCH when he never once pulled code from BU, but instead kept cloning Core Dev changes in BTC. What BUIP166 proposes is a lesser-chain which can pilot BCH-compatible functional changes and then BCH can cherry-pick functionality which is proven to have potential. This reduces the perceived and real risk in doing significant changes in the 6-monthly upgrades.

Finally, I ask for a retraction @imaginary_username. This proposal has a limited budget which will have a negligible effect on BU funds. The term “self-dealing” is disgusting as the proposed chain will be from genesis block (did Satoshi self-deal when he launched the genesis block??) . Everyone has equal chance it use it or ignore it. BU does not have a payroll, it has consultants funded only by member-approved projects.

I ask that all commenters should focus on the proposal. From what I can see it has potential to revitalise the BU org, harnessing its community decision-making , and producing a slew of battle-tested prototype functionality from which BCH can take advantage.

[scherrey]

First off - I’m quite likely aligned with the desire to innovate with BCH and ensure it keeps ahead of the “competition” in bringing about the cryptoledger revolution. Since you don’t state a time horizon I can’t really evaluate whether or not the philosophy espoused “is inherently in conflict with Bitcoin Cash’s vision of a stable, massively scalable, universal currency.” I don’t think it has to be at all if done the right way.

@AndrewStone

However, it should be completely obvious to all that there is minimal to zero use of and interest in testnet features that have no roadmap to deployment.

@AndrewStone

we will use a “white ball” approach to feature inclusion – 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).

Agreed - but the solution you espouse seems destined to fall into this same trap because new “radical” features implemented haphazardly stand little chance of getting merged in even if highly desirable because they will quickly become too divergent from the protocol implementations of BCH to be able to be incorporated “upstream”. I don’t see how this can be avoided without going through the consensus process of any other BCH change in the first place which then begs the question as to the value of this otherwise independent chain from the perspective of BCH.

I absolutely share your frustration with having ideas that should be extremely valuable to BCH but the efforts to get them in seem monumental and glacial. But I think this is a) not quite as bad as you think, b) is caused by an entirely different reason than you might suspect, c) partially addressed by “Multiple OP_RETURN”, and d) has already shown improvements within just the last year.

Point B is that our ecosystem is incredibly painful to update. VERY little attention is given to the non-functional requirements of maintaining, operating, and forward upgrading the key systems that make up BCH protocol implementations and ancillary services. Therefore upgrades to the protocol that seem REALLY simple from a development perspective (I give you ‘Multiple OP_RETURN’ as an example - under a dozen lines of extremely straightforward code) have a vastly larger impact on the people whose living depend on running the stuff afterwards. We really have a poor standard of software engineering practices that account for this reality the the rest of the software industry has been addressing and without FIRST addressing this problem, bounding off with an alternative chain in hopes that it will rapidly implement gobs of new fantastic features is only guaranteed to exacerbate the problem. If we solve the challenges of in place upgrades to core infrastructure so that updates are a snap then innovation could move much faster. Frankly, it won’t be until we do. As it is we’ve already had to back off of twice annual upgrades that impact consensus. That’s a red flag that we should not ignore. With better practices, even quarterly updates is achievable in my mind (although I suspect many reading this would think it scary and irresponsible but that’s just cause they’ve never seen it done).

Point C is that I proposed the ‘Multiple OP_RETURN’ CHIP explicitly to support the ability for us devs to experiment with new protocol feature improvements on the real BCH chain without impacting anyone else in the ecosystem that wasn’t using these new features. SLP is a great example. A TestNet, in my view, is not for deploying proof of concept systems - it is for confirming operational compliance and interoperability with the rest of the ecosystem immediately prior to a new update being deployed and included into the MainNet environment. RegTest is for playing around with prototype implementations and proof of concepts in an isolated manner (thus preserving your “trade secrets” if you so choose). That’s why my team created BCH-Toolkit (which we implemented first with Bitcoin Unlimited’s Node) to do just that and help introduce good software engineering practices and better tooling to the BCH community.

Point D is - thanks to the newly introduced and now bloodied and tested CHIP process, the method for driving an improvement through the ‘standards consensus’ process is far more clear and helps ensures ALL stakeholders are aware of the proposal and have their input considered before too much time is wasted implementing experimental solutions that ultimately have zero chance of ever getting into BCH due to a massive unexpected conflict with critical stakeholders.

If your proposed blockchain doesn’t solve these problems then it is doomed to fail. And I see no reason why the effort to solve them for your new chain is any different than just doing it for BCH straight away.

I think a proposal such as this (assuming we’re all ultimately working towards the ultimate betterment of BCH and it’s core mission of being the best peer-to-peer electronic currency in the solar system) needs to be judged primarily on its merits as to the likelihood of it having such a beneficial impact. So let’s judge this by taking a look at your list of initial proposed deployment features:

@AndrewStone

• A different POW algorithm (to prevent the chain from competing for ASIC capacity with BCH)
• Smart contracting features: transaction introspection, OP_EXEC, OP_TEMPLATE (see the nextchain work around these) etc.
• Tokens
• A different block header
• A different UTXO database structure which will allow UTXO commitments
• Sound money
• Fair launch – no premined coins go to Bitcoin Unlimited, the blockchain’s creator, or its developers, and there will be no coinbase tax.
• 2 minute average block interval

1. a different POW seems just a complete introduction of a bunch of unnecessary complexity so you can “safely” do something independent of BCH in a manner so as not to compete with BCH miners. This is a requirement created solely to the nature of your proposal and adds no value to BCH.

2. smart contract features - this is actively being worked on now and seems to be getting some good traction already.

3. token - this is actively being worked on now and seems to be getting some good tractions.

4. Different block header - too vague and no value stated for me to be able to comment but hard to believe any derived value rises to the level of creating an entirely new blockchain.

5. Different UXTO structure - same as 4.

6. Sound money - got that now. A bloody damn difficult thing to accomplish and incredibly unlikely any chain established with the primary goal as guiding innovation for another chain (BCH) could ever achieve it. Damn near impossible.

7. Fair launch - ok fine but doesn’t do anything to benefit BCH.

8. 2 minute block interval - really doing a lot of mental work to see how this was even considered as something intended to improve BCH at any point in time. Smells like something you’d do instead of using BCH, no?

So - all the things that appear to have potential value for BCH are already today right now this minute actively being worked on with the live BCH chain. Furthermore - a KEY value of the BCH ecosystem is the diversity of protocol implementations we have. It was really sad to see the Bitcoin ABC node drop away. I fear such a new chain will distract and further dilute this unique attribute of the BCH ecosystem. We need all these disparate implementations of key systems to keep BCH properly decentralized and its development mindshare increasing rather than evaporating. How does your proposal not increase this problem?

Given the proposals being worked on with BCH now, I can only guess that your time horizon is MUCH faster than May 2022. And, in that respect, I absolutely sympathize with you and would like to see that brought in sooner as well if it could be. But we are where we are today and it doesn’t appear that what you’ve proposed has any chance of improving on that. What do you propose people on your chain do who are using these features (almost 100% guaranteed to be implemented in a manner incompatible with what BCH will ultimate reach consensus on because yours will be deployed before BCH’s is fully spec’d) when the equivalent features become available on BCH? They should abandon yours and figure out some expensive migration path? It just doesn’t add up as anything but a (quite understandable) cry of frustration for having to wait for the killer features we all want to demonstrate the superiority of BCH.

So let me offer an alternative way of addressing this that DOES align with the goals of BCH. Let’s just first agree that BCH IS the ultimate stable currency that everyone needs to be the market value measuring stick and medium of exchange for the revolution of the crypto world to build upon. If we agree on this then we can proceed. If not then we’re really not aligned in our respective interests.

Assuming the above - let’s reconsider what absolutely needs to be in the BCH protocol and what the BCH protocol needs to interface with in order to achieve its destiny. To keep BCH focused and true to its mission, there are simply some levels of complexity that will never belong on the chain. Those things likely belong on something that is independent of BCH but stores its state on BCH. It can use an alternative consensus mechanism yet take advantage of BCH’s POW for transaction finality and safety - or it can be completely dependent on BCH POW. An independent computation engine that can innovate like crazy but uses BCH to store the financial results of its computations gets the best of both worlds. This is fairly similar to what SmartBCH is proposing but the trick is, of course, how to transfer value across the two chains in a trustless and low latency manner. They don’t yet seem to have a viable solution (using those standards) and ultimately such a solution likely requires a few op_code changes to BCH to make it capable of interoperating with another chain in such a manner.

The nice thing is - once such a capability exists, there could be any number of independent compute engines for BCH to interoperate with. Here’s where devs can compete in the free market of ideas and innovation all whilst supporting and benefiting from BCH and what it brings to the table today. I THINK something along these lines supports your stated goals better than your current proposal. Let me know what I got wrong…

[imaginary_username]

I’m not sure why Bitcoin Unlimited has to “sit in neutral” when there are a number of unique, uncontroversial technologies that nobody else is in a good position to bring to fruition and adoption. STORM, Graphene and database improvement (BUIP120?) have so far been either sitting on BU testnet (STORM), done but not pushed to wider ecosystem (graphene; note that BCHN adopted BU’s xversion as a first step to interoperate) or simply left alone (database) - where is the drive to actually make them a part of BCH?

These are all BUIPs that people were once excited about. They are still “BU’s projects” in people’s minds, and will remain so as long as they’re not a common feature of BCH. BU is very far from having nothing to do and have to launch a coin to justify its existence.

And indeed, it seems like the officers on top are trying to do that - if I give them benefit of doubt - in the most misguided way possible. There are lots of PoW coins launched from scratch that ended up being self-dealing, this has no fundamental reason to be any different, especially when it attempts to launch from the “treasury” of an alleged BCH organization. I will not retract, and will instead like to extend to @solex my call to censure.

[AndrewStone]

@imaginary_username Your accusations are garbage and unsupported. The real historical record describes the exact opposite. For years, the BU officers have supported BCH even when the community was actively attempting to push Bitcoin Unlimited away from this blockchain and disparaging us within the community. This occurred by many people, but notably by both nChain and ABC. That is, we have consistently refused to fork while the other development leaders, who were so free with their “no true scotsman!” accusations ultimately forked for selfish, self-aggrandizing purposes, and in a manner that created maximum damage.

Since your comment went straight ad-hominem I will reply in kind. Your comment is exactly the kind of poison that ABC employed to great effect to fracture the chain, funnel all innovation through itself, and maintain power over an ever-smaller pie. You have learned too well from your teacher. And you need to check your own track record. You were part of the group that steered BCH from over 10% BTC’s price and #3 crypto to <1% BTC’s and out of the top 10. Maybe you need to stop talking so much and start listening.

My track record is that of proposing technologies like transaction introspection and native tokens, which I did years ago. These technologies are being adopted industry-wide and are proving to be extremely important in the ecosystem. We could have had a 3 year head start and have been a viable competitor to ETH today. I also correctly predicted exploits of and argued against bad ideas like the DAA, the uselessness of CTOR, and finalization and parking that may have occurred recently on BCHA.

This chain will open a growth corridor for any endeavor/startup. It will create a narrative that could be bought by investors. That narrative is “we start to grow on NextChain, and transition to the much larger BCH market when the technology is proven and deployed”. This is a very powerful story. Here’s a narrative that doesn’t work for shit: “we’ll build technology that can’t be used on any blockchain and hope that BCH hard forks to it”. The nice answer VCs are thinking is: “why not use ETH or some other chain that supports your technology”, but the real answer VCs will give is “bye” (you are a BCH idealist that I wouldn’t trust with an investment).

The only way what you imagine can happen is if BCH persistently refuses to deploy technologies that are proving successful for YEARS allowing the market cap of a zero coin to exceed it. I cannot predict BCH but first off I think that that’s extremely unlikely. And second, if it would happen that way, then BCH is in such trouble this coin would not be relevant – there are plenty of other competitors.

I am sorry to speak harshly, but you seriously need to reevaluate the last few years and do things differently.

[AndrewStone]

@scherrey Thank you for this very considered reply. I will try to reply to each part. Please point out anything that I may miss:

Agreed - but the solution you espouse seems destined to fall into this same trap because new “radical” features implemented haphazardly stand little chance of getting merged in even if highly desirable because they will quickly become too divergent from the protocol implementations of BCH to be able to be incorporated “upstream”.

I disagree. Many features will in general be completely unrelated in topic and be physically separate in code. It will be simple enough to take a new opcode (for example), without taking a different POW algorithm. Additional sighash flags don’t affect opcodes. Opcodes also don’t interact. Sure having opcodes A and B may allow a script to implement some functionality that can’t be done without both. But if BCH has a need for opcode A alone then pulling it over without B would be extremely straightforward. Surely this can’t be a matter of debate: BU, ABC and then BCHN all have a history of pulling features in isolation from Core and Flowee and eachother without much trouble.

Point B

Your observations support my goal. No chalk-talk or POC demonstration can get the ecosystem to move forward. We need a working, successful example to justify it to BCH. And the startup backing the change wants to move it to BCH to take advantage of a much larger market.

I hope we aren’t still coin maximalists – there can be only 1 coin – are we? I mean look at the ecosystem! That philosophy is debunked. So you only have 2 choices: 1. Deployment on a chain that is unfriendly to BCH and uses such different tech that porting means complete reimplementation. 2. Deployment on this chain I’m proposing.

Point C

SLP is a poster child of the problem. Look at what’s happened to it over the last few years. Nothing. But Tokens and NFTs are driving massive growth on other chains. What happened?

Point D

I do not think that the CHIP process is clearly defined. Some parts are. But the part where a proposal gets accepted is not AFAIK. And I’m one of the earliest engagements. But more importantly, the process requires consensus which is a much higher bar than this new chain’s bar which is by BUIP (or majority). This will allow experimental feature to be deployed more readily.

If your proposed blockchain doesn’t solve these problems then it is doomed to fail.

I think that it does solve the problems you’ve mentioned as I described above. But what does “failure” even mean to you in the context of this chain? I see many avenues of success here with a small low-value coin: giving features a shake out with real money, giving startups a place to grow, BCH adopting features, and finally it could actually succeed on its own merits if BCH does not adopt the features.

assuming we’re all ultimately working towards the ultimate betterment of BCH and it’s core mission of being the best peer-to-peer electronic currency in the solar system

Everybody has a different idea of what that means so we effectively are not all working together as you suggest. This is why it is necessary to prove the real value of proposals.

OK on to the features:

1

Not solely. There is a persistent concern of a POW attack since doing so from a large BTC miner would be trivial. This has occurred in BCHA for ideological reasons and on other cryptos for economic reasons. It would be very valuable to have something ready just in case the community needs to react to a persistent reorganization attack.

2

I originally proposed transaction introspection in 2018, and have repeatedly brought it up over the years, and have some simple code on NextChain which nobody has looked at. The transaction introspection working group has not had substantive comments since march.

Also, I don’t love some aspects of its direction, although I think that anything is better than nothing. I have mentioned some of my issues in the working group but the “community” seems to be wanting to go another way. The only way forward is to really demonstrate what I’m trying to say.

3

Tokens have been dramatically cut in scope and features. I would like to show what can be done with the more advanced functionality.

4 & 5

This is the heart of the problem. I (and by “I” I mean any company/startup/developer) should not need to convince you or any other individual (and you should not need to convince me) to try something. Of course we can’t put any garbage in. So this chain tries to compromise by allowing BUIP vote, which is essentially a majority. But this stands in contrast with the more conservative BCH “consensus” which requires that essentially everyone be convinced.

6 & 7

Well these are just the basic ingredients of a chain that might carry value.

8

Actually its been suggested for BCH several times (of course the reward would be reduced to even things out). The naysayers say 2 minutes is still too long for the checkout line so why bother. But the advocates say its useful for things like the coffeehouse exchange, where 10 minutes becomes extremely painful if you get unlucky and the 10 minutes turns into 1 hour.

Ok back to your general comments:

all the things that appear to have potential value for BCH are already today right now this minute actively being worked on with the live BCH chain

I have been working within these groups. In each situation that I’m involved in, the trend is to deploy the minimum feature set to meet certain known issues. For large numbers, the need is to handle satoshi amounts in scripts, so 64 bits is gaining traction. For group tokens, the need is to make SLP miner validated. For introspection there are bunch of items that smart contract writers have run into. What this new chain will do is different. It will imagine “within such and such a space, what is the MOST that can reasonably be done”. As such it will be very different in philosophy and the things we discover using it could drive valuable new features into BCH (and allow us to avoid the ones that turn out to not be valuable).

But we are where we are today and it doesn’t appear that what you’ve proposed has any chance of improving on that.

The above features were not intended to be a complete set. You should not vote for or against this proposal based on a couple of features… this blockchain could be the proving grounds for any new feature that BU chooses to work on in the future.

And many things are already implemented.

What do you propose people on your chain do who are using these features (almost 100% guaranteed to be implemented in a manner incompatible with what BCH will ultimate reach consensus on because yours will be deployed before BCH’s is fully spec’d) when the equivalent features become available on BCH? They should abandon yours and figure out some expensive migration path?

“One coin to rule them all” is dead. I propose that they implement the feature in their multi-currency wallets on BCH and grab BCH’s much larger client base.

What doesn’t “add up”, is the expectation that companies will develop on BCH but be unable to deploy until and unless some feature is added. The last 3 years of ignoring SLP in favor of other token solutions has proven this. Instead they will simply deploy on a different blockchain and have nothing to do with BCH.

An independent computation engine that can innovate like crazy but uses BCH to store the financial results…

People have been talking about this for years. Sidechains, etc. I proposed something in the 2017 Arnhem BU conference called FSHblocks that could seamlessly transition from a federated sidechain into a hard forked main-chain without changing a line of code.

No one has managed to trustlessly move value back and forth, so let’s not engage in fantasy or make decisions on hot air.

Also, if anyone had the technology you propose the obvious targets would be BTC and ETH for the anchor chain, since such a thing could also clearly be made to scale, and those coins carry much larger markets.

I hope that you will carefully evaluate what I’m saying and realize that this chain simply cannot be competitive with BCH – either BCH will adopt the same or similar features, and be much more successful based on its existing community and deployment – the same powerful first mover advantage that has kept BTC #1, OR BCH will choose not to deploy the features in which case the coins will fill different ecosystems. Sure in the latter case the chain may become successful within its niche, but there could be great value in having a friendly chain in a niche that BCH is not interested in pursuing.

[imaginary_username]

Debates about history pales in comparison with the actual act that you are committing right now with this proposal, pulling in irrelevant grievances from elsewhere does not help. You are appropriating BCH resources to launch an altcoin, full stop, no amount of mental gymnastics is going to change that fact.

[scherrey]

@AndrewStone I’ve read through your reply a few times now but it doesn’t seem that you’ve actually responded materially to any of my concerns beyond simply disagreeing with them and key points you argue against are neither points I’ve made nor positions that I would ever support. So let me first, in the spirit of the Principle of charity ( see wikipedia Principle_of_charity entry), attempt to summarize your position as I understand it from your response then I will restate the concerns that I think have not been addressed.

1. You believe VM op_codes are safe to implement entirely outside the BCH ecosystem in a manner that will allow them to be easily be incorporated back into BCH. (I can make arguments on both sides of this but agree it can be done. Question becomes is the new process for your chain credible in securing this likelihood).

2. You infer that any other changes implemented in your new chain won’t be any more difficult to integrate into BCH than the above op_code example (since you at no point acknowledge this concern is otherwise legitimate in your response).

3. You either don’t think your new chain will suffer any of the issues of non-functional operations, upgradability, and maintenance that every other established crypto project in existence (er… BTC & ETH, et al?) are presently enduring or you disagree that it’s actually an issue for these chains. (I couldn’t tell which from your reply but you clearly dismiss it out of hand as being anything your chain will need to deal with.)

4. You think SLP to be a failure and not a success for BCH labeling it as the “poster child” of “the problem” (not clearly defined but I take that you define “the problem” to mean the slowness of innovation in BCH).

5. You don’t believe that BCH should be:

[quote=“scherrey, post:10, topic:35”]
the ultimate stable currency that everyone needs to be the market value measuring stick and medium of exchange for the revolution of the crypto world to build upon
[/quote].

6. You believe that those who believe point 5 are BCH maxis.

7. You don’t trust or believe the CHIP process is a useful means to accomplish your goals as, at best, it impedes the speed of innovation to a level that dissatisfies you.

8. You don’t think any of the current CHIPs that are in the same direction as the features you would like to implement go nearly far enough fast enough to satisfy you.

9. You believe the concept of trustless cross-cryptoledger low-latency services to be

@AndrewStone

engage[-ing] in fantasy or make decisions on hot air

I suspect that several of the above are not your intent but I can’t come to any other conclusion based on what you’ve said thus far in the matter. So please do correct any misunderstandings of the above.

Let me correct one gross misconception once and for all. I am the opposite of a “insert chain here”-maxi of any sort. My entire history in the crypto world since the 1990’s is supporting the value and progress of all legit (and, frankly, some lesser) crypto. I am on the public record for this position. For example, while I greatly disagree with the direction BTC has taken with the Bitcoin name, I think if they wanna be digital gold then I support their honest efforts to become that. (Their dishonest efforts - not so much. But there clearly have been both.) I also have been a big supporter of Ethereum’s efforts to bring a decentralized computation engine to crypto along with all the rest of the “better ETH than ETH” crowd attempts.

My sole point in raising these specific issues with you is the context of this BUIP: if you want to go off and build your own legit block chain then absolutely “more power to you”, but to do so in the guise of it being “pro-BCH” without any clear obligation or path for it to impart value upon BCH is disengenuous and you have not really even tried to make such an affirmative claim - only that you’re doing things to attempt to reduce or eliminate the inevitable damage it is likely to bring (all while seemingly ignoring or dismissing the very real impact of recent splits or alternative chains from prior BCH supporters). So sure - you can make a claim that your extra efforts limit the damage to BCH but you have said nothing whatsoever that gives credible credence that this effort has any hope of helping BCH. That is an affirmative obligation that I believe needs to be met under the charter of Federation upon which this group claims it operates and you being a key member.

It is my belief that, as described and further reinforced by your response to my questions, your new chain is an existential threat to the goals of Bitcoin Unlimited’s Articles unless you intend to subsume BCH’s role with your new chain - which you implicitly but not explicitly deny. This claim is based on my personal presumption that BU’s primary focus for achieving its goals is via the BCH blockchain and could absolutely be mistaken. I’m relatively new (about one year in) to the awareness of all this.

Now I don’t believe that this is your intent. I just truly believe that it is the inevitable outcome of your proposal unless you a) put some things in place to prevent the issues and b) explicitly provide for means to transfer the value to BCH ultimately. You’ve touched on ‘a’ slightly but, imho, quite inadequately, and have utterly failed to address ‘b’ in your proposal and comments thus far. I don’t see how you can possibly address ‘b’ without working within the existing and evolving CHIP process framework which you seem to reject - thus my conclusions.

Beyond the giant elephant in the room criticism I made in the preceding paragraph, here are other concerns/counter-views that I have:

1. The CHIP process (though still evolving) worked damn well. I am that poster child. My own business project (a novel auction protocol dependent on SLP required multiple OP_RETURNs. It was proposed by others (pre-CHIP) but got kicked out of adoption for last November’s due to the stress of the ABC fork nonsense. I picked it up, not knowing ANY of the key players or even what all the possible stakeholders may be, and shepherd it through the (still evolving) CHIP process and got it done. Without CHIP and the support of those aligned with its goals there’s no way a newbie like me could have gotten that done. It can still be improved but it clearly works. It is a means of consensus that is necessary when a decentralized project needs to coordinate so many moving parts without relying on centralized authority. That’s a freaking hard problem and you haven’t proposed an alternative for your direction that does anything except fly against all known history of such endeavors. You need to define your model more clearly and sell the hell out of it before even considering putting something like this up for a vote.

2. When you ignore the non-functional aspects of operational challenges due to success then you doom yourself to fail. I’ve been doing this for 30+ years and this is the number one cause of failure for otherwise well designed technological solutions. You don’t get to ignore this problem and win - ever.

3. What is it that you wanna do that can’t be first demonstrably experimented with multiple OP_RETURNs and side support services like indexers, etc, to provide its value (ala SLP) before being incorporated into the core protocol (which is happening now with GROUP/PMV3/etc)?

4. You ignored completely my observation about the correct use of a TestNet/Regtest network and good software engineering practices while providing no alternative. Show me something successful in the past that follows your (as-of-yet-undefined) dev process that demonstrates it can be successful process to adopt.

5. For more advanced systems, why can’t you build a prototype on top of SmartBCH to demonstrate feasibility and then migrate it to BCH core once it justifies that value?

6. You completely ignored my question about what users on your chain should do with the applications they’ve built on it when and if the feature gets adopted into BCH. In other words - what happens when, despite all these challenges - you succeed??? Oh oops.

The point here is you’re proposing a HUGE expensive effort that is not clearly defined that abandons all empirically demonstrated models of success for projects of this complexity and have failed to show how BCH can ever benefit from it.

I could go on, frankly, but this should suffice for anyone looking to benefit BCH.

(BTW - I get your frustrations regarding speed of progress. You’ve been at it for a while and don’t feel you have much to show for it. But, I’m here to tell you, it’s getting better and will continue to do so. A new chain under BU auspices will not accelerate this improvement, however. It will impede it.)

[JonathanSilverblood]

My view is that it is relatively easy to work together with others when you want the same thing, but opening up an intentionally more fun sandbox around the corner sounds to me like a setup that will result in people wanting different things, and then having difficulties working together.

I absolutely think we should have testnets, and that new features should be developed side-by-side with the main network, but it should be clear that they are testnets and, in my opinion, it would be best if they most of the time tested the things that is being discussed that didn’t originate from BU, rather than the opposite, where it’s testing mostly BU originated stuff.

[griffith]

@scherrey

You think SLP to be a failure and not a success for BCH labeling it as the “poster child” of “the problem” (not clearly defined but I take that you define “the problem” to mean the slowness of innovation in BCH).

@scherrey

What is it that you wanna do that can’t be first demonstrably experimented with multiple OP_RETURNs and side support services like indexers, etc, to provide its value (ala SLP) before being incorporated into the core protocol (which is happening now with GROUP/PMV3/etc)?

I will comment on this because i share the same views about SLP. SLP is and has been riddled with issues due to lack of miner validation. The SLP UTXO is prone to silent forks between nodes which have been and continue to cause problems for people using SLP for projects. The other huge issue is the inability to be verified in SPV. In general, compared to other token solutions, SLP lacks features and reliability.

Take that with a grain of salt as I am not a big token person.

[imaginary_username]

At the risk or derailing the thread, as someone more involved in SLP than most of this thread’s participants I think I should comment. The biggest problem SLP faced, by far, since its inception has been poorly written and maintained software that has nothing to do with whether they’re miner-validated or not. Lack of features has not been a prominent complaint at any point in its life, instead, the common complaint was that the infrastructure outright didn’t work, or worked extremely poorly.

Given a similar level of quality control and investment, it makes no sense to expect those problems to go away magically upon miner validation. Token-related problems will become BCH-wide crisis instead of staying contained to within the token ecosystem.

Note that I’m not even against miner-validated tokens - I merely wanted to see them simplified to minimize risk and retain maintainability, and was willing to give up my personal dislike for output adjustments to work with it. /u/bitcoincashautist worked hard on a pared down spec that went in the right direction - at least I personally think it was getting somewhere.

But apparently some other folks think it must be exactly their way or the highway, which was frankly quite difficult to swallow, especially in the context of it being used as an excuse to justify this appalling proposal.

[solex]

The big picture here is that BCH is sliding down the crypto market cap rankings and this should be ringing alarm bells in the development community who supports it.

Coingecko 15 Nov 2020

Coingecko 31 May 2021

It is becoming more evident by the day that the 21st century world economy is far too sophisticated to be satisfied with crypto which is simply peer-to-peer cash. That is the foundation, the entry-level which gets a seat at the table. After that, it is Darwinian natural selection in the global financial marketplace where coins use features in the fight to attract new users. Yes, features have to be designed well, implemented safely, work robustly, and deliver a good user experience. Documentation helps, which is why BU has spent tens of thousands of dollars on BUIPs raised by @JonathanSilverblood to try and get documentation done for BCH. Thanks to Software Verde good progress has been made.

@AndrewStone and BU development never insisted on OP_Group being implemented exactly as it was first designed. It was always open to peer review feedback and refinement. This may be a historical example, where BCH has missed the boat, but it is indicative of a wider problem which is that major changes have risk and that perceived risk is slowing down BCH such that competing coins are overtaking it.

Today, there is not simply an issue of debating what functional changes are needed to attract adoption, there is a need to have an open mind to novel approaches. The approach of having a prototype blockchain with market value, which starts from a high degree of compatibility with the existing BCH code-base is radical, but deserving serious attention, not emotional outbursts.

@scherrey

2 minute block interval - really doing a lot of mental work to see how this was even considered as something intended to improve BCH at any point in time.

Users have been asking for shorter block times in r/btc for years.

This is an easy win to help adoption. Of course, shorter times do not add to security, but they do give tangible granularity in the UX where a wait for confirmations is necessary. The Chinese community came to r/btc to argue for it, as shorter block times has long been popular with them. Nothing eventuated and those users do not wait around for ever, they go to ETH or Binance coin or one of many other options.

I doubt anyone launches a newly designed coin with >= 10 minute block times nowadays. The market is not interested in that.

BCH needs to respond to the market. Not tell the market it is wrong.

---

Well, you won’t retract, @imaginary_username , you prefer to double-down on the emotion. I will correct you on the aspect of funding. About 90% of BU’s funds was donated to bring onchain scaling to BTC, long before BCH existed, Nevertheless, BCH is the priority for BU as it is the best scalable Bitcoin.

Personally, it is the only form of Bitcoin I own now. It is called “putting your money where your mouth is”. However, in a febrile “No true Scotsman” environment, I guess that means nothing to those who are led by their emotions.

[scherrey]

@griffith

I will comment on this because i share the same views about SLP. SLP is and has been riddled with issues due to lack of miner validation. The SLP UTXO is prone to silent forks between nodes which have been and continue to cause problems for people using SLP for projects. The other huge issue is the inability to be verified in SPV. In general, compared to other token solutions, SLP lacks features and reliability.

I take it you agree with Andrew and not my point of SLP being a good example. My point is that things build on OP_RETURN are excellent ways of experimenting with new capabilities while working alongside the actual BCH. SLP’s specific issues revolve primarily around (surprise surprise) the non-functional aspects rather than the functional ones. The supporting services are not implemented with a scalable or resilient design in mind.

But my point is that SLP demonstrated viability and use of tokens on BCH and now there are serious CHIPs intended to bring those capabilities in as first-class miner-validated tokens. That’s a WIN for the experimental system and how I would anticipate lots of new features to be able to be tested quickly and easily.