Join 76,551 users and earn money for participation
read.cash is a platform where you could earn money (total earned by users so far: $ 547,360.51).
You could get tips for writing articles and comments, which are paid in Bitcoin Cash (BCH) cryptocurrency,
which can be spent on the Internet or converted to your local money.
This means tokens imlemented as a hardcoded feature provided by the Bitcoin Cash blockchain, like the native currency BCH. Token checks and balances are enforced the same way as for BCH, and with tokens a few new "buttons" are provided to manage token supply and metadata.
Let's first go over how Bitcoin Cash transactions work. Imagine BCH as gold sand packaged in transparent bags, each grain being one satoshi. The bag ties are locked with combination locks, most common type of lock called an address. The bags themselves are called transaction outputs. When we make a transaction, we're instructing the blockchain to repackage the gold sand into new bags with new locks. Some sand is taken as fee for this repackaging service, and the blockchain will refuse to pack too small amounts of sand - a requirement known as the dust limit.
Imagine tokens as synthetic sand, with color unique for each distinct token. We require it to always come packed in a separate bag, tied together with a bag of BCH, and locked with the same lock.
How is this synthetic sand first created, though? The blockchain produces it on demand if some requirements are met. As with any other transaction, you present unlocked bags and state your demands. To create a token, you must present just enough BCH to pay the fee and fill the small bag of BCH to accompany the token bag, that's it. The first bag of a new color will be a special grain of an unique, randomly assigned color.
To create token sand, you must present it to the blockchain.
With this, we illustrated the main token operations: genesis, minting, and transfer of tokens.
Recall that tokens are dual-currency outputs, always carrying at least a minimum BCH amount and some token amount. Should a token become worthless, users can burn all their token bags and reclaim the pure BCH.
If the special grain is thrown away (burned), then the token supply will be locked forever.
That's fine, but maybe others will care and have an use, and enabling tokens wouldn't hurt BCH holders. We can't force people to want to exclusively use BCH. If they have a need for other currencies, even if we don't offer tokens, they'll use them on other blockchains.
I believe we're moving into an era of tokenization of everything. It started with Ethereum and it's only been ramping up. Supporting tokens on Bitcoin Cash blockchain means BCH gets to capture a little value from every token resident, as it would create a little additional demand for BCH. Will it add up to anything significant, who knows? Why not spread our bets?
SLP has an architectural flaw where middleware failure can cause total loss of funds to a 100% compliant wallet. No wonder it never really took off when there are user-friendly solutions on other blockchains without this flaw.
PMv3 gives us something better - native covenant support, and if a covenant can lock BCH, it can lock native tokens too! This proposal is not really a competing proposal, it's supplementing because native tokens can be used inside PMv3 covenants. I want both, here's why.
Sure, with covenant support you could code a Script contract called CashTokens, and it's an interesting demonstration of what covenant can do. Being that, they'd be awkward because keeping track of such token balances is done somewhere inside a complex lock placed on a pure BCH bag, known as the locking Script. Such tokens don't come with the same benefits as native tokens, and they have limitations due to their architecture.
It scales, just a little fixed amount of data and work per BCH UTXO carrying a token.
Imagine you had a pure BCH transaction with 10 BCH bags in, and 5 BCH bags out. The blockchain needs to visit and weigh 15 bags, check 10 locks, and create 5 new locks.
With tokens, it'd need to visit 15 pairs of bags, but still check the same 10 locks, and create 5 new ones. There's no double job, the node weighs BCH amount in each bag once, and token amount once. The weighing operation is very cheap because it's just basic arithmetics when coded.
What about it? It grows proportionally to number of locks placed on bags, nothing changes there. More users, more locks. And remember, there always must be a small BCH bag attached to each lock so... if it grows, it'd be a good problem to have?