A message from chairman Maomaury to reach.cash
Hey man,
You are clearly not doing good.
You are clearly a very talented individual. You setup a successful website, and iterated on it to make it great. Now you have many users, and they are demanding more and more. You are stretched thinner and thinner. You know that if you stop, everything will unravel real quick. You are seeing your life be sucked away by this thing that you created and you start to resent it. Irritability, loss of your sense of humor and passive aggressiveness are the signs.
You find yourself in this position because your incentives are misaligned. The more this website is successful, the more work you end up having on your plate. But the resources which are available to you do not grow in proportion, and you therefore find yourself in an unsustainable position. You love this thing you created, so you do not want to let it die, and yet, it is killing you.
You accepted large donations. However, while they come with no string attached, really, did they? There is an expectation coming with these donation. The expectation that you will keep things going. The expectation that you will not change direction in a way the donor would not like. Pulling a bait and switch on donors would indeed be a very dishonorable ting to do. You know it, they know it. Every other single prospect donor knows it. No need for a contract for this.
You have one way out of this. Extract a profit from what you have created. The more successful it will be, the more resources you'll have to handle it. It will not be eating away your life, but it will feed it instead. Reading between the lines in your posts, it is clear that you consider not having benefited from read.cash a good thing. Let me be blunt: it is not and it is why you are having so many problems today.
You don't have anyone preventing you from taking VC money, taking a fee on activities on the site or anything else. This limitation is self imposed and you can free yourself any time. This is hard, first and foremost because you will have to reconsider a to of things. This is not simply a business model change. This is a worldview change. This is hard. I urge you to do it anyways. For this website, for this community, but first and foremost for yourself.
Take a day off. Or two. Or more. Go see some friends. Do not check your mail, support tickets or anything. If the server goes offline, then so be it. Cool down. Wait for your sense of humor to come back. And when this happen, come back on this website, work on monetizing it and grow the shit out of it.
This is worth it. You are worth it.
Announcing the Grasberg DAA
The Bitcoin Cash community has shown great interest in improving the DAA. While there is a lot of discussion around the DAA, no concrete proposal has reached ABC at the time of this writing, which does not leave us with sufficient time to review adequately, simulate and test, and get feedback addressed before the feature freeze on August 15th.
Bitcoin ABC is therefore moving forward with the Grasberg DAA.
The Grasberg DAA aims to solve 3 main problems existing right now on the Bitcoin Cash blockchain:
Ensure more consistent block production, which will translate into more reliable confirmation times for users, and will also reduce occurrences in which users run into per-block limits.
Ensure that steady miners get close to optimal profitability vs alternative mining strategies.
Ensure that the emission of coins follows a predictable schedule.
The source code for the Grasberg DAA is available for review. https://reviews.bitcoinabc.org/D6981
Design Choices
The Grasberg DAA is based on an ASERT core. ASERT is a DAA proposal made by Mark Lundeberg which has very interesting properties and would be perfect for a new blockchain, but it has to be modified slightly to fit Bitcoin Cash's requirements.
Work-based
The original ASERT proposal assumes that work and target are inverse of each other. In practice this is not exactly true. While the difference is not big enough to make ASERT based on target unworkable, we should do what is correct as much as possible. Grasberg is therefore working on the work required to produce a block rather than the target.
Fixed-point math
ASERT needs to compute an exponential. In order to make the DAA 100% predictable on all machines, the use of floating point needs to be banned. This lead to the implementation of a fixed point approximation of an exponential.
This approximation is computed via the use of lookup tables and a polynomial of order 2 to improve the result. This leads to a precision that exceeds the precision of the input which has a second granularity and is therefore deemed enough.
Relative form
ASERT has two formulations, an absolute form, using a reference block, and a relative form using the two most recent blocks. While the absolute form has numerous advantages over the relative one, such as self-correcting imprecisions due to rounding, it does make the activation much more complex. The absolute form would certainly be preferable on a system that is built from scratch, but Bitcoin Cash has an history.
Parameters
The chosen half-life is of 288 blocks, or 2 days, as suggested by Jonathan Toomim in his analysis of ASERT.
Drift correction
Grasberg includes a drift correction mechanism. While ASERT does not drift very much on its own, Bitcoin Cash has experienced significant drift in the past. Choosing a reference point other than the genesis block is effectively equivalent to redefining the coin emission policy, which is a big NO.
The drift correction adjusts the targeted block time up or down slightly in order to catch up with the expected emission schedule. This adjustment is small and bounded in order to not disrupt the user experience. It is also purposefully defined to be tame so that its influence is bounded to larger time scales.
Some will find that this mechanism breaks the mathematical beauty of ASERT and they'd be correct. Unfortunately, ASERT in its absolute form using the genesis block as reference would jack up the difficulty so high due to pre-existing drift that it is a complete non-starter.
Once again, Bitcoin Cash is a chain with a history, not a new blockchain that we start from scratch. The upside of such a mechanism is that it ends up being more precise than ASERT at correcting drift. Once existing drift is absorbed, it will be possible to predict with a high degree of precision when a block is going to be mined, even many years in advance.
Testing and simulations
Bitcoin ABC has already run simulations and real-world testing of this algorithm, but is inviting other parties to reproduce the results - hopefully - or not. We also want to encourage anyone with knowledge of C++ or DAA in general to review the source code of the Grasberg DAA. https://reviews.bitcoinabc.org/D6981
Bitcoin Core developers do understand economics
There is a common theme in various crypto circles that Bitcoin Core developers do not understand economics, and this is therefore why they made decisions such as keeping the block size small.
This argument is often professed by people who themselves think they have a great understanding of economics because they've read Rothbard, Mises or Hazlitt. Unfortunately, they demonstrate doing so how spot on Hayek was when he wrote abut the pretense of knowledge.
In my presentation in Arnhem in 2017, I explained what are the incentives of different actors in the space and how there behavior is explained by their incentives. However, it wasn't the main point of the talk and it is definitively a point worth going over again.
https://www.youtube.com/watch?v=By0w43NQdiY
What is a rational economic agent
In economics, a rational agent is an agent able to take into account available information, probability of various events taking place, risks and benefits, and its own self preference to make the best decisions.
Bitcoin is secured by incentives, which means it assumes a large portion of its participants are rational agents. While this is not stated in these terms in the whitepaper, Satoshi is very clear on the matter - and and study of Bitcoin's security model will confirm this from first principle to anyone willing to go through the trouble.
He ought to find it more profitable to play by the rules, such rules that favour him with more new coins than everyone else combined, than to undermine the system and the validity of his own wealth.
An agent which does not understand economics is unable to be rational and, therefore, will makes choices that are sub-optimal or even sometime detrimental according to its own preferences. Conversely, an agent which understands economics is able to make optimal choices based on available information.
In order to decide if Bitcoin Core developers understand economics or not, we need to ask ourselves if they've acted as rational agents or not.
Are Bitcoin Core developers rational agents?
To understand this, we first define a realistic set of preferences for Bitcoin Core developers. Let's assume that they value money and status and would rather avoid poor working conditions, such as adding upon themselves additional work and responsibilities.
Obviously, in the real world, there is not such things as a Bitcoin Core developer. Each of them are individuals with different preferences, but, fortunately, the assumptions we are making about their preference are very bland and will fit almost everyone who ever lived, and this will be sufficient for our demonstration.
An analysis of the alternatives that were available to Bitcoin Core developers when they took actions for which they are deemed to have lacked economic insight will tell us if this is effectively the case or if, they were able to understand the different incentives at play and make a rational economic choice. We will limit ourselves to the analysis of the 1MB limit and its alternatives, as it is obvious that other choices made such as RBF are simply the natural continuation of keeping that limit in place, and this is therefore the choice that matters.
Money
Everything else being equal, every one of us would like to have more money. Bitcoin Core developers are no exception. The main sources of funding for the Bitcoin Core project, as far as I know, are Blockstream and the MIT media lab.
Blockstream is a company that makes money by selling products such as Liquid. These products are more valuable when blocks are small and therefore the incentive for Blockstream, as well as for Bitcoin Core developers funded by Blockstream, is to keep blocks small.
The MIT media lab is an academic institution. It's goal is therefore to build interesting technology and do scientific experimentation. Looking at this way, a roadmap including sidechains, lightning network and other complex technical schemes is preferable.
On the other hand, the larger block community just closed a funding round of roughly $500k that must we shared across 6 node software - and this has largely been reported from within the community as a success. My guesstimate is that it is more than an order of magnitude smaller than what is provided to the Bitcoin Core project - and for 6 projects. It is therefore not reasonable for Bitcoin Core developers to have found an alternative source of funding allowing them to make more than what they do now.
Considering the current Bitcoin Core roadmap is supported by institutions that are willing to put an order of magnitude more money into funding its infrastructure, it would be widely unrealistic from the part of these developers to expect making more money by making an alternative choice. We can therefore conclude that they made the rational choice by keeping block small when it comes to money.
Status
The Bitcoin Core community often states that it has the best developer in the world. We can debate if this is true or not, but in our case it doesn't matter. First because economics tells us that value is subjective, and therefore it is possible that the Bitcoin Core community effectively consider these people as the best in the world, but more importantly because it doesn't mater if this is true or not, what matter is that they are conferred the status.
On the other hand, has they made an alternative choice, they'd have to deal with community leaders such as Roger Ver who consider they have to be held in tight leash and collar. https://archive.ph/JcX0c#selection-2237.365-2237.443
It is therefore evident that Core developers made the rational choice when they kept blocks small in term of status.
Workload
Increasing the size of the blocks require a lot of work from developers. As block gets bigger, every inefficiencies in block processing gets bigger in the same proportions - sometime worse. What can be a problem small enough to be ignored at one scale can become exceedingly important to fix once the block size is increased.
In addition to regular development work, larger block also means that various attacks on the network can be executed much faster or with much greater impact. A concrete example of such an attack is the now fixed out of memory problem revealed by Christopher Jeffrey at Breaking Bitcoin in 2017. https://www.youtube.com/watch?v=0WCaoGiAOHE&t=8928
This in turn increase the pressure due to developer being effectively always oncall, even though nobody is paying for it.
Once again, what is the rational choice for Bitcoin Core developers is self evident.
Conclusion
The Bitcoin Core developers have demonstrated via their behavior that they understand their economic incentives and are able to act as rational economic agents by making choices aligned with these incentives.
On the other hand, people accusing them of being economic ignoramus have demonstrated an inability to understand the plurality of economic incentives that exist in the ecosystem, which is the base of every economic thought.
While it is undeniable that users and businesses benefit tremendously more from a Bitcoin network that is uncongested and over which transaction are cheap fast and reliable, it is also undeniable that these same users and businesses failed to provide the proper incentives for Bitcoin Core developers to make it happen. In doing so, they also demonstrated a very poor understanding of economics.
When people quoting Mises and Rothbard, bragging about their economic knowledge, fail to apply economic principle so fundamentals that they'd have Keynes and Hayek in agreement, we are reminded that markets are about human action, and that these self aggrandizing words mean very little.
On the Bitcoin Cash block time
It recently came to my attention that reducing the block time for Bitcoin Cash is still a hot topic in the eastern community. There also seems to be a lack of knowledge of the various arguments surrounding the matter, so in this article, I hope to clear things up a bit.
Why faster blocks?
A shorter block time has several advantages that shouldn't be dismissed too quickly.
As blocks come faster, the amount of mining work required to produce a block will diminish. For instance, if we reduce the block time to 1 minute, then each block will become 10x easier to produce. So the security of transactions is the same on long timeframes. 10 blocks at difficulty 100 is the same as 100 blocks at difficulty 10. But this is not the case in short timeframes. 1 block at difficulty 100 is significantly less secure than 10 blocks at difficulty 10. The math behind this can be a bit complex, but the intuition is that an attacker has 10 minutes to run its attack rather than 1.
Having higher security on a short timeframe would allow services such as payment processors and exchanges to process transactions faster, enabling more use cases on BCH. For reasons related to scaling, it is not really possible to dramatically reduce the block time, so this is not really a solution for instant payments, but it is very useful for arbitrage or reducing risk due to price variation for merchants.
Another important benefit of reducing the block time is to provide more information to the difficulty adjustment algorithm. The difficulty adjustment algorithm uses past blocks to estimate the amount of hashrate on the chain and adjust the difficulty accordingly. However, there is a lot of variance in the individual block time, so it is necessary to use several blocks to make a decision. The more blocks are used, the better the decision, but also the longer it takes to make that decision. There is an inherent tradeoff that can be improved by providing more blocks faster to the algorithm, allowing it to adjust faster and more precisely.
Considering all of the above, if I were to start a new coin from scratch, I would likely choose a block time lower than 10 minutes. Maybe 2.5, or even 1 minute, but no lower, for reasons that I will explain. However, when it comes to Bitcoin Cash specifically, it must be understood that there are drawbacks associated with the fact that there is an existing system, and so the benefit we need to expect from such a block time modification needs to be way higher than what is required from a new system.
Why do faster blocks hinders scaling?
Any bitcoin style network requires the block time to be significantly larger than the time required to process a block by the network as a whole. If that is not the case, then the capability of the network to come to an agreement is severely damaged. The most extreme case obviously occurs when blocks are produced faster than the network can process them, effectively sending each miner on its own chain. But even before the network reaches this state of total collapse, the quality will degrade due to the orphan rate increasing.
Intuitively, one would expect that if we make blocks faster, then each block would be smaller, and therefore, faster to propagate. To some extent this is true, but this is neglecting the fact that there are fixed costs associated with propagating a block. These costs do not depend on the size of the block. To understand this, let's assume that we have Alice, Bob and Carol propagate a block to each other in a way similar to what nodes on the network would be doing.
**Alice, to Bob:** Hey Bob, I just got a new block, its hash is 00012345af, do you want it?
**Bob:** Hey Alice. I do not know about this block, please send it over to me.
**Alice:** Alright Bob. So the first transaction in the block is .....
**Bob, to Carol:** Hey Carol, I just got a new block, its hash is 00012345af, do you want it?
**Carol:** Hey Bob. I do not know about this block, please send it over to me.
**Bob:** Alright Carol. So the first transaction in the block is .....
This is fairly similar to what happens on the network between nodes when a new block is found. As we can see, there is a fair amount of back and forth between the parties in addition to the transmission of the block itself. This back and forth is required because if it did not take place, then all the nodes would start to send blocks to everybody at once, causing a total network collapse when a new block is found. There are various tricks that can be used - and in fact are used by the Compact Block technology that is used by Bitcoin ABC nodes - to improve the situation, but the general problem remains, there are overhead costs.
By changing the block time from 10 minutes to 1 minute, we would effectively multiply by 10 the overhead cost that happens on a 10 minute time scale, which would limit how much we can safely scale the system.
What about faster confirmations?
While faster blocks would improve confirmation time, it cannot ultimately do it on a timescale that really enables many use cases. For any face to face interaction, the confirmation time needs to be lowered to 3s or less to be very impactful, something we cannot do with the block time. This is something that the Avalanche technology can achieve. The prototype that exists now is able to confirm transactions in less than 2s.
While some use cases such as arbitrage would benefit from this, it is probably not sufficiently aligned with the Core values of Bitcoin Cash to justify changing something as central as the block time.
What about difficulty adjustment?
Faster blocks can help design better difficulty adjustment algorithms because they provide more data that can be used by such algorithms. The obvious downside is that there is more data to process, which leads to more load on SPV systems, as well as seriously limiting what very lightweight systems such as smart cards can do.
While this is certainly not an impossible amount of data to process, people make assumptions when they decide to build on Bitcoin Cash, and breaking these assumptions is detrimental to the growth of the ecosystem.
Why is it harder to change the block time on an already deployed system?
I stated in this article that I would choose a block time shorter than 10 minutes if I were to build a new system from scratch. However, on a system such as Bitcoin Cash, there are already many existing users. Bitcoin Cash has a script system that has time based features, such as locking coins for a certain amount of time before they are spendable.
These features are essential for many smart contract systems, notably payment channels or recurring payment solutions such as Mecenas. These contracts do not have a source of time, and therefore use the blockchain itself as a clock. Changing the block time would therefore effectively change the speed at which time passes for all these contracts, breaking the system they are built upon.
To add to the challenge, Bitcoin Cash supports P2SH, which means we are not aware of all the scripts that are associated with existing coins. It is not possible to parse the blockchain and devise a system that would work for existing contracts, so we are forced to devise a system that will work for all contracts that could have been written. It is not certain that this can be achieved at all without serious downsides, but what is certain is that nobody has the time or resources required to make an honest attempt.
Without a solution to this problem, we do not have a very concrete proposal to change the block time we can discuss.
Conclusion
There are many challenges to changing the block time and some of them are unsolved at this time. Investing in solving these does not seem to me to be the right path considering the downsides and maximum gains in terms of confirmation time, and the existence of better alternatives.
With our current roadmap, we estimate that we can deliver avalanche in 2 years. However, we would like to deliver this much sooner if resources allow. After all, Avalabs does have a working implementation, so there are no reasons to expect avalanche to eternally be 18 month away.
On the infrastructure funding plan for Bitcoin Cash
Recently, Jiang Zuoher from btc.top indicated that he and a group of miners want to **create a fund for Bitcoin Cash's infrastructure**. This is great news. This may sound to some like the proposal fell from the sky, but it has actually been a long time coming. The Chinese mining community has been attempting for years to do something similar to what is currently being proposed. https://medium.com/@jiangzhuoer/infrastructure-funding-plan-for-bitcoin-cash-131fdcd2412e
Earlier attempts failed for various reasons, but mainly because it is difficult for a set of actors who are otherwise competitors to agree on something for an extended period of time. A group of competitors in an industry setting aside their differences to partake in actions for the benefit of the industry is called a cartel, and cartels tend to be unstable. They asked myself several times to implement such a measure in Bitcoin ABC directly, to which I responded every time that such an initiative needed to come from the miners as there is obvious conflict of interest if devs decide to take away money from miners and pay themselves with it. Some lines are best not crossed.
Sound game theory
The proposal is very interesting from a game theory perspective. Bitcoin, all flavors, have suffered from a problem funding the commons as popularized by **Lloyd**. The commons are public goods that benefit the ecosystem as a whole, whether each participant pays for it or not. This often leads to the tragedy of the commons, where everybody expects everybody else to fund the commons, and nobody does, or only do so to an extent that is not sufficient for the whole ecosystem to thrive. https://en.wikipedia.org/wiki/William_Forster_Lloyd
In the early days, developers, miners and users were essentially the same people, so this was fairly simple. As the system grows, economic specialization took place and this is forcing us to think about the incentives that these specialized groups have to cooperate with each other. And they are not good. The people who care most about the system will voluntarily fund commons, while people who decide to be parasitic and use the commons without funding them will not. This creates an ecosystem in which those who care about the system are disincentivized and parasites are incentivized. Such an ecosystem is bound to attract a lot of bad actors, and, as a matter of fact, we can verify that it indeed does.
Any ecosystem that is unwilling to look this reality in the face is bound to either fall into irrelevance or be co-opted by parasites.
A group of miners is proposing to try something different that does not have this drawback. Moreover, they decide to do it using Bitcoin Cash, which demonstrates support and commitment to the project.
However, while the game theory is sound, several people have voiced concern with this plan.
Not a tax
A tax is a compulsory contribution to state revenue. Let's ignore the state part of the definition, as miners are clearly are not a state, but this is not really the crux of the argument. What people calling it a tax have a problem with the compulsory contribution. So, is it a compulsory contribution?
I would argue that it is not.
When a miner mines of top of another miner's block, they effectively choose to cooperate with this other miner. They usually do so because it is in their best interest to, but nobody is ever entitled to anyone else's cooperation. What this group of miners is saying, is that they do not wish to cooperate with other miners that do not wish to fund the commons.
They are not forcing anyone to do anything. Other miners can mine another chain such as BTC, or even decide to mine a chain that will not fund the commons. What they cannot do is force Jiang to accept their block if they do so, or to force the market to value these blocks at a certain price, if at all. Jiang does not have this power either.
Once a cartel is in place, it won't be able to impose its will on the chain
Some people are concerned that, while funding infrastructure is good, forming a cartel to do so is not. I think these people are used to government created cartels, such as what happened when the government creates licensing laws. In a free market, cartels tend to be fairly unstable.
It is important to keep in mind that cartel participants are otherwise competitors. They therefore all have an incentive to defect from the cartel. A cartel can hold for as long as all of its participants see a benefit in the actions of the cartel. And it seems that they all see a benefit by making sure that the infrastructure on top of which their business is built is robust, and remains so going forward.
So what about other measures? Could transactions sent to wikileaks be censored for instance? I will argue that it is not credible that all participants in the cartel see this as a beneficial development, and the most likely outcome of such a proposal would be the dissolution of the cartel.
Beware the money you take
When accepting money, you always give up some power. It can be explicit like in the case of an investment firm providing money to a company in exchange for partial ownership. But even when no such things exist, whoever funds a project always ends up having some control over it, at the very least because the funding can be pulled.
This is why Bitcoin ABC has been very careful about accepting funds. For instance, we recently **rejected funding from OKex** for that very reason. https://medium.com/@amaurysechet/update-regarding-the-okcoin-fundraiser-d6a726e71f8d
However, no organization can operate durably, yet alone thrive, without funding. The miners who decided to propose the plan all have proven that they care about the success of Bitcoin Cash. I cannot think of a better source of funding.
In addition, the value of the funding depends on the value of BCH, which creates great incentives for its beneficiaries to act in the best interest of Bitcoin Cash.
Who control the funds
This is obviously the elephant in the room. After all, maybe Jiang, Jihan and others only plan to cooperate to increase their share of the mining reward and won't provide anything to the infrastructure?
First, such a scenario is highly improbable, as we've seen before, the cartel would dissolve. But the question of transparency of the funds remains. We need to be sure they will be spent in a way that benefits Bitcoin Cash's commons.
This is a difficult task because we do not want to transform the whole thing into a bureaucratic process that would be both slow and inefficient. In a free market, the most efficient system wins.
I propose that the control of the key needs to be in the hands of people who have proven they work in the best interest of Bitcoin Cash, even during rough times, have a commitment to infrastructure and a proven track record, such as Jonald Fyookball, Mengerian and myself. This would effectively give 2 people in this group a veto power over spending, and, obviously, miners would also have veto power as they can decide to discontinue the plan.
I would also invite a group of trusted community members, such as Vin Armani, Josh Ellithorpe, Chris Pacia or Mike Malley who can advise on ways to spend the funds, as well as blow the whistle in case something fishy is going on. A group of 7 to 12 miners, developers, and businessmen in total would ensure that various sides of the ecosystem have their say without bogging down the whole thing with unnecessary bureaucracy.
Conlusion
I'm enthusiastic this proposal can yield very beneficial results to Bitcoin Cash, granted the details are done right. I think the proposed setup would inspire more trust from the community than a faceless corporation, which seems to be the major concern.
I predict that if this is done right, the impact on Bitcoin Cash can be fantastic and will result in benefits for all ecosystem participants.
Clearing the Way for Cooperation
There is a misunderstanding between Roger Ver and myself, which takes the form of a specific issue, but is also part of an ongoing communication problem. By writing this, I hope we can improve this situation. Even a minor improvement here would be of value.
One of the main roadblocks looks on the surface like it is related to personality clashes. The feedback I have gotten from others is that I am “attacking Roger and Bitcoin.com on social media”.
So before going further, I should say that it is not my intention to attack or badmouth Roger or his company. I’m sure it looks to some people that I have been doing exactly that, but this is part of the misunderstanding. The reason I give Roger flak, and focus on what he says, is because I recognize that he is a valuable part of our community, and what he says matters.
Following the wisdom of “seek first to understand, then to be understood”, I can understand how I can appear to others. People do sometimes find me hard to work with. I’ve been called “unpleasant” and “abrasive”. I have my challenges with communication. If it helps, I apologize to Roger if I’ve rubbed him the wrong way.
**The Missing $500,000**
Roger, you recently made a Reddit **comment** saying ***“I've donated / paid about $500K to ABC over the last few years”.*** I challenged the accuracy of this number in the same thread (I don’t believe we’ve received anywhere near that sum). You haven’t made any response to this, other than a private communication that it was being looked into. https://old.reddit.com/r/btc/comments/ebk1j5/an_open_letter_to_roger_ver/fb6zc1e/
Perhaps from Roger’s perspective, it appears that this is just another ungrateful, nitpicking complaint from me, and that I’m harassing him over financial details and wasting his time. Or, even worse, that I’m getting money from him while also bad mouthing him for it, complaining over and over, and having a bad attitude.
But, it is only fair to hear my side of things as well. Even if this number is inaccurate, some may wonder why I am harping on this point and refusing to let go of the issue.
**My Side of the Story**
I’m not going to write a long essay here, let’s just go right to it: Roger also made a comment recently that “ABC was dragging its feet” when it comes to development. In isolation, neither this comment, nor the $500k comment is accurate, but together they paint an especially bad and unjust narrative about Bitcoin ABC.
If I have to spell it out, there is a narrative being created here that essentially says *“Bitcoin ABC has been given plenty of money and they’re not doing the work”*. You can use your imagination to figure out what the implications of this false narrative are, and what this might lead to.
In general, narratives can destroy a community and we saw that happen before in Bitcoin Cash. And again, help with the legal bills is appreciated, but doesn’t impact the speed of developing code.
Battling misleading narratives makes it hard for me to do my job, both in terms of management and logistics, and also it is very demotivating, and a huge drain of time and energy. Misinformation is poisonous , and this is why it is so important to rectify it.
Also, it is unfair to expect me not to defend my position in public when this kind of narrative is being allowed to go out there unchallenged due to the fact that Roger did not retract his statement about the amount of money. So, while it may seem like I am “attacking” by bringing up this point, I feel that I am being attacked and forced to defend myself as long as it isn’t corrected.
**What is the Larger Issue Here?**
Yes, there is a communication problem but there's something else too. This may be a touchy subject, but in my view, Roger has repeatedly amplified people who push a message of "ABC is bad; they are Core 2.0, etc". I won't name names here as that wouldn't be productive, but I can assure you that I am not alone in this opinion.
There has been pervasive gaslighting (bordering on abuse) against ABC that has been allowed to go on for years, ever since Bitcoin Cash was created. The $500k issue is relevant to this pattern as now it is Roger himself who is either knowingly or unknowingly creating a similar narrative.
Maybe my own communication style over the years has provoked that response in Roger to a degree, and has helped start this negative cycle, so I will accept my part of the blame in that, but I think this cycle needs to stop.
I don’t know how to fix all the interpersonal issues in our community. It's true I don’t always have the best attitude, but communication is always a two-way street.
Bitcoin Cash is getting a spec!
Ever since Bitcoin Cash was created, the need for a specification has been very present in the minds of the people who created it. This is why we took it upon ourselves to document every single change we made to the protocol.
It is possible the find the specification of OP_CHECKDATASIG here: https://www.bitcoincash.org/spec/op_checkdatasig.html
The documentation of the new cashaddr format: https://www.bitcoincash.org/spec/cashaddr.html
However, while we took great care to document any changes we made, one major problem remained: the existing state of affairs is poorly documented. The best effort on that front is, to my knowledge, the bitcoin.it wiki: https://en.bitcoin.it/wiki/Protocol_documentation
This leaves with a task way bigger than we have manpower for. While many asked for a specification, very few have risen to the task of making it happen. The current specifications have been almost exclusively written by Antony “Mengerian” Zegers, Shammah Chancellor, freetrader, Mark Lundeberg and myself. These are names that anyone familiar with the Bitcoin Cash community will recognize as major contributors and herein lies the issue: it is expected from a handful of people to not only design the protocol, but coordinate with the ecosystem, write the software for it, run tests, and write a specification for it, all with little funding and a lot of posturing from 3rd parties wanting to gain influence without providing the amount of work that would justify such influence.
Enter Josh Green and Bitcoin Verde. Josh has proposed himself and his team to write a specification for Bitcoin Cash. His company wrote the Bitcoin Cash node Bitcoin Verde, and he more than anyone else can attest to how important having a proper specification is, as it would have made his job tremendously easier.
The creation of a formal specification for Bitcoin Cash is great news! However, we need to keep in mind that a previous attempt at writing a formal specification occurred in the past, funded by nChain. Taking control of the specification, rather than contributing to preexisting efforts, is a logical move for an attacker wanting to take advantage of a poorly funded infrastructure. As Justin Bons stated, a poorly funded and maintained infrastructure is susceptible to capture.
https://youtu.be/WAAJVD8UsGI?t=1170
In order to make sure no act of manipulation takes place, it is vitally important for the community to ensure that the right people are involved. People who have proven, not only by their words, but by their actions and achievements, their commitment to Bitcoin Cash and its goal: peer to peer cash for the world, enabled by cheap, fast and reliable transactions.
Josh Green is a good leader for this project. He has proven to be professional, and writing a node from scratch is an achievement that can hardly be understated. It demonstrates great commitment, outstanding professionalism and the capability to lead his team toward success even under very short timelines, in addition to a good familiarity with the details of the protocol.
But Josh’s involvement is not enough. For this project to be a success, it is imperative that he leverage the talent of other members of this community. With this in mind, I strongly suggest the following additions to the existing specification authoring team.
* **Chris Pacia** from BCHD, and who was instrumental in designing several features deployed on Bitcoin Cash, such as OP_CHECKDATASIG as well as several others in progress.
* **Mark Lundeberg** who, in addition to being one of the people who is already writing specifications for Bitcoin Cash, also designed and implemented several of its features.
Finally, the specification needs to be made in such a way that it is usable by all actors wanting to provide value to the Bitcoin Cash ecosystem. It must use a license compatible with MIT, which is currently the de facto standard in the ecosystem. But a license is not enough. It is also important that the specification doesn’t live in a walled garden. No matter what the license is, a malicious actor could create a de facto capture by requiring the use of non standard tools, for instance.
If this is done properly, this specification should live on the Bitcoin Verde documentation website, within bitcoincash.org specs as well as in any other place which desires to host it. https://bitcoinverde.org/documentation/ https://www.bitcoincash.org/specs/
I support the effort to write good specifications for Bitcoin Cash. The points outlined above are provided because I believe they are instrumental in ensuring that the project provides genuine benefit to the Bitcoin Cash community. I will be following progress with interest, and hope this project has great success.
@deadalnix