no-fork native tokens

In case you missed it token fever is upon us.  Easy-issue tokens have driven the rise of ETH and other coins.  Coingeek offered some kind of a cash prize for building a native token system for BCH (which likely would work for other satoshi-codebase coins).  This is what they want:

o Securely create tokens;
o Issue tokens to user’s wallets;
o Redeem tokens from users; and
o Securely destroy tokens back into the originating cryptocurrency at the end of that token’s life cycle

This is solved with a simple no-fork wallet protocol, which can be built into a satoshi-codebase wallet, consisting of three RPC calls:

1 - watchtoken <txid> <utxo-index vout> <label> [rescan=true]

2 - sendtokentoaddress <amt> <address> <label>

3 - gettokenbalance <label>

The first "watchtoken" marks an individual UTXO (from transaction txid and output index vout) as a "genesis" token.  This is a lump of coin that will be marked and watched and counted as a separate asset than the underlying coin.

The rescan then needs to take place, now checking to see if the wallet owns any of this asset or not.  The procedure of determining what addresses control tokens when scanning the blockchain is as follows.  A given UTXO is either of this token_label type (lets call it FU) or it is not (lets call these not-FU).

The only UTXO which is of type FU is at first the one pointed to by the watchtoken(<txid>,<vout>,"FU") call.  After that, other outputs will be of type FU only if they are outputs of a transaction exactly formed as follows:


Inputs                      Outputs

type - FU                      ?
type - FU                      ?
...                           ...
...                           ...
type - NOT-FU                 ...


The only way that any output of a transaction can also be labelled "FU" is if these conditions hold:

a)  All inputs except one must be of type FU
b)  Either all outputs are of type FU and the NOT-FU is exactly the fee,  OR all outputs but one are of type FU, in total equal to the total amount of FU input to the transaction, and one other output is not-FU (the not-FU change).

Wallets will create FU transactions with all outputs FU if possible, but sometimes when one doesn't happen to have an exactly current-fee-sized not-FU UTXO lying around, one will want to include a not-FU change output.

There is one possible edge case which might confuse a wallet implementation, which is if there are multiple outputs of exactly the same amount and so which one is non-FU change and which one is FU is unclear.  One simple way to avoid this is to mandate that in such a case there are no FU outputs, and so any wallet making a transaction needs to make sure the not-FU change is not exactly equal in amount to any of the intended FU outputs.  Once this is taken care of it is always clear which single output is not-FU.

If the transaction does not pass these requirements then the outputs are all considered not-FU, and any FU input to the transaction is "destroyed" (or rather, is now considered only the underlying coin).

This simple protocol allows us to securely create tokens, by placing some number of satoshi in a UTXO and labeling these as our token.  This allows us to issue tokens to users wallets, as any wallet which can receive coin can now receive tokens (it us up to the wallet to recognize them, so the user must tell their wallet to watch for that token).  Redemption can be done with any transaction, the user is able to sign that they control the tokens or move them as the redemption-giver sees fit.  Destroying tokens can be done by making an unbalanced transaction not obeying the above strict rule for transactions that allow passing of token type.

One nice thing about this token system is that there is no need for any software updates for miners or nodes.  To a miner, these token transactions proceed as any other transaction proceeds

The rest is very self explanatory.  Gettokenblanace returns the total of any type FU coin on the chain controlled by the keys in the wallet.  Sendtokentoaddress creates a transaction with enough FU inputs for the receiver, any FU change if necessary, and enough non-FU coin to pay the network fee.


But how will people know that my token is called "BADASS" and not FU or c74d8fce1b3d488d17b4dc92c61600ae26f7ebf1ab3e144d8014a6614b340ad2,3  ?

You can ask people to use any label for your token that you like.  In the end the token will be defined by that first TXID, vout combination.

How can I issue more of my token later on?  

You can add a new token FU2 with a new genesis UTXO and tell people this will be redeemed just like FU1 by your company or redeemer-cat.

Can this work on an SPV wallet?  

It will be a little slow to scan the chain when a new "watchtoken" is issued.  More likely people will use some trusted servers which list token UTXOs for mobile tokening.

What if I want to use 1mBTC to create 1 million tokens?  

You can't.  1mBTC creates only 100k tokens and they are indivisible.  Yes this means no token will be worth less than 1sat.

What if I want to move tokens without having any coin (non-FU coin)?

You can't.  Just like Ethereum's "gas price" you need some underlying coin to pay the network fee.

What if I want to muve a bunch of coin to several addresses and a bunch of token to several addresses at the same time?  

You can't.  Token movements in this protocol need a dedicated transaction, there can be at most ONE non-token output to a valid token transaction.

What does it take to update the network?  

Nothing.  Your network is ready to roll with this token system already.




Leave a Reply

Your email address will not be published. Required fields are marked *