原始的比特币商业模型被打破
作者： ****TobiasRuck**** https://read.cash/@TobiasRuck
原文发表于： **https://read.cash/@TobiasRuck/the-og-bitcoin-business-model-is-broken-979a132e**
2020年，美联储印的美钞量**占历史上美钞发行总量的22%**。很明显，美元将引来大通胀。 https://www.youtube.com/watch?v=r7GzaLROW0E
如果有人问我应该投资什么，我当下的回答一定是：黄金和白银。
而不是比特币，比特币现金或其他任何种类的密码货币。
为什么呢？
比特币走进我们的视野已有11个年头，然而它和它的分叉币绝非是有史以来最佳的货币-美元的可行替代品。
对不懂技术的人来说，美元是
（交易确认）**更快速的**，使用信用卡和PayPal感觉支付瞬间完成
（交易费用）**更低廉的**，单一欧盟支付区（SEPA）的交易是免费的，客户使用信用卡和PayPal的支付也感觉是免交易费的
（交易）**更加可靠**，因为它由国家做后盾保障，相对稳定，几乎在任何地点都可用于支付，并且总能找到人帮你处理交易。
因为比特币技术上存在巨大优势（基于UTXO的链是可扩展的），本可以轻易超越现有的传统金融服务。随之而来的一个大问号是：为什么现实并非如此?
要我回答的话，答案是：利润。
或者说缺乏利润。
**用比特币取代美元，没法直接赚到钱。**
截止到目前，比特币的原始“商业模型”一直是：购买比特币，普及/开发比特币，比特币增值，获利。
Roger Ver, 作为最早期的比特币初创企业投资者和比特币现金最知名的支持者，**是这种模式的支拥簇者**。这可以理解，毕竟这种商业模式推进了早期的比特币采用。 https://read.cash/@deadalnix/bitcoin-core-developers-do-understand-economics-f87cd400#comment-93862e65
但这是非常非常糟糕的商业模型。**它无法起作用**。它受限于搭便车的问题，把比特币的推广变为公共事宜。这几乎和**总是逐渐没落**的马克思主义合作社的模型相一致。 https://fortune.com/2016/12/12/michigan-marxist-vegan-restaurant-closes/
**在这种模型下，无论你是刻苦努力还是工作懈怠， 得到的回报都是一样的。**更糟的是，在比特币中，如果你不是早期投资者或入行不够早，你获得的利润和那些早入行的人相比要少很多。这样一来，我们基本把未来能协助取代美元的人才排除在外。
我在接下来的帖子中将进一步讨论能够生效的模型，因为我相信如果我们采纳投入回报相一致的模型，我们能以更快的速度取代美元；不过，让我们首先来详细讨论一下这个观点。
如果使用原始的“购买比特币，普及比特币，获利”模型，我们就人为地将比特币的普及/开发变成了公益。当下，绝大部分的普及/开发是由无私说服业务/写代码的人完成 （或无私的人以捐赠的方式资助这些工作）。作为回报，比特币价格的增长，每一个持币人，包括这些做贡献的人，将获取利润。**但除了比特币价格的小幅上涨外，这些人没有得到什么回报**。
这就是公益事业的机制。
其实有让公益运转的办法。诺贝尔奖得主埃莉诺·奥斯特罗姆（Elinor Ostrom）以她的8大准则指导我们如何“管理公地”：
明确定义团体界限。
根据当地的需要和条件，来制定与管理公益事业使用相一致的规则。
确保受规则影响的个体可以参与规则的修改。
确保社区成员的规则制定权得到外部权威的认可。
开发一个由社区成员执行的系统，用以监控成员的行为。
对违背规则的人进行分级处罚。
提供方便的、低成本的争端解决方案
从最底层到整个系统内部建立嵌套式公共资源的管理责任
如果依次套用这个列表，我们很快就会意识到以上**没有一点**适用于原始的比特币商业模型，因为后者是一个无需许可的系统。就看第一条规则：明确界定团体界限。我们到底如何能定义比特币的团体界限呢？根据字面意思，我们无法将任何人排除在外，因为每个人都有参与的自由，并且我们也无法阻止他们的行为。你就更不用让我谈第六条准则了。
在我看来，Bitcoin ABC提出的全球网络理事会可以解决公益性 "基础设施建设 "的资金问题，是一次很好的 "治理公地 "的尝试；而那些设计规则的人应该密切关注奥斯特罗姆的8条准则。全球网络理事会肯定已经满足了其中的一些准则，尤其是准则1。
让我们回到原始的比特币商业模型。
在很长一段时间后，总会有两种结果：
**无私的人将继续普及/开发或者为此捐赠，直到他们感到被压榨和榨干，他们才会沮丧地离开**
**有人带着健全的商业模型来“接管”**
我们反复看到这样的情况：
小区块者出现在比特币的舞台上，提出了名为Liquid的可行商业模式，并最终接管了整条公链；而大区块者则转到了自己的公链--比特币现金。
2014年，达士带着名为Treasury的可行商业模式出现在公众视野，带走了很多信奉点对点电子现金的人。
2015年，V神提出了以太坊，并提出了一个名为以太基金会的可行商业模式，带走了基本所有专注于智能合约的人。
2018年，BSV横空出世了，并提出了可行的商业模式，即矿工直接出资，带走了相当一部分 "数据上链 "的人。
2019-2020年，AVAX出现了，并提出了可行的商业模式--Ava Labs，从目前的比特币现金社区带走了很多专注于快速可靠支付的人。
2020年，比特币现金的主导实施者-Bitcoin ABC，，正带着一个可行的商业模式-全球网络理事会走来(该模型的资金来自于coinbase规则）。他们的目标是吸纳所有专注于点对点电子现金的人。**点击此处**可以阅读我对他们原始提案的想法。 https://read.cash/@TobiasRuck/why-i-support-the-ifp-despite-the-community-seeming-to-hate-it-and-how-to-fix-it-d128e975
目前，比特币现金中的许多人对Bitcoin ABC和全球网络理事会不满；他们建立了一个名为BCHN的新节点，借此希望继续沿用原始的比特币商业模式。从经济原理和历史先例来看，可以非常轻易地预测到这种努力的结果：要么人们的热情被燃烧殆尽而后离开, 要么有人会带着可行的商业模式来 "接管".
更糟糕的是，很多支持原始比特币商业模型的知名人士都**极力敌视从协议中获利的想法**。
“Collin’ It Like It Is”的节目主持人科林·埃斯坦德（Collin Enstad）**在最近的一段视频中**说："11月之后[......]比特币现金将继续为世界打造点对点的现金，因为它舍弃了又一个**想利用该协议为自己牟利的团队**"。 https://youtu.be/Xi2oxu1pOJ0?t=3m40s
可重复使用地址的作者Imaginary Username**在最近的一条推文**中，对Bitcoin ABC的首席开发者阿毛里·萨谢（Amaury Sechet）说。"谁想掠夺协议怎么解释呢？” https://twitter.com/im_uname/status/1304338187825807362
很多人也抱有类似的情绪;这些人不约而同地将coinbase规则称为税收，提出这（规则）是盗窃。
换句话说，取代原始的比特币商业模型的想法本身就要遭到反对。
当然，这种情况的结局不容乐观。要么人们沮丧地离开，要么有人带着可行的商业模型接管。
原始的比特币商业模型的死亡之轮还能持续转动多久？
取而代之的是，我们需要**拥抱逐利动机**，并提出真正有效的商业模型，即：可正确激励参与者的模型。
关于我更多的观点，请持续关注我的后续文章。
Refutation of “The OG Bitcoin business model works fine”
This is a refutation of this article: https://read.cash/@noise/the-og-bitcoin-business-model-works-fine-ec62a251
Noise makes two contradictory arguments:
> The OG Bitcoin business model works fine
> Adoption has been set back by attacks
He makes no attempt at resolving this contradiction, hence the article is moot.
He does argue irrelevant points though, red herrings one might argue:
Bitcoin is actually better than the USD
He believes 11 years is not long
The projects I listed that took over actually also have bad business models
In order to enforce Ostrom’s 8 principles, we need a central party. (Besides being irrelevant, I fail to see why this is true)
Therefore, I come to my final conclusion:
**Username checks out.**
The OG Bitcoin business model is broken
In 2020, the FED prints 22% of all USD ever created. Clearly, the USD is headed for a big inflation. https://www.youtube.com/watch?v=r7GzaLROW0E
If people ask me what they should invest in, my answer, right now, is always: gold and silver.
But not Bitcoin, and not Bitcoin Cash, nor any other cryptocurrency.
Why not?
We’ve already had 11 years of Bitcoin, yet it and its forks by no means is a viable replacement of the best money ever created—the USD.
For non-tech savvy people, the USD is
**faster**, with credit cards and PayPal feeling instant,
**cheaper**, SEPA payments are literally free, for customers credit card and PayPal payments also feel free
and **more reliable**, as it’s backed by the government, quite stable, it’s basically accepted everywhere and there’s always someone you can call to get your transaction handled.
Bitcoin could have easily out-competed the existing traditional financial services, as the technology is vastly superior (UTXO based chains are actually really scalable), the big question though is: Why hasn’t it?
The answer, for me, is profit.
Or rather the lack thereof.
**There simply is no money to be made directly from replacing the USD with Bitcoin.**
So far, the OG “business model” for that has been: Buy Bitcoin, adopt/develop for Bitcoin, Bitcoin increases in value, profit.
Roger Ver, the first investor into Bitcoin startups and the most prominent supporter of Bitcoin Cash, is a proponent of this model. And that’s understandable, because this business model drove initial Bitcoin adoption. https://read.cash/@deadalnix/bitcoin-core-developers-do-understand-economics-f87cd400#comment-93862e65
But this is a really, really terrible business model. **It doesn’t work**. It suffers from the free-rider problem, it turns Bitcoin adoption into a public good. It’s basically the same model as one of those Marxist cooperatives, which always eventually fail. https://fortune.com/2016/12/12/michigan-marxist-vegan-restaurant-closes/
**It doesn’t matter whether you work hard or slack off in that model, you get the same reward**. Even worse, for Bitcoin, if you were not an early bird and didn’t get in early, you will profit much less than people who did get in early. So this way we basically remove all the future talent from the pool of people who would help replace the USD.
I will talk more on models that actually work in a future post, because I believe we can replace the USD quite quickly if we just adopt an incentive aligned model, but first let’s examine this one in more detail.
If we use the OG “Buy Bitcoin, Adopt Bitcoin, Profit” model, we artificially turn Bitcoin adoption/development into a public good. Right now, adoption/development is mostly done by people who selflessly approach businesses/write code (or are paid by selfless people, in form of donations). In return, the price of Bitcoin increases, and every holder, including them, profits. **But other than that marginal increase in Bitcoin’s price, they get nothing in return**.
That’s the mechanics of a public good.
There’s actually a way to make public goods work. Nobel prize winner Elinor Ostrom guides us on how to “govern the commons” with her 8 principles:
Define clear group boundaries.
Match rules governing use of common goods to local needs and conditions.
Ensure that those affected by the rules can participate in modifying the rules.
Make sure the rule-making rights of community members are respected by outside authorities.
Develop a system, carried out by community members, for monitoring members’ behavior.
Use graduated sanctions for rule violators.
Provide accessible, low-cost means for dispute resolution.
Build responsibility for governing the common resource in nested tiers from the lowest level up to the entire interconnected system.
If we go through that list, we quickly realize that **none** of them work for the OG Bitcoin business model, because it is a permissionless system. Just look at the first principle: Define clear group boundaries. How on earth should be we define group boundaries for Bitcoin? By definition, we can’t exclude anyone, because everyone is free to participate and there’s nothing we can do to stop them. And don’t get me started on the 6th principle.
It seems like the Global Network Council proposed by Bitcoin ABC to solve the funding problem of the public good “infrastructure development” is a good attempt at “governing the commons”, and the people designing the rules there should pay close attention to those 8 principles by Ostrom. It definitely fulfills some of those principles already, especially principle 1.
But back to the OG Bitcoin business model.
It means there will always be exactly two outcomes, after sufficient time:
**Selfless people will continue adoption/development or donate for it exactly until they feel exploited or burnt out and then leave in frustration**
**Someone else comes along with a sound business model and “takes over”**
And we’re seeing this over and over again:
Small blockers appeared on the scene in Bitcoin, presented a viable business model, Liquid, and eventually took over the entire chain while big blockers went onto their own chain, Bitcoin Cash.
In 2014, Dash came along with a viable business model, the Treasury, and took a lot of the peer-to-peer electronic cash people.
In 2015, Vitalik came up with Ethereum which presented a viable business model, the Ethereum Foundation, and took basically all of the people focused on smart contracts.
In 2018, Bitcoin SV came along and presented a viable business model, direct funding from miners, and took a good portion of the “data-on-chain” people.
In 2019-2020, AVAX is coming along and is presenting a viable business model, Ava Labs, and is taking a lot of people from the current Bitcoin Cash community which are focused on fast and reliable payments.
In 2020, Bitcoin ABC, the lead implementation of Bitcoin Cash, is coming along with a viable business model, the Global Network Council, funded by the Coinbase Rule. They aim to take all the people focused on peer-to-peer electronic cash. You can read my thoughts on their initial proposal here. https://read.cash/@TobiasRuck/why-i-support-the-ifp-despite-the-community-seeming-to-hate-it-and-how-to-fix-it-d128e975
A lot of people in Bitcoin Cash currently are unhappy with Bitcoin ABC and the Global Network Council, and want to continue with the OG Bitcoin business model, with a new node called BCHN. And it will be very easy to predict the outcome of that effort, given economic reasoning and historical precedent: People will either be burnt out and leave, or someone will come along with a viable business model and “take over”.
To make matters worse, a lot of prominent people supporting the OG Bitcoin business model are **actively hostile to the very idea of profiting off the protocol**:
Collin Enstad, host of the “Collin’ It Like It Is” show, in a recent video said “After November [...] Bitcoin Cash will continue its quest to peer-to-peer cash for the world as it sheds yet another team **who wants to use the protocol for their own profit**”. https://youtu.be/Xi2oxu1pOJ0?t=3m40s
Imaginary Username, author of Reusable Addresses, in a recent tweet said about Amaury Sechet, the lead developer of Bitcoin ABC: “How about ‘who wants to loot the protocol’?” https://twitter.com/im_uname/status/1304338187825807362
A similar sentiment is shared by many people who unironically call the Coinbase Rule a tax, proposing it is theft.
In other words, the very idea of replacing the OG Bitcoin business model is to be opposed.
This, of course, will end very badly. Either people will leave in frustration or people with a sound business model will take over.
How long will the wheel of death of the OG Bitcoin business model continue spinning?
Instead, we need to **embrace the profit motive**, and come up with business models that actually work, models that incentivize participants correctly.
Stay tuned for a future post about my thoughts on that.
Amaury doesn‘t get paid
grond! GROND! GROND!
My (Tobias Ruck) opinion on the DAA drift correction
I’m Tobias Ruck, CEO of be.cash, and recently there has been some contention on the DAA. Specifically, the drift correction, which makes sure that the coin emission eventually gets back on schedule.
Here’s my view on this matter:
I don’t give a flying fuck.
I’ll just focus on building and don’t want to waste my energy on something irrelevant like that.
That’s all, thanks for your attention.
Also check out be.cash, if you want to get one of those slick card for the upcoming crowdfunding. https://be.cash
Why I support the IFP despite the community seeming to hate it and how to fix it
Technically, I’m a Bitcoin ABC developer. I recently developed the OP_REVERSEBYTES opcode and it got added to the codebase.
One might say that’s a conflict of interest and would make me biased towards ABC, however, as I didn’t take any money for my work, I believe the opposite is true: I know how ABC devs work, their rigor and practices while I’m also not getting any money from the IFP. And I don’t intend to, as I want to work on different projects instead, like be.cash and Mitra.
So far, I’ve only voiced my opinion on the fund in a handful of Tweets and recently told that I’d just work on NFC cards. Well I’m at the airport right now so the latter is probably not possible. It’s going to be a long flight so better set some time aside for reading this.
What I find fascinating is that on both sides of the argument, there are people I deem extremely intelligent, driven and passionate about BCH. How is it possible that people that agree on so many things, but diverge on this one issue so strongly? And one thing that has been even more startling to me, why are some people getting so emotional about this issue? Why are some just flat out insulting me directly, making a productive discussion impossible?
Recently, I had a private chat with a BCH node developer the other day whom I don’t want to reveal. He was supportive of the fund but didn’t want to voice the support too publicly, as he was afraid of losing face given all the vitriol of the side opposing the fund. If the climate regarding the fund is that bad, there’s something wrong going on.
I also had a chat with Vin Armani about the IFP the other day. I explained to him, I’m not a contrarian. I’m actually very agreeable (too much you might say) and always eager to get along with people as good as possible. I told him it’s quite surprising to me as to why I would be in favor of the fund while most people around me seem to be against it. He suggested that since I founded be.cash, I now have an increased time horizon, he compared it to having a child. That this changes one’s perspective of the world.
Maybe that’s the case, maybe not. I **have** to be on the “right” side of this issue, this project is my full-time job now. If I get it wrong I’m set back a lot of years a hundred of thousand dollars of opportunity costs.
And there is a large number of concerns and questions, some of them of them valid, some of them less valid:
It is a tax!
It’s against the whitepaper. It clearly states that all incentives should go to the “creator of the block”.
It creates a powerful entity that can arbitrarily dictate the course of Bitcoin Cash
Amaury is a huge fils de pute and can suck my bits
Amaury is a bad project leader and very wasteful with the resources his team has been given. Code reviews are late, he’s demoralizing his developers and the mood is bad
If there’s an infrastructure development fund, why is there no marketing/adoption fund (similar to DASH)? A chain without usage is useless regardless of infrastructure development
This will be a slippery slope towards changing the protocol arbitrarily; who will prevent Amaury from changing the 21’000’000 BCH inflation schedule?
Changing the coin issuance will be really bad optics, just imagine BTC did this
Should BCH‘s distribution be redirected to Warren Buffett if he promises to help promote it?
What hashrate of all SHA256 miners is pro/neutral/against the fund, as they are the ones paying for the fund?
How will miners against the fund respond to having a percentage of their income redirected to BCH devs?
How can accountability be established for the funded projects?
Why can’t development not be funded by donations instead of the IFP? For example, via an assurance contract. Holders benefit more than miners from a price increase therefore it would be natural for them to fund the development.
Satoshi worked for free, Amaury can work for free. If he doesn’t like it, others will take on that burden.
Nakamoto Consensus is nice and well but most miners and exchanges just follow the code ABC releases anyway without changing any defaults.
BIP9 (miner voting) doesn’t work because Calvin and other adversarial miners will just cause trouble by voting maliciously
The proposal is very contentious and will likely cause a split; the crypto community is already fractured enough
Bitcoin Verde is not on the whitelist
The requirement for a project to be “in need of money” incentivizes developers to pretend to be in constant need of money, making sure they always spend all the money regardless of whether that’s actually needed. It’s also unfair to projects who aren’t in need of money.
I believe anyone agrees with at least one of the points or questions above, at least I do. If you do, too, this article could be very interesting for you.
A tax?
Before we get into why I support the proposal, let’s first get the terms straight. I believe calling the IFP a tax commits the logical fallacy of begging the question by using a loaded term. Let me explain why I think this is the case.
I’ve posed the following question on Twitter: “anyone can explain to me how the IFP is a tax but a minimum transaction fee isn’t?”
Interestingly, I got about a dozen of different reasons! Many of them directly contradicting each other:
It’s not a tax, it’s just an easy metaphor that everyone knows
Miner policies are voluntary, consensus rules are coercive
Both are a tax; fee = tax
Both are *like* a tax but not in the strictest sense of the word
Anyone can collect transaction fees, only a few specific people can collect the IFP
The IFP is central planning; projects funded by taxation are too. Minimum transaction fees are not central planning
Infrastructure development is too broad of a category of work, which is also true for projects funded by taxation, transaction fees are not
Orphaning blocks is like burning down the proof-of-work of miners and thus coercion
The IFP is theft as it’s taking something that doesn’t belong to them.
If the IFP really is a tax, then why are the many reasons for this argument so clearly divergent and contradictory? Intuitively, this reeks of backwards reasoning: You’re already convinced of X and you‘re then coming up with reasons why X is true, which often results in widely different assumptions—which in turn often lead to conclusions even the proponent would deem incorrect.
Instead, we should start with assumptions and argue from there. If our assumptions are considered true by all parties and every logical step made is valid, we have arrived at a conclusion that must be considered true by all parties.
Let us do just that and see where we arrive.
What is a tax? Usually, it’s only used in the context of governments, but for this argument we can relax that definition to the following:
A compulsory contribution to some entity.
Compulsion in this argument doesn’t have to be violent, it could also be by someone not having access to a private key or something along those lines.
What is the IFP? In short, it enforces a certain list of addresses to which a fixed percentage of the coinbase output has to be sent to. This is ensured by orphaning blocks that don’t follow the rules of the IFP.
But what is orphaning? Technically, it’s when a miner node rejects an incoming block from another node and doesn’t include it in the block header of the current block he’s solving. The whitepaper explains it in the conclusion: “They vote with their CPU power, expressing their acceptance of valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them. Any needed rules and incentives can be enforced with this consensus mechanism.”
This mechanism is also known as Nakamoto Consensus. Generally, any divergence in consensus creates a fork so that one set of nodes follow one chain of blocks and another set of nodes follow another chain of blocks.
Is orphaning blocks compulsion? Even using the very relaxed definition above, orphaning a block is not compulsion, as it merely is refusing to perform work on top of a different block.
An analogy would be when a girl asks me out and I decline (although the reversed situation would be more plausible). She might claim I forced her to spent the day alone by rejecting her invitation, but this is not the case, as she could just go on a different date. Similarly, just because my node rejected your block, this doesn’t mean no other node can accept it.
Equally, even if she put a lot of work into her invitation, that wouldn’t change the fact that it wouldn’t be compulsion for me to reject her. Similarly, just because a node spent a lot of electricity working on a block and my node rejects it, that wouldn’t make it any more or less compulsory.
In the same vein, if I tell her beforehand that I will only go on a date with her if 5% of our expenditures go to my friend Amaury, this too will not make it compulsion.
Similarly, the IFP is not compulsive. It’s not a tax.
What about “The IFP is *like* a tax”? Well, that’s perfectly fine. My brother is like me. We’re quite similar actually. But does my grandmother call my brother ‘Tobias’? No, because we’re not the same person. Similarly, just because the IFP and a tax have some commonalities, it wouldn’t be fair to call the IFP a tax.
Unless, of course, “tax” obtains a new meaning, which presently isn’t the case.
Nenn mich “Fee”, Baby
I hope I’ve been able to make clear why I don’t think the IFP is a tax. Instead, I suggest calling it a *fee,* which is much more accurate. Users ask miners for confirmations of their transactions, therefore they pay a transaction fee to miners. Miners need infrastructure to run the network, therefore they pay an infrastructure fee to developers to develop infrastructure.
I would be less insistent on refraining from calling it a tax if the word wasn’t so emotionally and ideologically charged. It would be like when socialists insist on calling a business owner’s profits “exploitation”—how could you support exploitation, hence, how could you support free enterprise?
More so, a good portion of Bitcoin Cashers are libertarians, which includes me, which consider taxation to be theft and immoral. Suggesting that libertarians in favor of the IFP are supportive of something they themselves abhor, is a cheap and very unconvincing way of arguing against the fund and just guarantees people to get angry, which empirically is the case.
It’s using a loaded term and begging the question, which is a logical fallacy where you assume the conclusion. The conclusion here is whether the IFP is bad, the assumption is that IFP=tax.
Some people actually get annoyed when I point out this error, calling it “focusing on [semantics]”. However, what is the point of a debate if one side has permission to just commit a logical fallacy?
Ex falso quodlibet—from a false assumption we can derive any statement we like. It is therefore paramount to get our terms correct, otherwise we can end up at completely incorrect conclusions.
There are some people who instead of calling it a tax moved on to calling it “not-a-tax”. I appreciate the sentiment of this, but hiding a fallacy behind sarcasm doesn’t make the fallacy disappear. Intuitively, it also appears pretty childish to me.
Now that the discussion has become even more charged, it’s hard for me to differentiate between trolls trying to stir things up and people who are genuinely concerned but just use flawed terminology. Therefore, from now on, I’ll refrain from arguing with anyone who genuinely refers to the IFP as a tax and instead point them to this article.
And frankly, after thinking about the IFP a bit more, I figured that referring to it as a tax fundamentally rejects Nakamoto Consensus, the whitepaper and what I consider to be the spirit of Bitcoin. The final sentence of the whitepaper—“Any needed rules and incentives can be enforced with this consensus mechanism”—explicitly allows for the IFP, by changing the incentives if such a change is needed.
Holding onto the belief that Bitcoin‘s rules and incentives should never be changed out of principle is rejecting the foundations of Bitcoin. People are free to follow such principles, but they are not the principles Bitcoin has been built upon.
I’m not interested in convincing someone that the IFP is good for Bitcoin if they don’t believe in Bitcoin.
Principles
Thinking about it some more, I figured I should first establish what my own principles actually are. During my time off from developing which I spent in Acapulco and while being 10’000 ft above the ground, I had some time to reflect on my principles. What are the principles that guide me? And most importantly, does the IFP naturally follow from those principles?
Those are the principles I found which are relevant here:
Truth
Individualism
Selfishness
Meritocracy
Paying for what one values
Let me go through them one by one to explain what I mean with each.
Truth
This is my foundational principle. It’s a very tough standard—it‘s very hard to overcome ones biases, drives and emotions in the face of truth—but the only one I can personally live by. I’ve broken up with girlfriends just because they’ve violated that principle. It’s the principle that got me into libertarianism and Bitcoin Cash specifically. It means that I will not speak untruth deliberately and that I will not refrain from telling the truth when it counts. Which is the reason I‘m writing this post.
Individualism
Other words for this would be ‘secessionism’ or ‘sovereignty’ and it’s very related to selfishness. It means I’m responsible for my own actions. It‘s the opposite of collectivism, where action should be taken as a collective, diverging from the group is seen as bad and the guiding principle is following “the greater good”. In the individualistic view, one is free to not comply and do one’s own thing.
Selfishness
This term carries a lot of negative connotation, however, it is still very important for me. Developers like me often get exploited by other people, which already happened to me. Now, I always ask “What’s in it for me?”. Being selfish means putting one’s own well-being first. This of course doesn’t mean one ought to exploit others, and usually that isn’t in one’s self interest anyway—as it burns valuable bridges.
Meritocracy
Meritocracy means those who provide merit are in charge. It means decisions in a project are not made by majority vote but instead by the accomplishments one has made in the project. Rust, Linux and many other successful open source projects use this mechanism. Also, it’s the foundation of capitalism.
Paying for what one values
I don’t know if there’s a word encapsulating this principle, but in short, it means deliberately paying when one received good services and goods. If I get a convincing and friendly sale, I’ll gladly buy the product and pay for it. If I get good service, I’ll gladly pay a good tip. If a content creator creates good content, I’ll add them to my Patreon or buy their merch.
Bitcoin is an expression of all of the above principles.
It enforces truth by everyone being able to see the entire blockchain and verify for themselves the validity of the chain.
It allows individualism via censorship resistance: Anyone can send money to anyone on the whole planet and there‘s no “collective” that could stop it, as miners are in competition with each other. Bitcoin and collectivism are incompatible.
Bitcoin embraces selfishness as a virtue and turns it into a well functioning economic system by aligning incentives of miners. It doesn’t force or compel anyone to share their coins with anyone.
In the blockchain world, meritocracy is called Proof-Of-Work. ASIC mining—the number of leading zeros—is a good measure for Proof-Of-Work. Proof-Of-Stake is a good proxy for that, less so, though, as it doesn’t mean continuous investment. Development is also meritocratic, if you produce good code and products, you‘ll automatically gain influence.
Bitcoin Cash currently also enforces a transaction fee. If you want to make a transaction, i.e. if you value it, you pay for it.
So far I’ve established why the IFP is not a tax and I’ve explained my principles and how they relate to Bitcoin.
Is the IFP consistent with my principles and might it even follow naturally?
Obviously, just because the IFP is not a tax that doesn’t mean it’s a good idea. Therefore, I will be making the following arguments:
A coinbase output as part of consensus is a natural way of funding infrastructure development
Bitcoin ABC and BCHD are ideal recipients of such a fund
Along the way, I will make a couple of suggestions how the fund can be improved to be more in line with what I think is the spirit of Bitcoin.
One: A coinbase output as part of consensus is the natural way of funding infrastructure development
When thinking about the problem for a minute, one comes up with a myriad of ways different from the IFP how one could fund BCH‘s developers, for example:
Devs just work on their free time without getting paid
Devs get paid by miners directly
Community donates to the devs
Devs provide support for their software, Red Hat style
Establishment of a Bitcoin Cash Foundation, Linux Foundation style
The first one empirically doesn’t work in practice (see most other chains, e.g. Litecoin) and violates the “Paying for what one values” principle. For most people, this sounds like a crazy proposition, but there are actually some Bitcoin Cash supporters that hold this view.
The second one is the one propelled by BSV. If I understand it correctly, miners basically hire developers to write the software for them. Of course, it‘s obvious that this is only a good option if there‘s only a handful of miners (ideally, 1) and if they make massive profits to allow the waste of having different developers working on different implementations. Also, it would be more efficient for miners to form a cartel and pool resources to fund common infrastructure.
This is also how infrastructure has been funded in the past on BCH. In the recent developer meeting, Amaury explained that it‘s been miners, especially those behind the IFP, that have funded ABC so far. However, they are only a subset of miners on BCH. All other miners—often switch miners—aren‘t funding the developers and are basically free-riding. As they don‘t want free rider miners to mine on BCH anymore, they‘ve proposed the IFP.
The third one is sound and consistent with my principles. I really hope the infrastructure can be funded this way. However, my principle of truth also includes empiricism and empirically, BCH would be the first cryptocurrency that would be funded via donations successfully. There have been multiple attempts at this, for example Lighthouse, which didn‘t really take off. There‘s been a recent renewed attempt at this with Flipstarter. It is unclear to me as to why this renewed attempt should succeed while previous ones failed. The arguments I‘ve heard have not been convincing. I still hope it will come around and succeed this time. However, following the principle of truth and empiricism, I cannot just dismiss the past failures of equivalent projects.
Other ways for funding via donations would be for wallets to integrate an additional fee output to the developers, or to make some ritualized event where all holders are asked to kindly pay a certain percentage of their holdings to the developers. Maybe generous donors could be added in a Hall-Of-Fame or something. I think it would be a great idea if we could establish a culture that would partake in such events.
imaginary_username has done an excellent analysis of the dynamics and economics of holder funded development (https://read.cash/@im_uname/assessment-and-proposal-re-the-bitcoin-cash-infrastructure-funding-situation-3e5179fc). Empirically, I don‘t think infrastructure development correlates as clearly with price increase as is insinuated in the article, but I agree with the sentiment.
Given that there‘s a new Bitcoin Cash Node that has forked from ABC just recently, it would be thoroughly surprising to me if both the development of ABC and the BCN can be funded via donations, or even just one of them. It seems like a very short-term solution.
The last two solutions are both economically sound and work empirically. Amaury himself suggested that we should establish some form of foundation that‘s modelled after the Linux Foundation. However, I don‘t believe the ecosystem is yet mature enough to support either of those models. While doing everything in our power to emplace a foundation or a Red-Hat-esque support model, in the meantime, we need a different and temporary solution for funding.
IFP
This is where the IFP comes in.
In short, it adds a new consensus rule to Bitcoin Cash, namely that a certain percentage (in the most recent proposal, 5%) of the coinbase must be sent to one of the addresses of a whitelist of projects.
For some, the idea of miners funding infrastructure development via consensus in any shape or form seems to be against perceived Bitcoin principles. I don‘t think this is the case. While the whitepaper does say “the first transaction in a block is a special transaction that starts a new coin owned by the creator of the block”, which for some appears to be a rule that shall never be broken, it is referred to as a “convention”. In fact, the coinbase reward is an “incentive for nodes to support the network”. It‘s not a dogmatic rule but a practical rule that has a reason to be in place.
What is this reason? The reason is that without miners, the network would not function, as nobody would voluntarily waste resources on mining blocks and transactions would not be secured.
The same reason also applies to infrastructure development. Just as miners wouldn‘t want to waste their time and money on securing the network if they wouldn’t get paid, developers also wouldn’t waste their time and money on securing the network if they wouldn’t get paid.
The concluding statement of the Bitcoin whitepaper clearly allows for a consensus enforced developer fund: “Any needed rules and **incentives** can be enforced with this consensus mechanism.”
It specifically mentions incentives.
Of course, the question is whether those incentives are actually needed. This clearly is the case if infrastructure development cannot be funded in other ways.
Public Goods
Now wait! What about all the other stuff that’s important for Bitcoin Cash, like merchant adoption, wallet development and advertisement? What‘s the point of a highly secure and safe network if no one uses it?
The difference is that all of those things can be done by a profitable business. As I‘ve outlined above, infrastructure development can’t really be done by a profitable business, except in e.g. the Red Hat model above. However, merchant adoption, wallets and advertisement are *already* today being done by profitable businesses, most notably Bitcoin.com. I hope more businesses will follow and I hope that my own business, be.cash, will be one of those that spread adoption and awareness of Bitcoin Cash.
That’s why ABC’s proposal specifically limited the addresses to those that are to be considered “Public Goods”.
Whitelist
The IFP enforces a specific whitelist for a fixed set of allowed addresses. Many are supportive of the idea of the IFP, but also think this whitelist is against Bitcoin‘s principles. I don‘t think it is—for Bitcoin Cash specifically.
Practically speaking, the whitelist is up for a vote (at least) every six months. Given that Bitcoin Cash is supportive of frequently changing the rules of the network, I would be thoroughly surprised adding or removing projects from the whitelist wouldn’t be strenuously debated each hardfork. Even the benign change of my opcode—OP_REVERSEBYTES—has caused quite a lot of (mostly productive) debate.
The community and ultimately the miners will come to a consensus which projects should be added or removed from the whitelist, developers will update the whitelist and miners will then enforce said whitelist.
Some members of the community are afraid some form of government could form around the IFP. “What happens when this government is targeted by one or more national governments […] that are x100 size and influence?” one tweet says.
I don‘t think whatever entity will emerge (if any) will have similar powers like a government. My fear is actually the opposite: That there will be so much debate around the whitelist that it will cause a lot of contention and that achieving consensus on the whitelist will be prohibitively difficult. Especially since getting on the whitelist will be a big privilege to have. Miners will still have to choose which project they actually want to support, so getting a project erroneously on the list or one that later turns out to be not a good idea can be avoided by miners simply not sending any money to the address.
To avoid any of these issues I believe we will need three things for the IFP to function, which presently don’t exist yet:
Some form of Bitcoin Cash Manifesto, which lays out clear and concise principles of Bitcoin Cash (similar to how I’ve laid out my principles in this article). I’m sure there are numerous sources to draw from, but one has to be very careful about which principles to include and which to omit. If the principles are inconsistent, it will make the whole thing useless.
A clear set of conditions a project on the whitelist has to fulfill. There currently exists such a list for the IFP, but it seems too arbitrary, relaxed and over-inclusive. It also isn‘t very convincingly written, not very precise and doesn‘t define its terms well.
An independent set of auditors. These auditors can be volunteers from the community or funded by third parties. It‘s an open group, anyone can become an auditor. It should be a community effort. They will keep the projects on the whitelist accountable to the whitelist conditions, gather metrics regarding the projects’ performance and productivity and uphold the principles of the manifesto. If they violate any of the conditions or principles or don’t show sufficient performance, they will first be removed from the list miners choose from and subsequently removed from consensus.
All projects publish the development history (i.e., amongst other things, the git history) of the developed code, with accurate timestamps. This already is the case today anyway so it wouldn‘t change anything about how developers operate. Based on the development history, auditors can see the progress and performance of the project. Are many tickets closed? Are the made changes necessary and are they clean? Is there time wasted on vanity changes or instead spent on useful refactoring? What new features are added? Do benchmarks improve over time? Can the software process more transactions now?
I do believe that this mechanism will both be efficient and effective. It is *principles* based and doesn’t add unnecessary overhead for developers. Developers will have to answer more questions about their work than before, but that is the price that is—and should be—paid for receiving funds via the IFP.
For me, it seems like ABC didn’t make it’s due diligence when coming up with the IFP implementation that’s now part of the ABC code, which is also reflected in the fact that no miners are signalling for the change: https://bitcoincash.network/voting/
The conditions for the whitelist seem sloppy and too lazily established. Why are those conditions there and what underlying principle do they it serve? What is the “General Fund”? What does “in need of money” actually mean and on what principle is it based? ABC needs to pay a bit more attention to these questions.
I think miners would be very grateful for having a whitelist of projects that has been properly audited and based on principles they agree with. They would have the certainty that their investment is in good hands.
Such a modified IFP would be d‘accord with all of my principles:
Truth: It would establish clear rules and principles and anyone can verify they are actually upheld. It embraces discussion and scrutiny.
Individualism: Everyone has a chance of getting on the whitelist and the rules are clearly defined. The whitelist itself is enforced by Nakamoto Consensus and ultimately, anyone is free to choose a different chain.
Selfishness: It allows BCH-supportive miners to follow their own self-interest. Currently, they are forced to be altruistic and have to accept that a certain percentage of their money goes to fund developers despite all miners benefiting off it.
Meritocracy: It financially rewards projects based on merit and what they‘ve accomplished so far and it punishes wastefulness.
Paying for what one values: Infrastructure development is valuable and the IFP makes sure it is paid in exchange of a relatively small reduction in PoW security.
Two: Bitcoin ABC and BCHD are ideal recipients of such a fund
Now, we haven’t established the principles that will be used for such a whitelist yet. However, we can use my principles from above for now.
There are numerous projects that could need funding. As established previously, I don‘t think wallets should be included in this list, as they can (and often are) funded by a profitable business. This means Electron Cash cannot be included in the list.
What about node implementations?
The only notable ones are the following ones:
Bitcoin ABC
Bitcoin Unlimited (BU)
BCHD
Bitcoin Verde
Flowee
BU already has sufficient development funding, but more importantly, funding BU via a development fund would violate my principles of truth and meritocracy. Joannes Vermorel in his recent blogpost writes the following (https://blog.vermorel.com/journal/2020/2/21/abc-is-bitcoins-biggest-asset.html):
“Bitcoin Unlimited (BU) has abysmal development practices, and keep misleading the community about the ‘grand’ features they have delivered. This team has zero clue on how software is supposed to be engineered. By way of anecdotal evidence, this recent commit merged into the master branch: 267 changed files with 18,311 additions and 4,526 deletions. For infrastructure code, this is beyond amateurism, this is madness.”
If BU doesn‘t improve on its rigor and professionalism, to include them on the whitelist would be a violation of my principles. In fact, due to bugs in the creation of block templates, some miners have lost a good portion of money already (https://bitcoinist.com/bitcoin-unlimited-bug-miscounting-bytes/). Development practices should be rectified and improved regardless of the fund. If this would be the case already, there‘d be no funding problem in the first case.
Neither Bitcoin Verde and Flowee show up on any node explorer that I could find, which made me conclude that the node share must be relatively small. Bitcoin Verde has made laudable process over the time and I‘m almost certain that the project would eventually be included in the whitelist once its significance rises even more. However, as it currently stands, the merit of both Bitcoin Verde and Flowee does currently seem too small to warrant an entry in the whitelist.
BCHD, on the other hand, is used quite frequently when looking at the node count, and its code follows professional software practices. Going through the code myself, it was very easy to find the functions I was looking for and even make debug modifications myself, despite never writing any significant Go before. If I recall correctly, it is used by CoinText and a lot of other projects due to its easy-to-use nature. In my view, it provides sufficient merit to be included in the whitelist. This of course depends on the actual conditions that will be established for the whitelist.
Now, finally, Bitcoin ABC.
There‘s been a lot of misinformation going around Bitcoin ABC. People are claiming things are not getting done, reviews remain unreviewed for a long time and morale is down.
All of that due to Amaury Sechet, of course, who apparently is a terrible leader. Now, I do agree that some of the public communication done by him has been very questionable and, to put it kindly, a bit too French. Some of his attacks on BU seem undiplomatic. Justin Bons calls the IFP a “clear failure of leadership [...] since it is [severely] lacking in political & diplomatic sensitivity”.
However, given that the communication by other members of the community has been even worse and sometimes flat-out insulting, his behavior can be excused to some extent. And he definitely is aware that some of his communication style should be improved.
And yes, he can be harsh in reviews, albeit so far this seems fully warranted:
And when you break the code and don‘t reply for six hours (I was 10’000ft above the ground), he does get a bit annoyed:
However, at least in my communication, he‘s usually a lot of fun and very supportive:
Now, your interaction with Amaury might be entirely different and likely is, but this is just my subjective view. He puts very high standards on all changes to Bitcoin ABC, even requested an unrelated refactoring to happen to make the code for the OP_REVERSEBYTES activation clear enough.
Everything about dealing with Bitcoin ABC feels extremely professional. This shows in their track record, historically, there have been only very few significant bugs and all of them have been fixed pretty much immediately. Most notably, the inflation bug found by awemany has been handled even more professionally than by Bitcoin Core, which have a reputation for having excellent coders.
Also, Bitcoin ABC was solely responsible for the inception of Bitcoin Cash.
It should be crystal clear that they’ve provided enough merit to warrant an entry in the whitelist.
Conclusion
I hope I was able to make clear why I do support the IFP and why it aligns with my principles. Regardless, creating some form of manifesto would be a good idea in my opinion.
I further hope this article will be used as a basis for a friendly and productive discussion.
If desired, I can provide beer and pretzels.
Why Mises would love Mitra; Bitcoin Cash‘s hidden superpower that even Ethereum 2.0 doesn‘t have
*Note: I renamed Nimbus, which I‘ve presented in Australia during the developer congress on the Bitcoin Cash City conference and made a video based on that, to* ***Mitra****. Nimbus is already a term used for a lot of things, including an Ethereum 2.0 node. It‘s very confusing. From now on, I‘ll refer to the new transaction version for Bitcoin Cash as Mitra (pronounced “meetrah” for simplicity). Mitra a word from Indo-Iranian mythology and means “covenant, treaty”. Therefore, I think it‘s a great name for a protocol change that‘s primarily about smart contracts and covenants. It‘s also easy to pronounce.*
Bitcoin Cash has some big advantages over Ethereum.
Unfortunately though, it‘s currently not living up to its full potential.
And let‘s face it: Bitcoin Cash just doesn‘t have the same momentum, capital and brain power that Ethereum has.
Yes, *of course*, Bitcoin Cash is much cheaper than Ethereum for simple transfers, but it‘s Ethereum where all the cool stuff is happening.
And yes, maybe financial stuff like prediction markets, synthetic assets and tokenization of securities, or even apparently silly stuff like CryptoKitties, Gods Unchained and My Crypto Heroes don‘t immediately seem relevant for the “cash” use case of Bitcoin Cash.
**But Ludwig von Mises would disagree.**
I recently re-read this amazing piece by Jeffrey A. Tucker (https://fee.org/articles/what-gave-bitcoin-its-value/), where he explains how on earth Bitcoin can have any value.
It‘s a difficult question, because von **Mises‘ theory of money would naively predict that Bitcoin couldn‘t have any value**. I highly recommend reading the article, it‘s just amazing that this has been written way back in 2014. In the article, Tucker quotes von Mises:
*The theory of the value of money as such can trace back the objective exchange value of money only to that point where it ceases to be the value of money and becomes merely the value of a commodity…. If in this way we continually go farther and farther back we must eventually arrive at a point where we no longer find any component in the objective exchange value of money that arises from valuations based on the function of money as a common medium of exchange; where the value of money is nothing other than the value of an object that is useful in some other way than as money…. Before it was usual to acquire goods in the market, not for personal consumption, but simply in order to exchange them again for the goods that were really wanted, each individual commodity was only accredited with that value given by the subjective valuations based on its direct utility.*
In other words, **money must be used as something that‘s useful before it can be used as something that‘s a medium of exchange**. Tucker writes:
*Would salt have become money had it otherwise been completely useless? Would beaver pelts have obtained monetary value had they not been useful for clothing? Would silver or gold have had money value if they had no value as commodities first? The answer in all cases of monetary history is clearly no.*
*[...]*
*At first glance, bitcoin would seem to be an exception. You can’t use a bitcoin for anything other than money. It can’t be worn as jewelry. You can’t make a machine out of it. You can’t eat it or even decorate with it.*
Tucker then goes on how the fact that Bitcoin was able to acquire a price and (back then) be used as money was puzzling him “for more than a year”. At some point, he realized:
*Bitcoin is both a payment system and a money. The payment system is the source of value, while the accounting unit merely expresses that value in terms of price.*
**Bitcoin (the network) can be used to do payments—that‘s what makes it useful, and that‘s what gives Bitcoin (the coin) its value**. It‘s a great insight, probably the most important insight of all of cryptoeconomics.
Bitcoin Cash and Ethereum
**Justin Bons**, a great thinker of both the Ethereum and Bitcoin Cash community, recently said this on the Humans Of Bitcoin podcast (https://podcast.bitcoin.com/e865-A-Crypto-Fund-With-0-BTC-Justin-Bons, 20:55):
*Aaron: How do you see [Bitcoin Cash and Ethereum] coexisting? What purposes do you envision them serving in the future from a utility standpoint?*
*Bons: Now, I will say that* ***Ethereum and Bitcoin Cash are direct competitors****. And this is maybe not the most widely held opinion, but I very much do see Ethereum, especially in its later planned iterations, to be a very good, you know, form of currency and store of value. I‘ll say this: Ethereum is the real Bitcoin. I can say that. If we‘re talking about vision and intent.*
Justin realizes that Ethereum can be just as good money as Bitcoin Cash aspires to become. He later points out that both Ethereum and Bitcoin Cash have different engineering tradeoffs, and that given this differentiation, there will be a world with Ethereum and Bitcoin Cash coexisting, as competitors.
**Vin Armani** said this in a recent CoinSpice podcast (https://www.youtube.com/watch?v=pXW0DOb-ZqI, 59:30) regarding SLP tokens:
*Satoshis are a commodity. They‘re the oil of Bitcoin. [...] That‘s gonna be hard for people, you know, there‘s plenty of people who have wanted this to be money. But, like, it‘s not gonna be. Not at first. It‘ll be oil. Maybe someday it‘ll be money after it‘s been oil for a while, you know, after it‘s been a commodity for a little while.* ***Maybe someday it can be money, but it‘s gotta be a commodity first.***
If oil wouldn‘t be so stinky and hard to transport and store, it would be a great money. Bitcoin Cash or Ethereum, before it will be used as money by a great number of people, must first go through the same process that cowries, salt, copper, silver and gold went through. All of them have been commodities first, and very useful commodities. And only after that they‘ve become a unit of account and money.
Many people believe Bitcoin Cash is already money and they‘d like to skip the commodity step, but this is not how the real world works. Bitcoin Cash also has to go through that process.
It first has to become very useful.
**But we know Ethereum is objectively more useful than Bitcoin Cash, currently.**
This is just a fact.
What are the things you can you with Bitcoin Cash? Well, you can spend it at a few merchants, that‘s cool, but in no way unique. I can do that with my credit card, too, at more places, more reliably, faster, usually for a lower price (as customer). I can use Bitcoin Cash to send money over the internet, but, well PayPal already allows this at more places and sometimes is even cheaper than Bitcoin Cash. The only part where Bitcoin Cash actually is better than other established solutions is for sending payments trustlessly, pseudonymously and uncensorably.
Now to Ethereum. It allows something far more powerful than trustless, pseudonymous and uncensorable payments, it allows trustless, pseudonymous and uncensorable *computation.* Back in 2014/2015, Vitalik knew that‘s where the true potential of blockchain lies. He isn‘t just a genius in computer science and cryptography, he‘s also an expert in economics, which shows in the fact that a large portion of his writing is about economics. Ethereum solves problems for which traditional solutions are much more expensive and less reliable than even the relatively expensive Ethereum now. **It allows decentralized finance, which, currently, is much more useful than mere payments**.
And Ethereum is getting more and more useful. Right know, you can even do completely anonymous payments *AND* computation using zero-knowledge proofs.
Yes, the average Ethereum transaction is more expensive than the average Bitcoin Cash transaction. However:
For many financial applications, paying a dollar or two is not at all an issue—often that‘s actually very cheap.
Credit cards usually have still higher fees, so Ethereum‘s ~10¢ is still competitive compared to credit cards for any payments above $10.
ZK Sync allows cheap off-chain—and private—payments using zero knowledge proofs (https://medium.com/matter-labs/introducing-zk-sync-the-missing-link-to-mass-adoption-of-ethereum-14c9cea83f58).
Ethereum 2.0.
The last part—Ethereum 2.0—should be the most disruptive, and the Bitcoin Cash community should keep a close eye on it. It would allow even more applications on Ethereum, and much cheaper and efficiently than is currently done, due to multiple reasons, including:
**Proof-of-stake**, which requires less energy/money than Proof-of-work.
**Sharding**, which allows the spreading-out of workload, thus lowering the hardware requirements to validate transactions.
**ewasm**, a variant of WebAssembly, which allows contracts to be compiled into efficient machine code.
Given all this, we, first, should expect Ethereum to become even more useful and, second, we should expect transaction fees even for the money use case to drop significantly on Ethereum.
Ludwig von Mises, if he were alive today and were to understand the tech, would predict Ethereum to become much better money once Ethereum 2.0 gets enabled than Bitcoin Cash. Ethereum would just be so incredibly useful, while also having all the great traits of Bitcoin Cash. Also, keep in mind that Ethereum is able to “stabilize” ETH‘s volatility with MakerDAO, and volatility is one of the biggest issues facing cryptocurrencies.
However, **Bitcoin Cash is simpler than Ethereum**. Everyone who‘s been in the space for a bit knows that Ethereum has some issues with scalability that Bitcoin Cash doesn‘t seem to have.
Why is this the case? There‘s three things that Bitcoin Cash has that Ethereum doesn‘t:
Longer block times (10 minutes vs ~17 seconds)
No invalid transactions
No metering required
Stateless & deterministic transactions
Longer block intervals allow higher throughput: High orphan rates incentivize centralization, and long block intervals reduce orphan rates. This requires high mempool syncronicity to work well, but with similar miner policies, and with Avalanche in the works, this is already being developed.
Additionally, **in Ethereum,** **invalid transactions are also mined on chain**. This is a sort-of spam protection: Senders still pay the transaction fee, even if their potentially very costly to (in)validate transaction fails. However, this also means that even invalid transactions have to be verified to *actually* fail by all nodes. Bitcoin Cash just rejects invalid transactions and bans nodes that repeatedly relay invalid transactions—but after that, it‘s game over for an invalid transaction. It‘s only validated by the few nodes that had the peasure of seeing it, but no more than that.
On top of that, Ethereum also requires *metering.* This means, when evaluating an Ethereum contract, every instruction also needs to keep track of how expensive the contract has been so far. If the contract runs over the gas limit, it will cancel the execution. **All of that isn‘t required for Bitcoin Cash**. Instead, a node can calculate beforehand if a contract runs into the opcode limit—it just counts the number of opcodes in the contract. If the number exceeds the opcode limit (currently, 201), the transaction is rejected.
The biggest advantage, however, comes from the fact that Bitcoin Cash‘s transactions are both stateless and deterministic, whereas in Ethereum, that‘s not the case, until the transaction is mined. In Bitcoin Cash, a transaction has a fixed outcome and a miner basically just puts their “stamp of approval” on it. On Ethereum, however, a miner actually executes the transaction and *that* determines the outcome.
**This means that miners usually have to run a transaction twice**: Once to create their block, and once to validate blocks from other miners. Among other reasons, this is due to opcodes such as COINBASE, which returns the address of the current miner, TIMESTAMP, which is the Unix timestamp as (subjectively) perceived by the miner, but also due to the fact that calls to contracts aren‘t ordered and a miner has to determine an order, which could change the outcome.
In other words, the transaction‘s outcome is unknown until it has been mined into a block.
This is actually a really big issue for Ethereum. Just put yourself into the shoes of a miner. You‘re receiving a block and you have no idea if the transactions have been executed correctly. You need to run every single transaction once again (except for some special cases) to verify the block.
**But: all of that while your ASICs are still mining on top of the previous block.**
So blocks can never take more than a fraction of a second to verify the entire block, otherwise we would have orphans every few blocks. The CPU time used to validate a block, economically speaking, is more valueable than the time before that, because it could mean you‘ll mine a block that will be orphaned right from the start.
The people behind ewasm assume that contract execution of a block may take up to 0.5s of the 15 seconds block time (https://ewasm.readthedocs.io/en/mkdocs/determining_wasm_gas_costs/). There have been some ideas of stateless clients for Ethereum 2.0 (https://ethresear.ch/t/the-stateless-client-concept/172), but from what I can see this ‘only’ optimizes execution time and doesn‘t eliminate it.
On Bitcoin Cash, however, transactions are both stateless and deterministic, except for double-spending.
**This is where Bitcoin Cash shines**. It allows both fully parallel verification of all transactions (see https://blog.vermorel.com/pdf/canonical-tx-ordering-2018-06-12.pdf), and transactions only have to be validated once, after that, they remain valid forever (unless double-spent).
If a Bitcoin Cash miner already knows all transactions in a block, the only thing they have to verify is whether a block contains any double spends, which—with CTOR—is very well researched by computer scientists and can be done exceptionally fast.
**Bitcoin Cash is much more scalable than Ethereum**, even with Ethereum 2.0, because all that I‘ve told you above about Ethereum will generally still be true for Ethereum 2.0.
Now here comes Mitra (which up to this point I have referred to as Nimbus in my tweets and videos) and shamelessly exploits the properties of Bitcoin Cash that make it so scalable, to amp their capabilities to the max and create something that I believe **can compete with a big chunk of use cases of Ethereum**.
I know this is a bold claim. But let me explain.
First of all, what is Mitra?
Mitra is a (still very much WIP) proposal to change the consensus rules of Bitcoin Cash to add a new transaction format. I‘ve already made a video explaining some of the ideas behind it in a video on my channel, where it‘s still called Nimbus:
https://www.youtube.com/watch?v=vI2JecWwYiA&t=909s
This new format would allow the following things:
**On-chain games**. Rules of the game are enforced by the smart contract.
**Native tokens**, i.e. token rules are enforced by a smart contract, similar to ERC-20 tokens.
**Decentralized exchanges** (DEX).
**Advanced wallets**, much more capable than what is possible now (recurrent payments, auto-shuffling, last-will clause, etc. all in one wallet, ran automatically, non-interactively).
**Decentralized autonomous organizations** (DAOs), which make decisions autonomously. MakerDAO, a decentralized stablecoin that ensures the price of a token stays at $1 using smart contracts would be a complex example, but there are simpler ones.
**Zero-knowledge proofs** like zkSNARKs or zkSTARKs. These are incredible pieces of technology that allow fully private transactions and efficient verification of complex contracts.
How can this be possible? For this, Mitra would add a couple of features to Bitcoin Cash:
**CashAssembly**, a non-Turing-complete and deterministic variant of the very efficient WebAssembly, which replaces Bitcoin Script as smart contract language.
**Carry-over**. An output can have some bytes specified as “carry-over”, and when an input wants to spend the output, these bytes have to be included exactly as specified—basically carrying-over the bytes, allowing state-transformations between transactions.
**Preambles**. This allows to put additional constraints on the transaction itself, such as inputs and outputs of the transaction fulfilling certain conditions.
**Input constraints**. This allows additional checks on inputs, i.e. the input having a specific block height, block hash or preamble hash.
Also, possibly some optimizations to the current transaction format, MAST, as well as fractional satoshis.
**And the best part is, none of them change the awesome scaling properties of Bitcoin Cash that make it so fast, cheap and reliable.**
But what do those features mean? None of them are particularly radical, perhaps CashAssembly, but that‘s pretty much only a more efficient version of Script.
So what is this all about?
CashAssembly
CashAssembly is a variant of WebAssembly, but a non-Turing-complete version. Let me unpack what that means.
**WebAssembly** is a new instruction set for the web. It allows to run websites at native speed, but fully sandboxed and secure. This means you can take a chunk of WebAssembly and execute it without having to worry about it infecting your computer or stealing your data. However, many realized that WebAssembly is useful even outside the web—a project called WASI (WebAssembly System Interface, https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/) is a project that standardizes this.
WebAssembly advertises itself with a lot of features (https://webassembly.github.io/spec/core/intro/introduction.html) that are very attractive for smart contracts:
**Fast**: Allows more smart contracts to be evaluated in the same time for the same hardware
**Safe**: Contracts aren‘t able to break into the node they‘re running on
**Well-defined**: The clarity of the spec prevents accidental chain-splits due to diverging implementations
**Hardware-, language- and platform-independent**: It‘s absolutely essential for a smart contract to be able to be evaluated independent of environment
**Compact**: Allows the same code with smaller transactions
**Efficient, parallelizable**: If compilation of contracts to machine code is quick, this allows more contracts to be compiled, which relaxes hardware requirements
And Ethereum realized this power, which is why they‘re developing ewasm. I‘m sure there‘d be ways to cooperate with the folks from ewasm.
If you have a look at the instruction set of WebAssembly (https://webassembly.github.io/spec/core/appendix/index-instructions.html), we see some things we don‘t want to have in Bitcoin Cash: loops, recusive function calls and floating point numbers. The last two can just be cut out by not including them in CashAssembly. Loops I‘ll talk about in a minute.
First, lets talk about a hidden feature of WebAssembly that is very beneficial: All instructions after 0x11 have a *constant* execution costs (ignoring some things like CPU caches). This means, no matter the inputs of the instruction, it‘ll always take the same amount of time to run. This is *not* generally the case for Bitcoin Cash instructions. For example, OP_CAT or OP_NUM2BIN take longer for some inputs and are faster for others. Which means we can‘t calculate the execution costs beforehand.
However, if we have a list of instructions that are all greater than 0x11, we can calculate the execution costs quite easily. Just add up all the execution costs of the individual costs and that‘s it!
For loops, this is a bit trickier, but if we know the number of iterations of the loop, then we can just multiply that by the costs of the body of the loop. So we just put the number of iterations for each loop along with the inputs for the transaction. If there are nested loops, it‘ll result in a tree structure of iterations.
I‘ve made a test implementation of this concept when I had some free time in Japan, and while it was a bit complicated to get my head around these recursive data structures, once I did, the implementation flowed quite nicely from there. But if we choose to go this route, we can start with non-recusive structures to allow implementations to ease in, and add nested loops later on.
This scheme would buy us a LOT of things:
We can have loops in our transactions, which computers are very good at executing, and which allow us a whole class of things to compute.
We can calculate the costs of verifying a transaction before running the smart contracts in it, just like with good ol‘ Bitcoin Cash transactions v1.
We don‘t have to meter each instruction. While we have to keep track of the number of iterations for each loop, we don‘t have to meter every single instruction—unlike Ethereum—which makes evaluating of the contract just that much faster.
For contracts that don‘t need recursive function calls (which I suppose are most of them, and even the infamous mega recursive Ackermann function can be rewritten only using loops: https://www.sciencedirect.com/science/article/pii/0304397588900461), this is more than enough. It would allow us to compute a large class of things.
All of this while being non-Turing-complete: A program determining if a piece of CashAssembly halts (which is the infamous Halting Problem) can be written quite easily: Just write a program that always returns “halts”. Because every loop in CashAssembly must have a predefined and finite number of iterations, it must halt at some point, and given CashAssembly is only made out of loops and constant-cost instructions, this means every program written in CashAssembly must eventually halt.
And as I‘ve explained above, we can even calculate very precisely when it will halt.
Going hyper-efficient
If you take an even closer look at WebAssembly, you realize there are a lot of inefficiencies that we wouldn‘t want to have in a smart contract instruction set:
All load and store operations take at least 3 bytes
Accessing local variables takes at least 2 bytes
All opcodes for arithmetic (add, mul, div, etc.) are repeated for every data type (32-bit integers, 64-bit integers), which eats up a lot of opcode space
Stacks can grow to arbitrary sizes
WebAssembly really is optimized for compilation. For Bitcoin Cash, we‘d like be able to *both* interpret as well as compile contracts efficiently
I‘ve heard some great ideas how we could improve a new instruction set for Bitcoin Cash. Those are very technical and still very early in development, so sharing them here wouldn‘t make a lot of sense. But there‘s a lot of room to tailor CashAssembly to the requirements of Bitcoin Cash.
Carry-over
However, with only CashAssembly, we‘d only get what amounts to, pretty much, a great opcode compression. Yet, if we want to do something more interesting, like a game of chess on chain, we need to be able to transfer *state* between transactions. We actually *can* simulate state in Bitcoin Cash already, see https://kalis.me/smart-contracts-eth-btc-bch/ under Simulated state, however, “a new contract is created (with a new address) and the full balance can be transferred to this new contract. This causes UX problems due to the new address”, so it is hard to use in practice, and not very efficient. Ideally, we‘d have native support for transferring state between transactions.
This is where the carry-over comes in. It can be a part of an output and adds some additional metadata to it. When this output is spent by an input, the input also must contain this carry-over (hence the name). The contracts in the transaction can now access this data.
At the end of the day, it‘s just a leaner, clearer and easier to use version of what we‘re doing already in Rosco‘s article.
In the case of a chess game, the carry-over would be the positions of the pieces, and each transaction would be one move. For each move, the moved piece, the old and new board are included in a transaction, and the contract ensures that the move actually results in the new board.
Preambles
With carry-over and CashAssembly, we already get a powerful system. Unfortunately, with this scheme, we still can‘t do too much. For example, if we want to implement a token scheme, we‘re at a loss. For tokens, we need to recusively prove that all previous transactions are valid, too.
If we know the smart contract enforces the token rules (i.e. ∑inputs ≥ ∑outputs), and we also know that the same contract has been enforced for all previous transactions, the entire chain of transactions becomes valid.
We can do this using a proof-by-induction. It‘s one of the first things one learns in higher mathematics.
I think the best analogy of it dominos falling over. If you can show that one domino falling onto the next causes it to also fall over, the only thing you have to do is to make the first domino fall over. Then the whole chain falls over.
Basically, to prove P(n) holds for n ≥ 0, all you need to prove the following:
P(0). The base case. This is the first (zeroth) domino being tipped over.
P(n) => P(n + 1). The induction case. This means, if any domino (here, n) tips over, the one following (here, n + 1) it *must* also fall over.
So if we know both 1. and 2. are true, we know for sure that all dominos will fall over.
For tokens, P(0) would be the genesis transaction for the token, the first domino. It‘s basically self-evident.
P(n) => P(n + 1) would be what the actual smart contract verifies.
Let‘s apply this to dominos. Say the **number of dots of a domino represent the number of tokens**. Also, say dominos can choose to fall over or not, this would be the smart contract.
So before falling over, a domino would ask the previous domino the following question:
*I pinky promise to only ever fall over if the number of dots on myself are the same than my previous domino.*
*Did you, previous domino, also pinky promise to do this, and also, did you make your previous domino pinky promise to do all that I‘m asking you right now?*
If dominos always keep their pinky promises (and smart contracts do), each domino falling over will know for sure that all previous dominos have the same number of dots. This means, no dots can ever be created by a domino falling over. Except for the first one, which is our genesis transaction in our example.
This is what our smart contract will do for tokens. It‘ll go through all inputs and check if they also have that exact smart contract (which in turn must have checked if the inputs of that input have the exact same contract, and so on and so on back to the genesis transaction of the token).
However, this smart contract is something more special, because it constraints the transaction itself, and it has to be able to check if it‘s present in inputs. For this, we need the last piece of Nimbus, ...
Input constraints
..., input constraints. They allow to verify some property holds for an input transaction. For example, you could put in there the blockhash of the transaction you‘re spending, and if the transaction actually isn‘t in a block with that hash, your transaction trying to spend that would be invalid. The same could be done with a preamble and a preamble hash. The preamble hash specified in an input transaction constraint must be the same as the hash of the preamble of that input transaction.
How could this be useful? A smart contract preamble for a token would check if its own hash is the same as the preamble hash of each input. Then, it would know that this exact contract is enforced not only for the transaction itself, but for all transactions coming before it.
This would actually be a bit too strong, because it would require an *infinite* number of transactions to come before it, which is impossible. So we just create an exception in the rules that state that this check doesn‘t have to hold for the genesis transaction of the token.
And there we have it! A powerful smart contract platform for Bitcoin Cash, which would allow native tokens.
But with these ingredients, we can do even more
Today, we can already do looping transactions that can be used to keep a contract alive forever. We can build a simple DAO out of this. The be.cash contract is something like that. Each time you give it a signature, amount and nonce, it‘ll automatically pay you that amount, given the nonce and signature is correct, and also modify the contract to have the new nonce.
This is already possible and if we squint eyes, it‘s something like a very simple DAO. But let‘s build something bigger. Something like MakerDAO.
With the preamble, we can not only make tokens, but we can also create “messages” between DAOs. A DAO, for example, an oracle can create an output every few seconds that contains price data. It would enforce this behaviour with a preamble, and also enforce the same preamble for all transactions before that (up to the genesis transaction of the DAO). Another DAO, a buying/selling DAO, for instance, that would want to take such a message as input to determine its behaviour, can now just check if the “message” transaction does have the oracle preamble hash.
Then it knows for sure that the “message” must come from the oracle DAO, just by checking the preamble hash. Nifty!
Based on that, we can create a whole web of DAOs that all send verifiable messages to each other using the preamble. This model of development is actually well researched, it‘s called the “Actor model”. Erlang is a language that uses this design.
This, of course, still needs a ton of additional research. But it would be very powerful.
Incremental activation
And it wouldn‘t be activated and supported by the whole network all in one go, we would first activate a limited version that doesn‘t add any features but just lays out and hashes the bytes differently while still keeping the old Script system (we would have to support it in Mitra anyways), also add fractional satoshis, then, maybe in this order, add the carry-over, MAST, input constraints, CashAssembly, preambles. All of them in their own hard-fork, every 6 months—just as we‘re used to it—once they‘re well researched, polished and tested.
Step by step, it would make Bitcoin Cash incredibly useful. And in my opinion, more efficiently so than Ethereum. Let me just summarize all the ways Bitcoin Cash with Mitra would be more efficient than Ethereum:
No need to run each transaction twice
No need to meter the execution costs of each instruction
Much lower orphan rate due to higher block intervals
Transactions can be verified independently from each other embarassingly parallel, possibly even using GPUs
I believe Ethereum and Bitcoin Cash will remain in competition forever. They‘ll just have different priorities and engineering tradeoffs, making some use cases more viable on Ethereum (like very sophisticated DAOs) or on Bitcoin Cash (like simpler but cooperating contracts).
Ludwig von Mises would see that Mitra recognizes that for something to become money, it has to be a commodity first. Mitra would allow Bitcoin Cash to become a more useful commodity, which would then allow it to become money.
That‘s why I believe Ludwig von Mises would love Mitra.
*Note: all donations for this article will be used to develop Mitra*
@TobiasRuck
