General Protocols Statement on "CHIP-2021-02 Group Tokenization for Bitcoin Cash"

Overall statement

A lot of work and research has gone into the technical specification of this CHIP. However, in its current form, GP does not think it is simple / minimal enough to be considered for acceptance into the network. Furthermore, important sections about costs, risks and alternatives are incomplete or have wrongfully been asserted as non-existent. GP would like to see a minimum viable change isolated from the current large scope, and then a deeper evaluation of costs, risks and alternatives.

Provided below are comments on the different sections of the CHIP.

Summary

Satisfactory: Yes

Comments: None

Motivation / Benefits

Satisfactory: No

Comments:

• 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?

• A strong statement such as "the market demands X" needs some actual backing.

• The noun/verb analogy is confusing and creates more questions than it answers.

Costs / Risks

Satisfactory: No

Comments:

• 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. There are likely other costs that are not mentioned / researched.

Technical Description

Satisfactory: No

Comments:

• It's not clear which features are part of the current proposal.

• If all features are included, this is much more than a minimal viable proposal, and should be separated.

• The authority system seems very complex.

Specification

Not evaluated in detail.

Implementations

Satisfactory: Yes

Comments: None

Evaluation of Alternatives

Satisfactory: No

Comments:

• The proposal states there are no "real" alternatives because the alternatives use different types of implementation. By definition, "alternatives" are alternatives (i.e. use a different type of implementation) that address similar use cases. So these alternatives (e.g. CashTokens, SLP, SmartBCH) should still be evaluated.

• An evaluation of alternative versions of GROUP tokens could also be added.

• The evaluation of alternative rollout approaches is a good addition.

Security considerations

Satisfactory: No

Comments:

• The proposal states "Not even a single line of existing consensus code needs to be changed to implement Group Tokenization" and uses this as reasoning that there are no security considerations. Even *if* the proposal doesn't alter any existing consensus code, it does have serious implications on the core functioning of the network. So security considerations need to be further specified.

Stakeholder costs / benefits

Satisfactory: No

Comments:

• Besides the workload increase for node developers, the only listed cost is that "BCH will get more adoption".

Stakeholder statements

Satisfactory: No

Comments:

• No statements present.

General Protocols Blog

This article forms part of the General Protocols Blog, a collection of cross-platform links showcasing our team's community activity, Bitcoin Cash projects, UTXO development, and general crypto musings.