Those are non-blocking and clearly defined and I believe we can successfully resolve those. Even though I may not always fully agree with you, I value your feedback and admire your positions on many other topics.
I’m hoping to convince more and more people, but there will always be some where it may be in their interest not to be convinced. Ecosystem is big and wide, and I hope it will become bigger and wider, and not one single entity represents it. If I fail to convince, giving up is also an option.
Re. “Going back to the fact that the owner of Group is advertising it as “SLP2.0”, that means that we would lose a lot of features.”
I did not create nor change the name of that Telegram group to SLP2.0 so that’s not being fair. It was Paul Wasensteiner who made the initiative to rename it to SLP2.0 and nobody in that group (including you) seemed to mind at the time.
I then asked James Cramer about it to clarify and got the impression there was agreement forming around it so I just went along with it in casual talk.
The Group CHIP nowhere refers to it as SLP2.0, and it won’t ever because while GROUP enables a functionality, SLP can choose to use it or not use it, and some other token ecosystem could freely form around Group, but it is my impression that SLP folks want to use GROUP. Instead of speculation, it would be good to ask them?
Also, middleware development is permissionless, and once building blocks are available on the base layer, anyone will be free to use them as they see fit and build whatever they want with them. Group is an enabler, not a full-stack solution.
I was asked to provide some specific costs and risks so here is one.
As I understand it, any un-upgraded wallet that receives a GROUP utxo will be completely unaware of its special status, and would treat it as any other utxo on that address. Therefore when the wallet tries to spend it, the transaction will fail and the wallet will have no idea about how to deal with it.
It effectively means that all economic wallets must be upgraded in order to stay reliable. If not, BCH network will appear to the rest of the world to be unreliable and unsafe. Given that, the CHIP needs to address and commit to achieving that ecosystem-wide wallet upgrade.
It is my understanding that most wallets (maybe even all) simply filter UTXOs according to known patterns against the pubkey script TX field i.e. they’re whitelisting spendable patterns. A grouped pattern would not match, and would so not be included in the wallet’s local db of UTXOs belonging to the wallet. An unupgraded wallet would therefore NOT attempt to spend it because it wouldn’t even consider grouped UTXOs in building a transaction. I think it would be good to ask wallet devs for inputs here, but after talking with @cculianu I’m fairly confident of this.
That sounds very optimistic. I don’t think it’s the case since until SLP there was no reason for wallets to do this besides p2pkh and p2sh. Or at best p2pkh, p2sh, p2sh-multisig. Electron is the most capable power-wallet that exists for BCH. It’s capabilities should not be considered representative.
Then I guess we should consider building a list of wallets and see how they deal with non-p2pkh and non-p2sh outputs. If consensus would allow it, what would happen if a miner would mine a 0xEE <gibberish> output? What if that <gibberish> contained a P2PKH template? Maybe some wallet implementation processing it from the back would think it’s just a P2PKH output and ignore the prefix? But then, couldn’t a miner even now prefix it with some currently-valid opcodes to make it unspendable and confuse such wallets?
To add some fresh context, in response to all the comments I’m reworking the CHIP to reduce the scope down to TRANSFER, GENESIS, MINT, MELT, and BATON features. The working branch is here.Merged. There I have already reduced the scope in both tech. description and the spec, those parts are like 90% done and I intend to add a flowchart if it will added a flowchart to clear some concepts and help with security analysis later. Also, Calin’s proposal is now implemented and it would help us close the following issues: layer mixing, number format for qty can now be VarInt (aka CompactSize), simplify parsing for non-VM aware code (could be relevant for HW), and the issue of multiple OP_GROUPs in script
Yes that seems like a reasonable thing for the CHIP authors to organize and execute. I’m predicting that the result will be “Vast majority of unupgraded wallets and services will become unreliable in the case that they receive a GROUP utxo.” If so, this is a massive cost and risk. Enough to make me consider that the design of group needs to be redone so that it does not cause this.
If that’s what Calin’s idea is referring to, e.g. something like stuffing all of this into p2sh, then big from me.
Would feel good to get that but that’s not what’s proposed. The prefix and group fields would still live outside the P2SH hash, but here they would also live outside the Script VM and only make use of the TX serialization script field to store the prefix.
Nodes have to be in consensus so after an upgrade they’d all be aware of this and wouldn’t treat the prefix as part of the script, they’d slice it off before passing the rest to the Script VM.
However, unupgraded wallets would think it’s all a script, and to them could look like 0xEE <gibberish> or 0xEE <gibberish> <p2pkh>.
Stuffing it all into p2sh would make the proposal lose the appeal, at least to me. Because then you couldn’t tell that some output is a token output without also receiving the actual script through some side-channel. This would complicate a lot of things, how would you build a token explorer if you couldn’t tell where those tokens are on the blockchain? You’d have to somehow collect all those scripts externally, and there’d be no way to tell whether you got them all.
You can think of MINT as nothing but a “magical” token amount which can be fanned out to any number of other magical amounts or ordinary amounts. So, you answer both questions by filtering all UTXOs having that token ID, summing their quantities, and checking for existence of a MINT authority in the UTXO set. If token amounts add up to 1 and no MINT exists then it’s a NFT with a fixed supply. A token database can be built in a single pass over the blockchain, and then updated as new TX-es are published. You don’t need this database to only verify consensus rules, though, so only services such as block explorers would need that database and only if they’re interested in supporting tokens.
For light wallets interested in some token features a SPV proof of fixed supply can be provided by filtering for only transactions of that token ID which have a MINT bit in either inputs or outputs, and providing them alongside Merkle proof of their existence. To be fair, these proofs could grow large if a token had a lot of MINT operations before spending the last MINT.
So these questions can both be answered by information contained on the blockchain. The same goes for metadata. We write it in the OP_RETURN of the GENESIS transaction, and by including that data in the hash which pseudo-randomly generates the token ID, we’re compressing the metadata inside the token ID, as it becomes a commitment to the metadata.
Any token DB can answer the “what is the metadata?” question by a simple lookup of the genesis TX for the token, and the person asking the question can be 100% sure it’s the correct metadata without having to look past the UTXO he owns. Just compare the hash of the metadata being served with the token ID you’ve received. It’s trustless.
Re. other points:
a) I expect the outcome of studying wallets to be quite the opposite of what you expects so we’ll have to hold this one until we actually get some new information. Before asking/studying wallets I’d like to complete at least the tech.description & spec sections so everyone can be on the same page.
b) More work needed on this one too For now, a simple question - is SLP cool and shiny enough? Because Group solves a lot of security/trust issues with SLP architecture as demonstrated above.
Here we can refer to another topic investigating the possibility to simply put SLP into consensus as-is. Here I will repeat my own argument to make a point which would be off-topic there.
If we’re breaking out of “as-is” then why not polish it further… this is kind of what Group does with the current scope.
After lots of feedback throughout almost 2 months since the first draft, the CHIP has significantly matured and I invite everyone interested to have another look. I have been told that the technical description flows much better and makes it easier to understand, and I’m so glad to be hearing that! I couldn’t have produced this alone, you’ll notice the difference in quality from my first draft. It is everyone’s feedback that made this possible, because I learned from you all, and with the goal to really make this proposal ironclad!
Scope is reduced to just the GENESIS, TRANSFER, MINT, MELT, and BATON features.
Scheme for storing token data changed so it doesn’t require living inside Script.
Still lots of TODOs, but this is a milestone and we’re moving ahead!
Update: If you already read the rev. 2021-04-13 kindly note that there was an erroneous claim regarding SPV proofs for current token supply when MINT and MELT authorities still exist. Such proofs are only verifiable if all MINT and MELT authorities have been destroyed, which can be proven. This is because verifier has no way of knowing that descendant branches spending some authority UTXO and affecting the supply don’t exist. He’d have to check the UTXO set from the proof VS the UTXO set obtained from a trusted full node.
Have you considered allowing miners to claim excess tokens? The rule could be that the coinbase outputs can include token outputs. Given that burning tokens normally isn’t allowed, I guess the point is moot.
It would move the tokens to nearer equal status to BCH, and that may be undesirable.
Hi thanks for reading! Note that line will only hold until we introduce the MELT authority later in the document. Before that we’re describing only a minimal token system. In technical description, we’re introducing the whole system bottom-up, building it up from the minimal system which is just the TRANSFER+GENESIS where you can do minting exactly 1 time, and there you can only transfer and freely melt. Then we introduce MINT to let you mint later and transfer ownership of minting capability, and then we introduce MELT and set the balancing rule to == so no more accidental melts. With MELT authority there is clear intent and authority to melt, which makes auditing the “official” supply easy while also preventing accidental burns by users. Finally, the BATON makes the distinction between one-time use authorities, and those that are allowed to be transferred.
This is not-applicable to the scope of the proposal, and as you said it may be undesirable. In an old draft, I did ponder a hypothetical solution where tokens would be really equal, and it would have problems.
While tokens can be plugged into all interfaces where BCH can, they’re not really equal and shouldn’t be – because we need the incentives around BCH not only for the blockchain to work, but for the whole ecosystem to align their incentives and share the same goal, and also for security because the price will not just have an impact for lives of everyone holding BCH, it will also have an impact on increasing our % of the SHA256 hash-power.
True, it could be as simple as introducing another authority, e.g. a FEE authority which would work exactly like MELT but the excess wouldn’t be destroyed and instead would be claimed by miners. Just to be clear, I have no intention of including such a feature in the current proposal, because assessing the impact could detract the proposal from moving forward.
After a days long discussion with Emil Oldenburg, I accepted his proposal to simplify the authority system to just one UTXO per tokenID, now called the baton output, have fixed minting capacity, and add lockable metadata fields to the baton. I believe that this will give the CHIP wider acceptance, make it more friendly for full stack product builders, address previous concerns about complexity, and make it more defensible and likely to be activated.