libauth VS pmv3

Note that a smart wallet for Bitcoin-tech doesn't exist, so if you implement a contract, you need to "teach" some wallet how to spend from the template. Dream is to have an universal wallet that can easily import contract templates, things like LibAuth and BitauthIDE were built with that goal, we're getting there!

To craft the transactions you'd also need a library, maybe something like https://libauth.org/ or you could craft the transactions by hand by reading on https://documentation.cash/

I've also written descriptions of all VM operations for Libauth: https://libauth.org/enums/opcodedescriptionscommon.html and https://libauth.org/enums/opcodedescriptionsuniquebch.html

I've been building this "user space" tooling in Libauth (a lightweight, zero-dependency JS/TS library), and I would love to work with anyone interested on building that tooling in other languages/libraries too!

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.