@andrewstone: would you consider developing an “implementation-ready” specification like PMv3 ?
Yes, I have extracted a specification out of the documentation and implementation, here: Group Tokenization Consensus Specification. You are essentially correct that the purpose of the Group Tokenization document is to explain the architecture and power of the approach while leaving a concrete specification until the point where there was interest in doing it.
Group Tokenization Script Templates and Contract Encumbered Groups seem aimed here, but those solutions seem like a much more complex way to accomplish similar goals as CashToken’s parent transaction validation. (@andrewstone would you disagree?)
Yes I disagree. As a general rule of thumb, any time a script would enforce token balance or a covenant you could just remove that logic and let Group tokens do it for you. This is more than just a “nice-to-have”. Without loops a BCH script will never be able to analyze and enforce covenants over any set of outputs arbitrarily. So there will always be awkward rules about where certain outputs need to go, and limitations in things like splitting utxos for the same reason. For example AFAICT, you can’t operation on 2 cashTokens in 1 transaction because the cashToken output MUST be output 0. This is a major limitation since it prevents atomic token swaps, and its very basic.
Contract Encumbered Groups is a simple comparison of a prevout script with the current output script. Fancy name, simple thing.
Script Templates is trying to solve a general problem with covenants that perhaps you haven’t come across yet. The problem is that (with covenants) there are now 3 antagonistic entities and only two places to put data. By antagonistic I mean “will take advantage of mistakes in each other’s code”. Today we have 2, the constrainer and the satisfier. It should be obvious that P2SH for example uses a cryptographic hash to identify the redeem script because if the “satisfier” could cheat and provide a different, easily satisfied constraint script, it would do so.
With covenants, the situation becomes more complex – the constrainer (holder of covenanted BCH or tokens) might gain advantage if they can break the covenant, the satisfier (spender) might gain advantage if they can break the constrainer OR the covenant.
And we basically have 2 entities that want to put constraints on spending, but only one place to do so (the output or redeem script).
Today, you can avoid this problem in a few ways: First, if your covenants are “anyone-can-spend”, there may be no concept of a holder and therefore no additional constraints. This might happen if your covenant implemented a defi service available to anyone, such as a CPMM (like uniswap), or the cashTokens state “baton” I think would apply.
Second, you could increase the complexity of your covenant enforcement to leave “gaps” for the holder to fill in (with their pubkeyhash, for example). I think this would be painful to implement even with an OP_PUSH_TX_DATA tx introspection opcode, and it becomes even more painful if the UTXO-efficient P2SH style output is used. But to get to real versatility, and provide an analogue to ETH’s inter-contract calling, the holder needs to add programmatic constraints, not just data constraints. This adds yet another level of complexity and area for security flaws for 2 reasons: 1. the gaps are variable sized. 2. The “holder” code can modify any part of the stack.
Script Templates solves this problem in a general fashion.
However, it makes sense to evaluate these different technologies in parts… so Script Templates is not part of what I’m proposing for Group Tokenization.
We do need to enhance the scripting language to enable smart contracts. And yes, once it is enhanced (to turing or near-turing levels) we could go the ethereum route and implement tokens (or any other computable function) on top of it. But as I’ve said in other venues, that turns BCH into a poor copy of ETH. And given ETH’s head start both in technology and adoption we will never catch up by copying. The more efficient approach is to make tokens native, and suddenly our blockchain fundamentally works faster and more efficiently than ETH plain token operations, and the token part of smart contract operations… that will be interesting to many people.