Brainstorming Interaction Between Group, PMv3, and Introspection

We have the 3 proposals moving forward on the standards track:

  1. Group enables native tokens, conceptually close to ERC-1155 but enforced with the C++ “contract” language. Scope has been reduced and now it’s just one baton UTXO per token for supply management and metadata updating operations. Pretty much SLP features with architectural flaws fixed but because it’s native and attached to BCH UTXOs we get DEX/CoinJoin almost out of the box and tokens get access to all interfaces BCH can access, including future ones.
  2. PMv3 gives us covenant and other goodies but for this topic covenant is the most relevant. The covenant also lets us implement CashTokens, conceptually close to ERC-20.
  3. Introspection gives us, well, introspection opcodes so Script contracts can easily be fed info from the outside, it’s like letting contracts load some variables from the outside, and those variables can be used to control the contract. Contract writers can code slots for user-provided variables, and users could plug those in by spending an input at the required index and with required features. I’m not a Script contract writer so I get lost here, but it’s not hard to imagine that introspection could enable a whole lot of interesting contracts.

Now, how could they all interact?

Here’s how I think it could work together:

1+2 saves covenant writers from having to implement tokens, and enables Group tokens to be locked inside a covenant BUT we can’t use the token amounts/IDs as conditions for the contract because Script has no way of accessing those, not without 3. that is.
1+2+3 gives contract writers full power, they can lock both BCH and some Group token inside a covenant, and then use other inputs/outputs to control their spending, and the covenant contract can be aware of tokenID/amount of the output it’s attached to.


  • The current introspection CHIP doesn’t include Group introspection opcodes, but I guess we can talk about adding those as all proposals move forward.
  • Full scope of Andrew Stone’s Group Tokenization also included a covenant solution, but it looks like there’s no community interest in going with that so PMv3 would take that role.
1 Like

I see them being discussed, but none of these are “moving forward to activation”.

Should I remind why this language is highly controversial?


Thanks, edited the wording

Can you TL;DR what is the difference between PMv3 covenants and Last Will or Mecenas (via Electron Cash) covenants?

The concept of a covenant is this: a way to enforce that the Script on the new output will be the same as that on the prevout, and that by induction we can know that the whole chain of such TX-es is unbroken all the way back to the creation transaction.

I had to read up a little about both of your examples and it looks like they’re limited in that the change (or full inheritance) always has to be sent back to the same address, and they’re probably a special type of covenant which can be hacked with available opcodes, because it’s enough to look at the parent output to make that covenant possible.

For a more complex covenant currently you can’t look at the grandparent output from the Script (and actually looking would imply scaling problems), so the next output would have to carry it in order to prove that the historical chain is unbroken and so on and it would quickly grow in size, and PMv3 fixes this by carrying the compressed proof of what happened in the past so you can chain together multiple TX-es and the tip of it can prove the history with a single hash, which gets updated after every TX to include the new parent, and so on. This way you can “look” at the grandparent without actually looking. The previous TX was the one that did the looking and embedded the proof (HashedWitness) of what it had seen.

Just for info, the dropped Group covenant feature did it another way, by having tokens be covenanted from their genesis (or BCH with the “fence” feature), so consensus would directly enforce the sameness of the Script across all tokens belonging to that group (same tokenID), but without introspection opcodes it would be fairly limited and I’m not sure how breaking out of the covenant would be handled from within Script. I wanted to study this feature more but after community feedback made it clear there’s only interest in the “base” Group scope I gave up on that. I think this breaking-out of the covenant would require multiple “authority” UTXOs so with the reduced scope we lost a prerequisite to have covenant the Group way. Locking BCH in a Group covenant would require the “fence” feature too, which also got dropped… so yeah, I kind of see now why people thought the original scope was complex.

1 Like

A lot of years ago, in the time of Symbian Nokia smart phones, I got an app on one that was a “radio”. When I started it, to my surprise, I got the ability to use an FM-tuner interface and listen to the local radio broadcasts.

At first I figured that the smart guys at Nokia must have included an actual FM tumer in their phone. Because, that is how its done, no?

Turns out, I just underestimated the power of a generic computing device in combination with a simple analog-to-digital converter that any audio-recording device, like a phone, will have anyway. (wikipedia)

I’m also seeing the same thing here where the group concept is a specialized solution for one type of tokens that require an extra component in the node. But when we look at the Script system there is ample opportunity to do tokens in a generic manner that don’t require the extra component. That don’t require the special-casing of one specific usecase.

This topic is opened to regard what makes sense in a world where these competing standars are developed, and that is awesome. That question is very important to answer.

My guess is that the goals of group can be answered by PMv3, and I emplore the group devs to consider this option and see if a joining of forces is the way forward.

1 Like

Bitcoin Cash is a specialized solution for one type of token and it worked quite well. All Group is really adding is the ability to create and manage the supply and metadata of these other tokens. They are reusing the base transfer function which works almost the same as it does for Bitcoin Cash. Same design paradigm.

But it does require it - the HashedWitness is the extra component. Re. “generic manner” - YAGNI. For exotic tokens/uses Group+PMv3HW would let you have those.

PMv3 is not a token solution by itself, it only enables a token solution to be coded with Script. Its main feature is covenant support through HashedWitness of which CashTokens are just one possible use. Because Script was not designed to build a whole token system, then even with the consensus change required (HashedWitness) the token solution is rather convoluted.

Why wasn’t Bitcoin originally implemented with the Script but the Bitcoin “covenant” is hard-coded by C++ instead? Because cash is the basic building block of a blockchain, everything blockchain does operates on some form of cash. Script operates on cash, it doesn’t create cash. Group is reusing the “transfer” interface of BCH whereas CashTokens have to re-implement it in Script and because of that it’s more limited.

Consider the atomic swap / DEX feature, this is what Jason said about it:

We get DEX pretty much out of the box with Group. Any BCH wallet dev. could build a basic DEX – required knowledge: BCH TX building principles, and basic accounting.

Why wasn’t BCH implemented with the Script but with the C++ “covenant”? Use the right tool for the job. Group does tokens, PMv3+Script does covenants.

A while ago you requested that Group demonstrates requirements on middlweare:

Solution: you poll a SPV server to give you the Genesis TX, any external metadata, and the SPV proof for that 1 genesis TX

Please add to the CHIP & spec all the new APIs, algorithms and indexers that are required to make this work.

It’s not been added yet but for anyone familiar with BCH UTXO model I believe it’s not hard to imagine what will be required, and with the baton (previously known as “authority outputs”) now locked to exactly one UTXO in existence for each distinct token, it only got simpler.

Why not ask the same kinds of question towards CashTokens? How does the user construct his transfer TX? How do we track token usage? How do we audit supply? How does the user know what he’s received? How do we build indexers? How do we track metadata? How much work is required to create all downstream software to have a smooth UX with CashTokens?

Just like a CPU with microcode is not an FM radio solution by itself, it “only” enables one with its code.

The question thus becomes: why spend money on an FM receiver if software can give you one already? Or, to drop the analogy, why add the Group special processing when plain script can do the same?

Make the question even more plain, to activate on Bitcoin Cash one of these two options:

  1. Group

  2. PMv3 + Introspection

Where nr 1 gives you one usecase, number 2 also gives that, but more. As I write just a few paragraphs above, why add Group when the PMv3 + Introspection can give you all that already?

I don’t think this got a real consideration and thus I’ll repeat it:

1 Like

one of these two

Why does it have to be one of the two, why not both? I want all 3.

Where nr 1 gives you one usecase, number 2 also gives that, but more.

It doesn’t give you that. It gives you more limited tokens, awkward to implement and use. I’d vote for 2. not for the tokens but for that “more”, and I’d vote for Group for the tokens.

Why did you ignore my points about APIs and middleware, judging from your past comments on Group I thought that was important to you?

joining of forces

For that we have to acknowledge the features and limitations of all 3 proposals. I did not open this thread to drop any one of them, but to see if they could be made to better fit together.

Maybe I missed something crucial, can you please explain what you mean with this?

“That” being the full-feature tokens, as in, having all features BCH has and being moved around and interacting with blockchain the same way BCH does. “Those” are best possible (value statement, you don’t have to agree but just to understand where I’m coming from) tokens, only thing better than that would be to drop the “dual” nature and have them really be equal to BCH but I’m not advocating for that because it would mess up incentives around BCH. So no, PMv3 doesn’t enable “that”. It enables some awkward tokens in which I’m not interested, and I don’t see other devs stading in line to build stuff based on CashTokens, whereas at least some people got excited about Group.

1 Like

ok, thanks for that. Good to see where you are coming from.

For clarity, a Script + Introspection solution actually has a better integration with the rest of the system since its part of the system. No glue needed, its included in the core fundamentals. Unlike group.

Maybe you have been looking at this in a very group-specific way and much like my software-defined-radio solution example above, its hard to grasp for most people. This is naturally a good improvement point.


That’s easy.

Because a dedicated, hardware FM receiver will use less power and provide greater efficiency (but less flexibility). It’s all about tradeoffs.

The same with Group tokens. They could be done using existing generic scripting subsystem, but such a solution, while more flexible, would be also much more complex, bloated and less efficient.

Since BCH blockchain aims to be efficient Cash system, Group seems like a logical solution, assuming it is done not in an overcomplicated way, of course.

1 Like