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:

1. For many financial applications, paying a dollar or two is not at all an issue—often that‘s actually very cheap.

2. Credit cards usually have still higher fees, so Ethereum‘s ~10¢ is still competitive compared to credit cards for any payments above $10.

3. 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).

4. 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:

1. Proof-of-stake, which requires less energy/money than Proof-of-work.

2. Sharding, which allows the spreading-out of workload, thus lowering the hardware requirements to validate transactions.

3. 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:

1. Longer block times (10 minutes vs ~17 seconds)

2. No invalid transactions

3. No metering required

4. 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:

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:

1. CashAssembly, a non-Turing-complete and deterministic variant of the very efficient WebAssembly, which replaces Bitcoin Script as smart contract language.

2. 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.

3. Preambles. This allows to put additional constraints on the transaction itself, such as inputs and outputs of the transaction fulfilling certain conditions.

4. 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:

1. P(0). The base case. This is the first (zeroth) domino being tipped over.

2. 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:

1. No need to run each transaction twice

2. No need to meter the execution costs of each instruction

3. Much lower orphan rate due to higher block intervals

4. 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