The Bitcoin Cash community is very attached to free markets. And for good reasons, free markets are incredibly economically efficient and have been shown to outperform central planing very consistently to to the economic calculation problem.
While this is correct, Bitcoin Cash supporter often make the mistake to think various variables controlling the protocol, such as the block size, op_return size, script length, dust limit or sigops count, needs to be left to the market, and the market only. This comes from a fundamental misunderstanding of how the market find its optimum. Markets do not spawn some magic fairy to tell you what the right value is. They work by ruthlessly destroying solutions that pick the wrong values and directing resources toward the ones that do.
The market always finds a solution. There is no guarantee that the solution the market picks includes Bitcoin Cash.

The blockchain's content is immutable

It bears to be repeated, what's in the blockchain cannot be changed. Anything introduced in it is there forever and needs to be supported forever. If insecure parameters or rules are picked, then the market cannot course correct the chain, which means it'll guts it to provide resources to another that did not do the same mistake.
A very noticeable example of such event is the ethereum blockchain. It's philosophy is to go fast and break things, and boy do they break things. Wile this approach also has it advantages, it is clear that the teams working on scaling ethereum are facing a serious challenges as the chain state has grown to a size current hardware and software has trouble managing. This places the chain in a do or die position, where they need to improve the software to support larger state properly faster than the state grows or face certain death. The people working on it are very talented, so maybe they'll make it happen. What is sure is that they cannot go back to clear the state or manage create solution that do not require as much state.

The 0-conf problem

We established that picking values for various protocol variables is suboptimal. We also established that it isn't a given that the market will be able to pick a proper value within the Bitcoin Cash ecosystem, but instead can decide to destroy it and move elsewhere. Which leave us to the following logical conclusion: we need to create solutions for the market to discover these values, and if no such thing exists, we'll need to accept being inefficient and agree on some value, as being inefficient still beat the hell out of being dead.
Creating such market has proven to be challenging for a very simple reason: Bitcoin Cash values 0-conf very much. However, if the policies of various actors differs on one of this variable, say the size of op_return for instance, then it come at a cost of destroying the confidence one can have in 0-conf. This is due to the fact that a transaction with an op_return of given size will be accepted by some and rejected by others, leaving the opportunity for double spend to include a different op_return. This was demonstrated by Vin Armani on Dash.
The primary goal of Bitcoin Cash is to be digital cash for the world. This imply that it's most important characteristics are high confidence 0-conf, scaling capabilities and fungibility, each of which are being actively worked on. Considering it is unavoidable for the market to find an equilibrium that various actors play with different values as a policy, and that doing so come at the cost of destroying 0-conf, we fond ourselves where we have to go with the suboptimal route of picking values manually.

Pre-consensus to the rescue

Fortunately I think there is. Bitcoin Cash already allows some variable to be determined by the market by picking limits significantly above what the market demand is. This is for instance the case for the block size. This in effect give the freedom to miner to produce whatever block size they deem appropriate. While not perfect, it seems to have worked really well in practice.
But we can do better. Even before Bitcoin Cash was a thing, I was promoting the idea of pre-consensus. This refers to a set of technologies allowing network participants to agree as much as possible on what the next block is going to look like. If done well, this provides significantly stronger 0-conf guarantee that we currently have, while also allowing to reach greater scale by moving work out of the critical path (if a node know what the next block is going to look like, a lot of the validation work can be done ahead of time). As it turns out, pre-consensus has the added bonus effect that it allows to delegate the responsibility of picking various values which are currently centrally planned to the market. Actors who use different policies will be able to reconciliate their differences in a time scale that is compatible with 0-conf.

Going forward

While pre-consensus is on the roadmap since day 1, it has made close to zero progress. I cannot tell why other have not worked on it, but I know why I did not. This years has been full of crisis to manage, of people wanting attention to get alternatives ideas move forward, the flavor of the day being tokens. While all these project have value, it is clear that I need to ruthlessly prioritize pre-consensus. The actions I have to take along the way will surely irritate many, but this is too important to not be tackled now.


25 of 25 reviewers say it's worth paying for

0 of 25 reviewers say it's not worth paying for
  spent 10.0¢
There is nothing more important than 0-conf/instant trnxs for Bitcoin (cash), without that we may as well wrap up everything and go home.
Edit: Read some of the recent articles
   2yr ago
  earned $1.00
It's not correct that pre-consensus has made no progress; subchain/weak blocks is a form of pre-consensus and tests have been done with it. It might or might not be the optimal solution, but lessons can be learned and we need not start from zero.
   2yr ago
10.0¢ 25.0¢ 25.0¢ 25.0¢ 10.0¢ 25.0¢
  earned 40.0¢
> Markets [...]. They work by ruthlessly destroying solutions that pick the wrong values and directing resources toward the ones that do.
> we need to create solutions for the market to discover these values
The first thing that comes to mind to give the market the choices it wants is to split the chain. We've done it before. I know it's a radical solution with a lot of downside, but it *is* a solution.

   2yr ago
10.0¢ 25.0¢ 25.0¢
  earned 50.0¢
"I see that others are progressing on solutions I don't like, so I'll announce something I haven't even started on to block their work."
   2yr ago
10.0¢ 25.0¢ 24.8¢ 10.0¢
  earned 15.0¢
I 100% support new ideas like this. And I 100% support constructive debate between knowledgeable parties. However, I really hope that this debate remains civilized and about the facts, and that miners (who eventually make decisions) are given enough unbiased information to form an opinion and not just "default to Experts (like happened with Core)" Another good test for BCH and the community
   2yr ago
10.0¢ 25.0¢
  earned 25.0¢
Sounds like you are too busy to implement GROUP which provides native tokens on bitcoin (BCH).
But relax, you are not alone. Other clients can implement it. And the miners can choose what software they want to run.
If the miners disagree among themselves, we get a persistant chain split.
   2yr ago
10.0¢ 9.9¢ 25.0¢
  earned $1.10
I'll be the lone voice here to say this article did nothing to convince me of a need for "pre-consensus".
This is a bad solution for a problem that doesn't exist.
   2yr ago
10.0¢ 9.9¢ 10.0¢ 25.0¢ 10.0¢ 10.0¢ 25.0¢ 10.0¢ 10.0¢ 10.0¢
  earned 10.0¢
It's not clear to me why pre-consensus strengthens the 0-conf guarantee? Does it allow for nodes to rebroadcast a transaction more quickly since they're able to do some work ahead of time, and thereby make it even more difficult for a double-spend broadcast to be seen as valid (since more nodes have the original transaction than without this feature?)
   2yr ago
10.0¢ 10.0¢ 10.0¢
  spent 10.0¢
You didn't do a good enough job of explaining the mechanics of how your idea would work. For me, 0-conf is already good enough. The best/only way to improve it is to improve network latency as far as I see it. On another note, I get annoyed when public articles are poorly written with many spelling mistakes, grammatical errors etc. Can't you get someone to check before you publish it? It greatly devalues the message you are trying to get across due to, for me, a perception of laziness/tardiness? I'll still tip you though.
   2yr ago
  spent 10.0¢
A Dash video does not show a problem with 0-conf on BCH. How do you know there is a 0-conf problem on BCH? Trying to fix non-existing problems or poorly understood problems can create more harm than good. Like with btc scaling and the 1 MB blocksize limit.
   2yr ago