PMv3: Build Decentralized Applications on Bitcoin Cash

This article introduces a new solution to a technical problem faced by Bitcoin Cash: certain types of transactions grow over time, making them inefficient and impractical.

With a solution to this issue, the Bitcoin Cash virtual machine is already powerful enough to implement and scale many applications planned for “global state” cryptocurrencies like Ethereum.

To describe the problem, the proposed solution, and how complex, decentralized applications can be implemented on Bitcoin Cash, this post begins with some background information.

Contracts

Bitcoin Cash transactions move money between addresses, and each wallet can have many addresses. Internally, each address is defined using a virtual machine bytecode often called “Script”. This internal language is used to specify each address’ contract, the program which sets the requirements for spending funds from that address.

The contract used by most addresses requires only one digital signature (P2PKH), but more complex contracts can also be specified. For example, a single contract can have two valid “code paths”: either A) signatures from three different secret keys, or B) after 30 days, signatures from only two of the keys (in case one of the signers loses their key). A wallet can provide either “proof” to create a valid transaction spending from this address.

Many cryptocurrencies support these simple contracts, but Bitcoin Cash also supports a much more powerful kind of contract, covenants.

Covenants

Covenants are contracts which “validate forward” — along with requiring the standard proofs (e.g. digital signatures), covenants require the spending transaction itself to match a pattern.

For example, a covenant can require that the spending transaction only withdraws a certain amount from the address, returning the remaining balance. This strategy is used by CashChannels, a covenant contract which enables non-custodial, subscription payments denominated in any currency.

Other examples of covenants include Mecenas, a Patreon-like recurring payment covenant, and Last Will, a covenant which supports inheritance.

The forward validation of covenants is extremely powerful, allowing developers to build contracts which are self-sufficient. Each time a user creates a transaction “spending” from the covenant, the transaction is only valid if the user follows the covenant’s rules. In effect, a covenant contract holds its own balance; the money is not held by any other person or entity.

Covenants enable self-sufficient, on-chain addresses, but to build complex on-chain applications, we need one more building block, tokens.

Tokens

In the cryptocurrency space, the term token is used to describe any virtual asset which can be transferred on a network.

Tokens can represent assets which exist outside the network (like commodities, stocks, or currencies held by custodial institutions), or they can represent more abstract concepts, like shares or privileges in decentralized applications.

Simple Ledger Protocol (SLP) Tokens

On Bitcoin Cash, Simple Ledger Protocol (SLP) is the most used token protocol, allowing tokens to be “minted”, transferred between users, and held in SLP-compatible wallets.

Like the bitcoin cash currency, SLP tokens are held in normal addresses, but SLP is not part of the internal design of the network. Rather, SLP specifies a precise format for SLP-compatible transactions. SLP-compatible wallets carefully validate the full history of every token they receive, ensuring the token is not a forgery. To do this, the wallet must download and verify every historical transaction which has involved the token since it was created: possibly thousands or millions of transactions.

SLP tokens currently work well for many use cases, but to be used inside covenants and other contracts, this full historical validation would need to be performed inside every transaction.

If a contract attempted to validate SLP tokens, because each new transaction must include and validate the previous transaction, each successive transaction would be larger than the last, growing infinitely until it’s too large to be accepted within Bitcoin Cash network limits (and the token is “stuck”).

Proof by Induction

Instead of individually validating all of a token’s parent transactions, it’s possible to employ a strategy called mathematical induction to validate them all at the same time.

Basically, a transaction can prove that it could not exist without being a valid descendant of an original token-minting transaction. If a wallet confirms that this single transaction is valid, it can know the whole token history is also valid. This inductive proof is the strategy used by CashTokens.

Fixed-size Inductive Proofs

Inductive proofs are already possible with the Bitcoin Cash virtual machine, but they suffer from the above “infinitely growing transaction” problem.

In the area of each transaction where proofs are provided, inductive proofs include the full parent transaction, allowing them to prove that the parent transaction spent a valid token. Unfortunately, because the included parent transaction also includes the grandparent transaction and previous proof in its own proof (and that transaction includes its parent and proof, and so on, all the way back to the minting transaction), each new transaction becomes larger than the last.

Detached proofs offer a surprisingly simple way around this problem: the parent transaction can optionally hash its proof, including the hashed contents at the end of the transaction. By "detaching" the proof, future transactions can use the transaction in their own proofs, and all token history and previous proofs are effectively “compressed” into the hash.

This change has no effect on transaction security, as a hash of the proof remains inside the transaction (unlike Segregated Witness, where proof data is actually excluded from the transaction). Effectively, detached proofs let a parent transaction optionally include 32 bytes of additional data (the hash), and in exchange, future transactions referencing that parent transaction may save KBs or MBs of data.

For a detailed technical specification, see CHIP-2021-01-PMv3: Version 3 Transaction Format.

In this simplified graphic, every transaction input is pictured only with its proof contents. The left represents a token transaction without detached proofs — the transaction is made much larger because the full contents and proofs of both its parent and grandparent transactions are included in its un-hashed proof data. (In practice, megabytes of additional history may also be required.) The graphic to the right demonstrates how detached proofs make this type of transaction efficient: the parent transaction is validated, but unused historical data is “compressed” into a small, 32-byte hash. Using detached proofs, all token transactions are equally efficient, regardless of their history.

To see a working demo of an inductive proof contract, including how parent transactions are reconstructed and validated by a covenant, see the “Token Transfer (tx3)” unlocking script in the CashTokens template.

Each script includes comments explaining its purpose, relevant design decisions, and security considerations.

CashTokens: Contract-Based Tokens

With detached proofs, it’s possible to develop a completely contract-based token system using a combination of covenants and fixed-size inductive proofs; see CashTokens: Contract-Validated Tokens for Bitcoin Cash.

CashTokens easily support Simplified Payment Verification (SPV) and light clients (like mobile apps) without requiring a heavy, trusted, SLP-compatible indexing server. This would improve the security of most SLP wallets and reduce the need for specialized SLP server infrastructure.

Existing SLP tokens can be migrated to a contract-based version of SLP either over time (using both systems simultaneously) or each can be migrated on a fixed date. For non-custodial tokens, it’s even possible for a token holder’s wallet to trustlessly redeem their “upgraded” tokens from a covenant.

While improving SLP would be extremely valuable, perhaps the most important value proposition of CashTokens is their compatibility with other Bitcoin Cash contracts.

Using Tokens in Contracts

Tokens provide a powerful new building block for Bitcoin Cash contracts. Because CashTokens can be issued and verified by covenants, they can be used as depository receipts, independently-transferable shares, and permission systems for decentralized applications.

On-Chain Token Sales

CashTokens can be distributed on-chain, either by trusted entities or by permissionless, public covenants. A simple, fixed-price token sale is demonstrated in the CashToken Demo. With support for larger numbers and OP_MUL, many Initial Coin Offering (ICO) algorithms can be implemented directly on-chain.

Transferable Synthetic Assets

Using CashTokens for option contracts like AnyHedge (used by Detoken) would allow each option to be transferred independently after its created. This would make it possible to create and trade synthetic assets on secondary markets.

Decentralized Exchanges

A decentralized, automated market maker covenant for SLP tokens has already been demonstrated by swap.cash. With CashTokens, market making covenants could support comprehensive, decentralized exchanges like Uniswap at transaction costs of less than $0.01 (USD, 2020). Using the above-described synthetic assets, these markets could enable borderless, global, uncapped investment in any stock, commodity, currency, or other asset.

Prediction Markets

Using CashTokens, prediction market covenants could create two-way-bridges, allowing Bitcoin Cash to be moved into and out of efficient, independent, decentralized prediction market networks.

Prediction markets could bring trillions in value to Bitcoin Cash (in 2020 USD), and Bitcoin Cash has important properties which make it superior for prediction market use. Prediction markets also provide the decentralized price oracles needed to build trustless synthetic assets.

Details: Prediction Markets on Bitcoin Cash.

Global-State Networks

Many cryptocurrency networks use what could be described as a “global state” paradigm: transactions push and manipulate data in an abstract, network-wide virtual machine. Ethereum is the largest example of this paradigm. In global-state networks, all transactions must be precisely ordered, as any transaction may interfere with any other transaction.

While these types of networks simplify decentralized application development, they are much more complex to scale, and base layer transaction costs have already risen to levels which make many use cases unaffordable (and place serious pressure on end-user privacy). Layer 2 solutions can alleviate these problems, but more development is required.

Stateless Network, Stateful Covenants

In contrast, Bitcoin Cash could be described as following a “contained state” or “stateless” paradigm. Almost all of the information needed to validate a Bitcoin Cash transaction is contained within the transaction itself. Nodes need only provide quick access to a small amount of data, Unspent Transaction Outputs (UTXOs), and transactions cannot otherwise interfere with each other. (In fact, even UTXO lock contention can be eliminated by the Spend Tree database structure.)

While harder to develop decentralized applications, the stateless paradigm is maximally-scalable: most elements of the system match computing patterns which are categorized as “embarrassingly parallel”, and in its current state, Bitcoin Cash can already scale to 25,000 transactions/second on modest hardware. Bitcoin Cash has sufficient capacity to serve billions of daily users in the next decade.

Detached proofs offer a strategy for enabling contract-based tokens and decentralized applications without breaking the statelessness of the Bitcoin Cash virtual machine. Instead of making all application data “global”, data for individual applications remains contained within covenants. Only users who care about a specific application need to concern themselves with that application’s covenant transactions. This makes development of light clients much easier, even for the most complex decentralized applications.

It’s likely too early to tell which of these network paradigms is superior–global-state vs. stateless transactions–but with support for detached proofs and contract-based tokens, Bitcoin Cash can support permissionless innovation on a much wider scale, offering decentralized application developers a cryptocurrency with competitive scaling, privacy, and censorship-resistance features.

Feedback & Discussion Groups

If you have questions, feedback, or you’re interested in contributing to future CashToken specifications, please join us:

This post is part of a series on developing decentralized prediction markets on Bitcoin Cash.

Previous Post: CashTokens: Contract-Validated Tokens for Bitcoin Cash ➔

Next Post: not yet written.

Thank you to John Nieri and Karol Trzeszczkowski for their feedback on this post. Thank you also to Jonathan Silverblood, Tom Zander, and Calin Culianu for their early feedback on the PMv3 proposal.