A lot of work and research has gone into the technical specification of this CHIP.
Thank you for recognizing it. However, I don’t subscribe to the labor theory of value so that labor will have been meaningless if doesn’t achieve the desired outcome and impact which is to grow the ecosystem and BCH value, and with it my net worth as well 
I’m not interested in participation trophies, I’m interested in 10x gains on BCH. While other proposals also increase the likelihood of a 10x, I felt that this one was neglected and has lots of potential so that’s where I’m putting my energy, it all adds up. The best way to predict the future is to make it happen.
However, in its current form, GP does not think it is simple / minimal enough to be considered for acceptance into the network.
Is there a broadly accepted simpleness / minimalism criteria for consensus layer changes? How do we quantify this requirement? Lines of code? Number of script ops required to perform token operations? If it’s a matter of opinion, then I simply disagree and will wait for other stakeholders to weigh in.
Furthermore, important sections about costs, risks and alternatives are incomplete or have wrongfully been asserted as non-existent.
Addressed below.
GP would like to see a minimum viable change isolated from the current large scope
Minimum viable change would be only the BATON, MINT, and MELT authorities. Even with only those, a lot can be done (tokens, atomic swaps, token CoinJoin/CashFusion), as demonstrated in the examples section.
However, covenants are really useful and would benefit from other Script opcodes as soon as they’re activated e.g. covenants would benefit from the introspection CHIP because it enables an entry into the covenant. Reducing the scope would mean we push that feature far away into the future. Why would we want to do that? The feature is cheap, enabled by a simple optional constraint on top of the above mentioned “base”.
How do we quantify “large”? If it’s a matter of opinion, then I simply disagree and will wait for other stakeholders to weigh in.
It is unclear what the author means with “The market demands smart cash but, with Ethereum, it got smart contracts disguised as cash”. What are the practical differences between smart cash and smart contracts disguised as cash?
Accepted, I’ll reword.
A strong statement such as “the market demands X” needs some actual backing.
How’s this: All Tokens | CoinMarketCap,
paired with the price appreciation of the “main” coins on whose blockchain those tokens exist.
If that is not sufficient, what kind of evidence would be satisfactory?
The noun/verb analogy is confusing and creates more questions than it answers.
Accepted, I’ll reword.
The only listed cost is “possible implementation errors”. At the very least this change will add complexity to potential future upgrades since future updates will need to account for both BCH and tokens.
This is vague so hard to address, let’s try and work it out.
Is BCH balance checking adding complexity to potential future upgrades? Token logic is in the same class as that. It just works, regardless of upgrades in other parts of the code.
Even if we only get what’s currently proposed in the CHIP and never ever upgrade it why would some future unrelated upgrades need to account for it?
Here are some changes that would NOT be affected by having group tokens:
- Network rules, unless we choose to give special treatment to group UTXOs with regards to fee or dust limit requirements
- Blocksize changes, unless we choose to have a separate cap for token TXes
- Pruning
- New opcodes
- New SIGHASH
- New signature types
- UTXO commitments
and some that might be:
- Changing numerical precision for BCH & tokens, and I suspect that BCH precision could be changed independently of tokens
- Totally new state scheme e.g. utreexo
- ?
There are likely other costs that are not mentioned / researched.
Another vague statement. What kind of costs are you expecting to find in some code performing simple arithmetic operations and a few IF statements? What kind of research are we looking for here?
It’s not clear which features are part of the current proposal.
All of the features in the CHIP. What’s described in technical description is also formalized in the specification. There’s a dedicated section for future upgrades, which is not part of the current proposal but for information only.
If all features are included, this is much more than a minimal viable proposal, and should be separated.
I did not see a convincing argument why we need to limit ourselves to a minimal viable proposal.
The authority system seems very complex.
Complex by what criteria? It’s no more complex than adding up balances, the only difference is that instead of summing up token amounts we’re summing the quantity field using a logical OR i.e. sum |= qty and then placing a few logical rules on that sum. I’m surprised by experienced developers classifying this as “complex”. On the outside, both token amount and token authority UTXOs are the same, and everything that works with BCH outputs work the same with both token amounts and authorities.
So these alternatives (e.g. CashTokens, SLP, SmartBCH) should still be evaluated.
Accepted, will add.
An evaluation of alternative versions of GROUP tokens could also be added.
Do you mean some historical proposals, or different scopes of the current one? The current authority system really made this “click” with me as an elegant solution. I didn’t look deeply into historical proposals but I understand that those had problems because they used a different way to perform management ops so I was not interested in that. What value would there be to entertain obsolete proposals? I actually got an opposing comment when I tried to explore an alternate design approach in the CHIP.
The evaluation of alternative rollout approaches is a good addition.
Thanks!
it does have serious implications on the core functioning of the network. So security considerations need to be further specified.
It’s vague, what kind of considerations are you looking for here? The network continues to function the same, but we could end up having lots of BCH dust UTXOs which would carry tokens, and with them economic value. We can even have lots of dust UTXOs now, but there’s no utility in having them other than to spam the network. It would cost only 5460 BCH (about $3m) to spam the network with 1b UTXOs. I understand that there are entities who’d like to see BCH fail, so why haven’t they attacked BCH in such a way? Maybe because they know it would be a futile attack because:
-
We can scale to more than 1T UTXOs and for 1T it becomes infeasible due to attack requiring about a quarter of BCH supply.
- Miners can respond and quickly adjust the dust limit should there be evidence of such an attack
- Withstanding such an attack would actually benefit holders because the attacker would have to purchase the BCH, and withstanding the attack would be good PR for BCH
If it will not be an attack but the aggregate market demand for tokens which ends up locking 5m BCH into 1T token UTXOs then I will be celebrating that on my yacht which I will have bought for 1 BCH.
Besides the workload increase for node developers, the only listed cost is that “BCH will get more adoption”.
What if it really is the only one? How hard do I have to try find others before giving up? We cannot invent problems to satisfy the expectation that there have to be problems. I don’t like complexity, that’s why this proposal appealed to me in the first place, because it so simple, cheap, and easy to reason about. Lots of potential impact at a low cost – yes please!
If you can think of any other costs then I’ll be happy to either dispute them or add them to the list if I fail to dispute them. Maybe this one should be turned to (-) for some stakeholders: “This functionality will enable competition from within our ecosystem.”
from me.