Recursive Smelting

A Token Layer Protocol on Bitcoin Cash

Recent events in the Bitcoin Cash community have spurred a new wave of innovative token solutions. Each proposal is unique and comes with its own advantages and disadvantages.

Existing Proposals

There are several existing proposals for tokenization on Bitcoin Cash. Perhaps the most ambitious proposal, GROUP, by Andrew Stone has a complete set of features (miner enforced token conservation, permissionless transfer, etc.) but requires a base protocol change which has caused contention within the developer community. On the other end of the spectrum lies OP_RETURN/DAG (Directed Acyclic Graph) protocols — potentially the most complete example of which being the Simple Ledger Protocol (SLP) by Jonald Fyookball et al.. While SLP requires no protocol change, it does however rely on user consensus to prevent fraud, enforced by a traversal backwards through prior transactions. This traversal may go back as far as the user deems appropriate, however the transaction cannot be fully trusted until reaching the genesis transaction (or relying on a trusted issuer to verify it). When Simplified Payment Verification (SPV) compatibility is taken seriously and fixation on permissionless transfer is relaxed, we arrive at proposals such as Tokeda by Joannes Vermorel. Tokeda allows for a simple and expressive framework but requires an auditable trusted issuer to enforce consensus rules, a point of contention for both the developer and user communities. The fourth and final category of proposals is that of segregated ecosystems such as RootStock, Omni, Wormhole, and CounterParty — all of which have an extensive set of features, but are not without significant cost. The interface between such protocols and Bitcoin Cash requires users to interact with additional infrastructure (such as utility tokens) and have adoption obstacles associated with them.

Recursive Smelting

In Recursive Smelting (RS) the primary objectives are to create a permissionless protocol using on-chain data, while maximizing SPV compatibility and avoiding invasive protocol changes. Our proposal originates in the DAG category and then breaks from it using novel cryptographic techniques — specifically Succinct Non-interactive ARguments of Knowledge (SNARKs). An RS token’s ledger is a collection of transactions adhering to one of three primitive transaction formats. Each primitive transaction interfaces with one another, creating a subgraph within the graph of all Bitcoin transactions. These primitive transactions are the genesis transaction, minting transactions, and ownership transactions. Ownership transactions are required to conserve token quantity while minting transactions are not.

Bob’s ownership of tokens is indicated by an unspent assert output in a valid ownership transaction broadcast by Alice (‘valid’ being defined later). In this way RS transactions can be seen as a direct overlay to traditional Bitcoin transactions.

A chain of ownership transactions

Genesis and minting transactions follow a similar design. The genesis transaction specifies metadata relating to the token and delegates minting duties. Minting transactions then create and issue tokens and again delegate minting duties. If no minting public-key is specified in a minting transaction (i.e. minting has not been delegated), tokens can no longer be minted.

A chain of transactions involving the creation and issuance of tokens

A single transaction adhering to one of the primitive transaction formats is not sufficient to verify token ownership, as a fake chain of transactions could be forged. To verify a primitive transaction as valid one must indeed traverse back through the graph to the genesis transaction, verifying that each one is correctly formatted — planting RS firmly in the DAG category thus far.

Without further changes, the token proposal in this incarnation may foster some interest —the protocol allows for permissionless creation, issuance, and transfer of tokens requiring no additional protocol changes. The design is simple and token ownership is transparent, easily readable and compact. Furthermore, assert outputs are constructed in a way which exposes them to the traditional Bitcoin script providing versatility (e.g. multisig, escrow and Bitcoin-to-token atomic swaps).

Proofs and Recursion

We now add an additional layer to the protocol, maximizing SPV compatibility using the SNARKs mentioned above. A SNARK is a tiny cryptographic proof (on the order of bytes) which can be used to quickly verify (on the order of milliseconds) that some statement is true.

Here comes the recursive magic: We supplement minting transactions and ownership transactions with a proof that the prior transactions adhere to the primitive transaction format and that their proofs are true.

A chain of primitive transactions with proofs supplemented

In this way, each transaction’s proof is a recursive proof of all previous transactions’ validation. Users can now validate primitive transactions without traversing the entire graph and can supplement their own transactions with ironclad proofs that they are valid while requiring only knowledge of the immediate inputs.

Putting it all together, we have a token protocol that is SPV compatible with minimal overhead that removes the need for a trusted central authority and requires no invasive changes to the base protocol. In our whitepaper, we go further and demonstrate how the RS protocol can be used to achieve, for example:

1. Provable token burns
2. Token issue escrow
3. Atomic swaps (Bitcoin-to-token)
4. Miners’ fees payable via tokens

This list is far from exhaustive — due to the nature of the transaction format, any abilities provided to a Bitcoin script are provided to a RS transaction script.

You can find our draft-quality whitepaper here (and its GitHub repository here). We welcome any and all questions, comments, and criticisms, and are very excited to hear from the community at large.

-Harry & Chris