Hey all! We now have a high level doc outlining the requirements for enabling group token semantics. It's one and half A4 page, should be easy to read and enough to enable us to assess impact on scaling etc, ie start the talk at high level, and as everyone's understanding catches up can work our way down to design choices and implementation details, in a way we will together reinvent group tokens.
Meanwhile, Andrew is working on a full spec which you can find here. He already had some comments on the doc below, but the essence is good already. I need to read up more to implement those comments for this doc and it can be part of this reinvention process.
Btw, what does it mean 1st class? It means that they're enforced by node C++ (or any other programming language) code as opposed to being enforced by script (like Ethereum) or by users (like SLP). 1st class means that the logic is enforced by the same power that enforces BCH logic. There is no script that can allow creating BCH from nothing. Similarly, there is no script that can allow cheating group token rules.
OP_GROUP enables storage of data in a place preceding normal script. That's all that Script has to check. That data is given meaning in the consensus checking part. This data could be stored in a new transaction field all the same.
Grouped transaction output scripts MUST follow the following format (<> brackets indicate data pushes):
<Group ID> <quantity> OP_GROUP [normal script constraints],
When verifying an individual transaction, perform the below in addition to normal processing.
For every input seen:
For every output seen:
Finally, check the validity of the transaction as a whole:
If an authority appears from nothing AND group genesis requirement is NOT met then fail the transaction.
Else check whether authority "balances" out i.e. only lower or equal authority can be found in the outputs flag. Fail the transaction if not met.
Check token balance taking into consideration authority found in the input and fail the transaction if criteria not met.
No authority: input group token balance == output group token balance
Mint authority: input group token balance <= output group token balance
Melt authority: input group token balance >= output group token balance
That's it. Whatever Native Group Token semantic details will designed, they will be implemented in one of these 3 places above. This high-level description should be sufficient to evaluate impact on scaling.
Users can decide whether to support the Native Group Token semantics or not. If it will not be supported, then NGT UTXOs will be unspendable by the user.
Non-supporting wallets should at least check for the presence of OP_GROUP and deal with them in a way that makes sense otherwise regular transactions created by the wallet could fail by accidentally including an OP_GROUP UTXO as input.
Assuming majority of wallets already match the UTXO script against know pantterns, this shouldn’t be an issue, as those will just ignore those UTXOs.
It is recommended that non-supporting wallets at least show them as non-spendable BCH balance because showing 0 would hide the fact that there's still something in there.
Should the user choose to support NGTs then he should support, as a minimum:
Preservation of authority UTXOs i.e. if you use one as input, you must create one as change output.
Tracking wallet NGT balances which is as simple as summing UTXOs that belong to the wallet
Building ordinary NGT transactions, which are transactions containing OP_GROUP and respecting the consensus rules shown above
Melting NGT UTXOs
While advanced features won't be supported this way, at least the end user will be protected from accidentally giving up authority or unknowingly passing it on to other parties. If he doesn't want the tokens, end user can burn the tokens and claim the locked BCH.
This document is placed in the public domain. Attribution neither required nor desired.
Andrew Stone
Thank you for this. This actually an additional learning for me.