We should create a BCH vision/roadmap document

This document will ensure that everyone is more or less aligned in what we build for BCH. We should mention specific technologies if possible, with the understanding that a demonstrably better technology could replace it. But the onus would be on the new tech to prove its better, and vaporware is not demonstrable :-).

Having this basic agreement will prevent a lot of problems that derailed the first few years in BCH, and stop a lot of wasted effort. We need to move quickly and efficiently now to make up for lost time, not fully investigate many possible ideas and then reject most of them simply because that’s not where we want BCH to go.

Should we even do smart contracts? We should not be debating this topic within the confines of a specific technical proposal to increase the P2SH script size. If we are not even doing smart contracts, the engineers who spent a few months creating a proposal to increase the P2SH script size should not have been wasting their time. This is how engineers leave the ecosystem.

Should we do smart contracts in BCH script, or should we make a completely new language for them such as web assembly. You can see how a tremendous amount of wasted work will happen if we chase down both of these roads, but the end result will be more or less the same from the user’s perspective since they are coding in higher level languages. And if all the engineers had piled onto one or the other, we’d be much further down that path. This is an example of why the roadmap should commit to specific technologies, when possible.

Finally, such a document would give something for people to get excited about, about the “new BCH leadership”, and also communicate that our more democratic process won’t get bogged down with no progress (which is a common criticism of more democratic processes verses the dictator model).

6 Likes

Vision or roadmap documents are awesome for advertisement purposes, especially at the start of a new project as this is essentially your promise for the future. For instance the BCH roadmap included lots of ideas which never got delivered. If you can’t deliver on your roadmap expect funding to stop from those that joined because of that roadmap.

Both a vision document and a roadmap are useful, for very different usages.

So, Wikipedia say this about a vision document:

It communicates the fundamental “why and what” for the project and is a gauge against which all future decisions should be validated.

For instance the Tesla vision statement is (source):

“to create the most compelling car company of the 21st century by driving the world’s transition to electric vehicles.”

Following this idea Flowee has the following one:

Flowee is a family of products that share the aim to accelerate the world towards a Bitcoin Cash economy.

As you can see, I got inspired by the Tesla one. And this is the goal of a vision: it is to inspire. It is to get people to join because they share the beliefs you have.

I also note that this is very short, can survive for a decade or longer and is just the right mix between fluffy and concrete.

As I mentioned, Flowee already has such a vision statement, if other projects have one they may be able to share that here.

1 Like

In my opinion we should have a Vision Document/Statement for BCH but not a roadmap. Individual features should have road maps but not the coin as a whole.

2 Likes

I share this opinion with you.

There is no central authority in Bitcoin only market forces.

This document would be aspirational not authoritative.

I do believe that a document explaining Bitcoin Cash Vision has relevant value in multiple dimensions and helps coordinate related efforts in different areas of the ecosystem, not only in software development.

From what I understand of the original post and subsequent clarifications, this document has no specific intentions to be authoritative. And in the remote event (:crossed_fingers:) that someone attempts to do so, I don’t think the community would face significant challenges expressing out against it.

Although it is true that a Roadmap can be understood from different perspectives based on diverse disciplines, it seems to me that the circumscription of the term to purely computational functionalities is a little to narrow its spectrum and meaning.

I believe that the Roadmap concept has to do with the practical application of a given strategy, the path that will be taken to achieve the Vision, and the times involved with a relative granularity.

This clearly involves a predictive or forecasting character, but from no point of view should be rigid. Yet, it does not mean that it cannot be used as a guide to better understand the idea of progress associated with the project. Furthermore, it can be functional to bring new businesses and users to the ecosystem by demonstrating a certain agreement level among involved parties.

Having a Vision and an associated Roadmap does not give me the impression to imply a central authority necessarily or to turn a deaf ear to the pace imposed by market forces.

Any actor who feels capable enough to come up with a Vision and Roadmap for Bitcoin Cash, and seeks consequent support from the community should be free to do so.

From the point of view of adoption and business development at least, I believe that such a document would be valuable.

1 Like

But that wasn’t the problem. The central authority is the most extreme and yes that is what we want to avoid. But we aim for the opposite, we aim for a permissionless innovation model.

That is a little reverse, though. Bitcoin Cash is not a finished product that is sold to businesses like MSOffice is. The business are not our customers that we have to research and create features for. That is clearly not the business model.

No, Bitcoin Cash is decentralized and practices permissionless innovation. This brings with it a set of promises and a set of obligations. The companies may not yet find a finished product for their unique usecase, but like any open source community, we promise to work with the companies and help them reach their goals. Including protocol upgrades if that is the best way to go.

1 Like

@tom to be honest I don’t yet understand if you favor or not the proposal made by @andrewstone , but I’m glad to know that central authority is not the problem. At some point along the thread it seemed that it could be interpreted another way. Hence my comment and personal opinion.

I see that we come from different backgrounds, and we probably understand business development from different perspectives. Therefore it won’t hurt a simple definition with the intention to find common ground.

I know that you like Wikipedia, so:

Business development entails tasks and processes to develop and implement growth opportunities within and between organizations. It is a subset of the fields of business, commerce, and organizational theory.

And I think the keyword here is growth.

Business development perse says nothing in terms of product maturity. And understanding Bitcoin Cash business as “customers that we have to research and create features for” is an oversimplification that I’m far from wanting to promote. We agree on that. But let’s point out that developing something without listening to the market’s needs in general, with very few exceptions, is a direct path to failure.

I get the impression that Bitcoin Cash is indeed understood by many as a product, and I don’t think such characterization removes value from it. And as with most of the available products, it is not “finished”. Not even MSOffice is finished but subjected to permanent evolution (whether I like it or not). Instead of “finished”, we probably can talk about different levels of readiness.

But the fact that Bitcoin Cash as a product is not finished and in permanent development doesn’t mean we don’t want it to grow. On the contrary, we want it to be the cornerstone of a decentralized economy on a global scale. Under that perspective, I find it interesting to have a plan that expresses the community’s direction best.

Now, for Bitcoin Cash to be that cornerstone, different fronts have to be considered. Undoubtedly, software development, upstream and downstream, is one of them. Still, another no less important is business development around the product itself, with one clear objective: growth (which can be measured by several indicators). If not, we can play all our lives sending a few coins to each other, mining 1MB blocks, and dreaming of the greatness we could have achieved. I hope not.

Some people spend their time in, for example, marketing and onboarding tasks, and they are an equally essential part of the ecosystem. They look from simple users who exchange a few satoshis to large corporations with their intricate operational processes.

In the first case, in general, the activity does not represent significant challenges. In a few words, a person with basic literacy can be explained how Bitcoin Cash works and its many benefits.

In the second case, when the sums involved and potential value rise, the challenge of convincing decision-makers increases exponentially. I don’t know if you have had the opportunity of trying to bring large capitals to the ecosystem, be it through individuals or companies. But I assure you, it’s not an easy task.

Funny enough, this challenge seems not to be tight to the maturity of Bitcoin Cash as a product but to the maturity of the community to resolve their different opinions. Or at least that’s my experience.

Bitcoin Cash, as hard as it is to admit, is known for its internal divergences, which can be wonderful from a romantic point of view, very cool. But when it comes to attracting new business, at minimum is strenuous. The last fork is a clear example of that, and people involved in contacting businesses, exchanges, and pools can attest to that.

From this point of view, which involves, but it’s not limited to, business development (keyword: growth), it seems that a document expressing the vision that unites us and the steps we plan to take in the future together has value. It passes a direction, a degree of the parties involved’ commitment and reliance. Although it’s not rigid, it’s a starting point and a tool to attract users and businesses, among many many things not necessarily related to business development. This tool it’s by no means the only one.

Another aspect I would like to mention is how companies perceive Bitcoin Cash. My understanding is that they know very well they won’t find a finished product in Bitcoin Cash for their arguably “unique use case”.

Companies, in general, have not that degree of innocence. Maybe among some startups with no future or some mid-size companies that lost their way. In general, companies are optimized and consolidated machines that know very well what to do with their money and labor force to obtain the most significant growth. They would be interested, yes, for a certain level of readiness and continuity but not in finished products.

If our vision is to become a decentralized economy on a planetary scale using our product, Bitcoin Cash, as a peer-to-peer value transfer protocol, don’t have any doubt at some point, we must sit down and have a chat with companies and businesses (if not already happening :grinning:). The first thing they are going to ask is:

  1. The vision of Bitcoin Cash.
  2. How are we planning to do it (aka strategy, plan, roadmap, whatever…)

It’s up to us to be ready or not.

Beware that I didn’t mention or refer to Business Models. I just talked about the benefits of showing some direction upon consensus of involved parties.

1 Like

I admit my OP was written hastily because I thought that making such a document would not be controversial. So it basically sucks.

You’ve done a GREAT job exploring the reasons such a thing would be valuable from an adoption perspective as a marketing tool to businesses.

Thanks!

1 Like

No, you misidentified the difference between us.

You see Bitcoin Cash as a product, and as a business.

I see it as a horizontal, a platform that is open for many businesses to exploit but also to extend.

A roadmap makes sense for each of those companies, and I invite a BU, a general protocols, a BCHD etc to each provide their roadmaps. Which provides the value you describe.

Bitcoin Cash is less like MSOffice, it is more like the Internet. You don’t find an Internet roadmap, instead you find many from different vendors and different countries and organizations.

I finished reading the rest of your long post and on general direction and what needs t obe done there is a lot of agreement between what you write and what I think and I know a lot of others in the space also think.

There is work that is being done in https://bitcoincashnetworkdiscussions.org/ and not yet visible is a lot of talks between a good number of people on how to move this forward in a wider and more inclusive way.

I’ve been personally writing a lot on this topic and will hopefully be publishing some of that soon.

1 Like

Thanks @tom just for the record, I do recognize the tremendous value of your perspective about Bitcoin Cash as a horizontal platform, and I pretty much agree with it. Not that I’m somebody, just a user. And in no way I’m trying to promote business development as the last dram of whisky in the highlands… Just another discipline, among others equally important, that will help us move forward in the direction the community decides best.

I used business development as an example of the applied value that a roadmap/strategy could bring. I’m sure that others can talk better than me about similar values related to project management, software development, and other disciplines.

Looking forward to seeing your writings, I’m sure they will bring exciting insights. Count with me in that regard in case of need.

1 Like

I think beyond something like ‘p2p cash system’ is unnecessary. I do think good Schelling points are important, maybe, voluntary funding, multiple implementations, and entrepreneurship would be fine.

Agree completely. Roadmaps for things that aren’t products are counter-productive. Teams can have roadmaps but the cryptoledger itself should just “be”. And even before considering a “road map” - you need to define where you are starting from. One of the biggest challenges for my team’s adoption of BCH as a dev target has been lack of formal specifications for BCH and related protocols like SLP. This not only cost us a couple of months of unnecessary challenges, but also results in us asking questions that would be naive because we don’t know where to look and then the answer of “go to the source” fails because the implementations often disagree.

We actually want to push BCH to some new horizons that we feel are directly inline with the goals of BCH and are investing accordingly. We want to do so incrementally and working within the boundaries or traditions of how things are now whenever possible and only pushing beyond when we find it otherwise can’t be done or is utterly impractical. But we don’t want to publish a “road map” for BCH to adopt our ideals… we prefer to demonstrate the value of the idea by making an implementation that demonstrates both the viability and value with as few changes as possible.

For example - we’re pushing for some functionality to be able to relate SLP-FTs & BCH to an SLP-NFT. We’re planning on demoing this via an auction app. We figured out a few ways to implement this via CHECKSIG or supporting multiple OP_RETURNs. Given the feedback when we reached out, it seemed that multiple OP_RETURNs was the path of least resistance. Our demo will hopefully be available in the next few weeks and will result in recommendations on how to move the functionality, properly, more onchain and detail what the extension to BCH & SLP protocols would be required. But we will do so with working code first.

This concept of working code speaks loudest is the most successful mechanism of separating the wheat from the chaff I’ve seen in working with open standards. The Technical Reports which are generally the result of analyzing different working code examples has been incredibly successful in the ISO C++ committee. If you want to make a road map - define some new architectural driver you think is interesting and invite other interested people to come and suggest how it should work. But then - don’t fix the goals until you have good working examples that might end up changing or extending those goals. It’s through working code that we speak most clearly and loudly rather than debating lots of stuff that will never come to be. But then it is CRITICAL that a clear document results from that code that is an objective specification for others to follow and adhere to going forward. This is the only way a project of the magnitude of BCH can scale and evolve without collapsing on itself. I need only point to the chaos of Ethereum as an example of making things standards before getting real experience to warn us of where it could go. They seem to be slowly learning their lesson the hard way. I hope they will. But we should learn from those mistakes rather than repeating them.

/rant

1 Like

I wanted to share my “vision” document that I published yesterday. You can find it here: