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.
Native Group Tokens High Level Requirements Overview
Script Requirements
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],
Consensus Requirements
When verifying an individual transaction, perform the below in addition to normal processing.
For every input seen:
If they have the OP_GROUP opcode then:
Check whether fields are of valid size. Fail the transaction if not.
If it's a group token then add group balances to running sums.
If it's a group authority then OR group authorities to running flags.
Else do nothing.
For every output seen:
If they have the OP_GROUP opcode then:
Check whether fields are of valid size. Fail the transaction if not.
If it's a group token then add group balances to running sums.
If it's a group authority then OR group authorities to running flags.
Else do nothing.
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.
User Requirements
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.
User Manual
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.
Copyright
This document is placed in the public domain. Attribution neither required nor desired.
Credits
Andrew Stone
Thank you for this. This actually an additional learning for me.