research VS pmv3

It is non-custodian betting on price of supported assets paired against BCH, both parties put their money into the contract's pot and later the contract parses an oracle message and calculates how much they can take out. Made possible with Introspection opcodes and int64 upgrades to Bitcoin-tech Script VM, which activated in May '22 on Bitcoin Cash blockchain.

I dug around a bit and it seems to be this one: CHIP-2021-02-Bigger-Script-Integers.

native introspection

The latest "Group" proposal (v4.2) is more than just "tokenization". It got simpler and more powerful at the same time. It now enables generic BCH output groups that can be used to create persistent Script covenant contracts that can prove their genuineness. This is something that current contracts cannot do, even with the new Introspection opcodes. Group would make it possible because the groupID is a commitment to the whole genesis transaction, but this is not a post about that.

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?

You can't, because it requires a sibling output (same prevout txid as the contract, but index 1 instead of 0) to be spent alongside it and it verifies it using introspection opcodes that will be available in May. Only the owner of the sibling can spend the contract.

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.