@Tomothy: Yes, the idea is basically the following. A classic BCH transaction, a bit simplified (lets ignore scripts and complicated spending schemes and so forth for now) looks like this:
INPUT_1 (pointer-to-output, signature-to-spend-it)
...
INPUT_N
goes to
OUTPUT_1 (amount, address-of-keypair to spend it)
...
OUTPUT_M
And then the BCH distributed system checks that all the necessary conditions to make this money match (sum of ins larger or equal than sums of outs, signatures check out etc.).
With OP_RETURN, you can add, as you know, a special field with arbitrary data to BCH.So how about creating a token chain which looks basically identical to the above, but transacts "TOK" instead of BCH?
And the idea is basically to do exactly that, and use the exact same keys and addresses of the BCH transaction to do so and augment the BCH transaction with an OP_RETURN that basically is a pointer (in the form of an unforgeable SHA256 hash) to the extra TOK transaction.
And then my script basically just make sure that the TOK transactions are sufficiently well-formed to behave as tokens (no faking, no creation by anyone other than the owner etc).
Which will result in a token chain parallel to the BCH chain and sharing the BCH keys and addresses but having a separate set of values transacted.
And you do token creation by spending from outputs of the token's address - and assume that all tokens are identified by a generating address (of the company / individual / entity / alien / whatever who wants to create a bunch of tokens).
Which creates chains of transactions just like in BCH and you'd store those to check them until their 'genesis'.
This way, no one can fake the tokens of the owner of the privkey to that address, with a bit of extra information published, inflation can be checked to any desired schedule by everyone and so forth.
EDIT: I might also add that the validity here and any idea of "sybilling" or creating fake transactions and the like is thwarted by requiring, of course, that any TOK output is unspent only if the corresponding BCH output is unspent as well. Which means that basically, the OP_RETURN data in the latest TOK transaction points to a chain of TOK transactions that go back until the genesis of these TOK tokens - which is a TOK-augmented "generation" spent from the address that the token is identified with. By the unforgeable hash reference, TOK transactions for all intents and purposes of
validation become part of the BCH transactions. This should also, I think, address
@jessquit's concern (which I share to some extend) that BCH can scale to be the world's money, but maybe not the world's container for all financial transactions.
As you all know, I am personally not even very keen on the value of many of these token schemes (though am willing to entertain the notion that others see this differently). With this approach, the only "damage" to the BCH chain is more transactions and more miner income plus a couple of prunable OP_RETURNs - so IMO no damage at all. And it also keeps the core validation code of BCH clean, nice and simple and pushes anything complex like this away from this core.
Yet it also does not invent any metacoins - or, respectively, allows anyone to quickly invent "metacoins" (which I'd rather call tokens).
