cashtokens VS pmv3

Useful References: https://cashtokens.org/ https://helpme.cash/CashTokens/

The Paytaca wallet team has created an open source indexer for BCMR (Bitcoin Cash Metadata Registry) metadata. In the next release of their wallet new CashToken metadata will be shown in the wallet.

Now that CashTokens has enabled on chain NFTs for BCH, the latest series BCH GURUs sold out all 200 over wave 1 in less than 24 hours.

Have you guys taken a look at BCH's CashTokens yet? It's a protocol upgrade that released on May 15 of this year. It allows BCH to have smart contract capabilities that rival Ethereum, but with a massive scaling advantage since BCH uses the UTXO model. We can now truly build the entire global financial system on BCH. We haven't even scratched the surface of the possibilities yet...

You probably don't want to know the full technicals, but if you do you can read the CHIP which contains all the details.

Will you soon shut up about BCH being shit against "superior chains" when I point you to the CHIPs such as Native Introspection Opcodes, Bigger Script Integers which allows better smart contract functionality coming in 2022, and PMv3 and Group Tokens which allow better token and transaction formats that are coming in 2023?

BSV has no way of storing state or doing anything close to https://github.com/bitjson/pmv3. I'm curious as to what level of fuckery and bloat they're using this time.

For variable number ranges, all parsing can safely be accomplished using a single 11-byte macro, rather than the minimum 29-byte macro required of VarInt in most cases. (Note, the safe, fully-equivalent VarInt macro is 53-bytes.) This simplification is notable enough to enable use cases which would otherwise be inhibited by parsing constructions causing contracts to exceed VM limits.

proposal: CHIP-2021-01-PMv3: Version 3 Transaction Format

One nice thing about PMv3 is that the "solution space" is surprisingly limited. Initially it might seem like there are many ways to accomplish the two big goals of PMv3 ("fixed-size inductive proofs" and "VM integer compatibility"), but if you dig deep on any particular element, of the 2 of 3 possible solutions, there's a clear "best choice". (I've tried to document everything in the Rationale section of the spec.) There's probably only one design decision I'm less sure about (the RSN format), but only because the analysis to (dis)prove it is taking me a long time. 😅 (Working on some open source tooling.)

Out of curiosity, what would you think about https://github.com/bitjson/pmv3 as a way to enable Ethereum-like smart contracts using a local state contained inside?

There are many important use cases for which Group Tokens would require PMv3 (an upgrade which would enable Hashed Witnesses and make CashToken contracts possible in "userland").

To enable hashed witnesses I proposed PMv3, a minimal v3 transaction format which enables a lot of other use cases like sidechained prediction markets (PM). Group Tokens also cannot support these use cases without hashed witnesses.