SPV friendly, token verification Protocol on Bitcoin

Low cost & scalable solution to Back to Genesis Problem.

Abstract:

We propose to solve the Back to Genesis Problem (B2G problem) as follows:

The token sender will hold the chain of transactions, all its historical liked transactions of the token from the tip to token genesis. When it’s spent, the sender simply hand over the chain of transactions to the recipient. The recipient traces back the chain of transactions and check that all transactions back to the genesis are following the token ruleset.

Compared to previously proposed solutions, this is a simple and practical approach that leverages the characteristics of Bitcoin. It can be implemented in various wallets, including SPV, and is cost-effective and scalable.

Background

What we want?

We want scalable token solutions on Bitcoin SV Network. In the age of CBDC or widely accepted legal stable coin, the potential users base of the token solution can be millions or billions. If the automation payment which is known as smart contracts became standard of any businesses or services with every devices on earth, then it might be wise to think the number of wallets will reach to trillions.

One of the tools of Bitcoin to scale is SPV, Simplified Payment Verification. It allows the P2P transactions wallets and reduce the traffics to the network drastically comparing to the current standard payments. We believe that in the mass adoption scenario above token transactions on Bitcoin will also have to be handle by SPV approach as well.  In this article, I explore the background of problems, current solutions, and the proposed simple yet scalable solution of B2G problem, Back to Genesis.

Tokens solutions on Bitcoin

Bitcoin as stateful: OP_Push_TX

Until the introduction of the OP_push_tx technic, generally Bitcoin script was believed that it is stateless. People thought that there are no mechanism in Bitcoin script that sender can enforce its locking script into its ancestor txs. Because of OP_push_tx, now we can create and enforce specific rules to ancestor txs thus the overlay network, one example is tokens, is possible.

Token types: Layer1 vs Layer 2

There are two types of token of Bitcoin. One is the layer one token, such as Stas token and Sensible token. It utilizes Op_Push_tx technic above and the token rules are enforced by miners through Bitcoin scripts.

The second one is layer two tokens, such as Run, 1 sat Ordinals and Tokenized. It is basically use the BSV blockchain as a WORM data storage, using OP_return to write token data and computers outside of Bitcoin network enforce the token rulesets.

The problem: Back to Genesis

I define this problem as the cost of the verification. Either layer one or layer two, Without a third party authority verifying and signing each token transaction, when the receiver receives the token transaction, the receiver need to verify the validity of token. In order to do so, they have to check that the chain of token transactions follow the token rule sets. It is from the received token tx to the original minting transaction, “token genesis” or “token base” in other words.