So I already wrote here about motivation, and I imagine that will become a part of some document to be written in the future.

Edit: I just realized group tokens would result in reducing circulating supply of BCH! Continue reading to find out why :)

We need a way to evaluate token proposals and I have started something, which I think is in line with this guideline which was a great read. I'm trying to understand scaling and stakeholders. Below is the working doc, have a read, tell me what you think and if you can help prove/disprove my claims or share other ideas.

Scaling FAQ

Will it inflate the UTXO set in terms of bytes?

The UTXO set will grow with adoption, period. Will it inflate because someone will write a silly script that takes up resources for no good reason? Because you can inflate it like that today. Multisig UTXOs require more space than normal UTXOs. So what? It brings in miner revenue, because it has to pay more for the space. Miner validated tokens (MVTs) wouldn't change anything fundamental here. A transacion made means a fee paid!

The UTXO set will get inflated, anyway. So let's inflate it for the good reasons, for utility! Can't have transactions and not have them at the same time.

TODO: How do fee earnings/byte scale? What about earnings/number of script instructions? Not all transactions have the same processing requirements. This is a general problem of a transaction's unit economics, something to look into further, any previous work?

Will it inflate the UTXO set in terms of number of UTXOs?

The UTXO set will grow with adoption, period. Will it inflate because someone is using CashFusion to split his wallet into a hundred small outputs easy to use later, or someone tagging BCH holders with dust for no good reason? Because you can inflate it like that today. A dust transaction still brings in miner revenue. Miner validated tokens (MVTs) wouldn't change anything fundamental here, they're nothing but magic dust transactions. A transacion made means a fee paid!

The UTXO set will get inflated, anyway. So let's inflate it for the good reasons, for utility! Can't have transactions and not have them at the same time.

TODO: How do fee earnings/number scale? This is the above problem multiplied. Whatever unit economics a certain TX type has, it'll get multiplied with the number of them.

Will it inflate the UTXO in terms of number of CPU cycles per each UTXO

Any script has the potential to increase the number of CPU cycles of the UTXO. This just adds another way to do it. Will it inflate because someone is using a hedge contract with the existing tools or will it inflate because someone is implementing tokens with the new tools? You can inflate CPU cycles today.

They will get inflated, but let's inflate it for the good reasons, for utility! Can't have script operations and not have them at the same time!

Here's where the scaling function is really important. If adding a script instruction results with a fixed amount of extra processing, then all is fine. If adding a script instruction could result with quadratic growth of CPU, then we'd have a big problem. I don't think any of the MVT solutions has this problem. TODO: confirm this.

Also, a transacion made means a fee paid! But, could there be a good way to price script operations? Like extra fee per each OP code? We don't want this as a hard rule, but miners could freely adapt if the market was requesting more and more OP codes in their transactions. Can we quantify resource costs for OP codes?

Will it add additional database requrements

I think this is a yes and no. For nodes that don't care about tokens, they just do their job as usual, verify validity of each TX, and that's it. All they have to do is process the script and see if the TX is valid. You don't need to build a token index to do that.

For those who want to actually use tokens, like token block explorers, well of course you need separate databases! Can't have tokens and not have them at the same time. Everyone using tokens needs to track them! Good news is - it's not mandatory to interact with token infrastructure!

Other Criticism Addressed

We have SLP already, we don't need another one

Yes, but let's be frank - it is not a 1st class token solution. It has to compete with solutions on other blockchains, and it can't. So, whatever we do there will be competition to SLP. Better have it on our own blockchain. Those who already built something that works with SLP can continue to use it so we wouldn't be forcing them into anything they aren't already forced into by competition from solutions on other blockchains. If we have to compete, better compete with ourselves, that's how we'll grow to be the best!

Having too good tokens will displace BCH

How could that possibly happen? Every group token TXO is also a BCH TXO ie every group token TXO needs to be wrapped into a little bit of BCH which will carry it around, like a soap bubble made of BCH.

This means that miners get an additional mechanism to control group token usage. Apart from setting the fee, they could adjust the required amount of soap ie amount of BCH locked in with the group token TXO. As with fee policy, this would be a software setting, where every miner decides for themselves.

Cost Benefit Analysis

General

• ( ) Competitive advantage versus other blockchains/ecosystems
• ( ) Attracting new users and talent, from outside of existing community ie growth of the BCH ecosystem. One species doesn't make an ecosystem. This should enable all species to flourish, like a fertilizer.
• ( ) Cost of doing nothing? Missed "revenue" in terms of user, developer, and cash inflows, missed ecosystem growth opportunity.
• (-) Narrow focus, can't be used to solve all smart contract problems

Note: The idea is that it would enable us to capture more % of the problem market because we'd be best at solving a select set of problems which should then attract those who need those specific problems solved.

• ( ) It can interact with whatever other script solution, thus expanding utility beyond scope.
• (-) Programming model, re. statefulness and side-effects (jtoomim). Why is this a problem? Is this philosophical or could it have far-reaching practical consequences?

1 Node stakeholders

• (-) More CPU cycles and more RAM needed. Supposedly only a little more, ie only the slope of linear scaling function would change.

1.1 Miner nodes

• ( ) More fee revenue if it brings more adoption

Does supporting group TX increase cost of non-group TX-es? Does adding a group TX bring in more revenue than the cost of extra processing? If yes, what proportion of group TXes would cover for the increased cost of processing non-group TXes? What's the current marginal cost of income/loss for a kilobyte added? We need some financial model here, previous work?

1.2 Big nodes

1.2.1 Those using group TXes themselves

These nodes are both verifying TX-es and using the features. Example: Group tokens block explorers. They'd have to index the tokens, too. That should be an user-space problem!

• (-) Additional resources needed to actually use the tokens instead of just verifying correctnes of transactions. How much cost per additional token supported? What do other blockchains cost in this regard?

1.2.2 Those not using group TXes themselves

Example: an exchange not interested in adding group tokens.

1.3 User nodes

• (-) Barrier to entry to BCH blockchain raised, a little bit? How to quantify this? Even with no tokens, what does this mean for 1b users we dram of? Can't they use SPV? But then is it still a "node". I need to read up on this. Previous work?
• ( ) Barrier to entry to token economics lowered! If they couldn't participate in other blockchain tokens as a node, this would kind of lower the barrier to entry to tokens. Now they can use SPV to independently participate in a whole new branch of the ecosystem.

1.4 Node developers

• (-) Extra work. How much now, and how much for maintenance?
• ( ) Maybe use these primitives for something cool in the future
• ( ) Attracting new talent, which should help with the workload

2 Userspace stakeholders

2.1 Individual users

• ( ) Access to financial instruments previously not available, or access them at a better price than competition

2.2 Business users

• ( ) Access to financial instruments previously not available, or access them at a better price than competition
• ( ) Enabling new business models?

2.3 Userspace developers

• ( ) Maybe use these primitives for something cool in the future
• ( ) With more growth there should be more opportunity for professional advancement within this ecosystem
• (-) Adds to technical debt, more specs to read etc.

2.4 Holders and Speculators

2.4.1 Long

• ( ) More adoption, number go up.
• ( ) Reduces amount of BCH in circulation!

That's right holders :) Because every OP_GROUP is also a dust TX that means that every group token in existence will have a little BCH attached to it, effectively taking it out of circulation.

2.4.2 Short

• (-) No love for you, sorry!
• ( ) But, if longs get ahead of themselves, there'll be opportunity for you, too!

3 Opinion holders with no skin in the game

• We appreciate your feedback too, hoping you will become a stakeholder!