Had a little brainstorming session with imaginary_username, here are the notes:
Summary of Spec Talk Held on 2022-02-01
Debaters: imaginary_username and bitcoincashautist
Spectators: freetrader, griffith, emergent_reasons
Main Topics:
- Unforgeable Groups CHIP scope
- Evaluation of carried commitment (Group) and detached proof (PMv3) features
- Detached proofs roll-out
Unforgeable Groups CHIP Scope
Discussed version: v4.3-905cac9e
It was demonstrated that “satoshi tokens” and “NFT” group types (also referred to as “super-contracts”) can be implemented using the “native tokens” group with a Script covenant set at group genesis.
To avoid premature optimization trap, the CHIP owner expressed agreement with removing the two while leaving the option to reintroduce them at a later upgrade should a need be demonstrated.
The dropped group types wouldn’t have enabled new features but would only optimize features enabled by the “native tokens” group type.
Evaluation of Carried Commitments (Group) and Detached Proofs (PMv3) Features
Both carried commitments (introduced in Unforgeable Groups CHIP) and detached proofs (introduced in PMv3 CHIP) can solve the problem of proving ancestry with a fixed-size proof, without requiring nodes to access non-local transaction data.
Either feature would enable a class of contracts currently not possible on Bitcoin Cash blockchain.
Group CHIP is non-breaking as it is, and it was assumed that the “detached proofs” would be rolled out in a non-breaking way, which is not how it’s currently proposed in PMv3 CHIP.
With solutions relying on either feature, the required data to complete the proof is brought into local context by the spender and proofs are then made by local Script validation.
Effect of either approach to nodes was confirmed to be irrelevant because the cost to blockchain is the same in terms of “big O”.
The discussion was focused around end-users and application developers.
imaginary_username presented a succinct summary:
Carried commitment
-
fixed for a given token set; clever way around taking anything out of txid, by making the proof immutable.
-
compact (because it doesn’t need to be blown up when not used in a given tx) and “surgical” (because when not blown up the tx can completely ignore the commitment, no need to do any maneuvering to propagate it)… as long as you expect almost all of your usecases to meet the following:
- the covenant is applied to the token group only. Minimal permissionless joins/exits - those will require batons - they are essentially minting/destruction events.
- you do not intend to mutate the genesis covenant very much. mutation will require that you either somehow adapt your script outside the commitment to your new requirements, or do some complex “lock this token to get a new superset token” kind of maneuver.
- you do not intend to propagate entities that span many existing tokens permissionlessly. you’ll probably need to pull some lock-and-superset maneuver as the previous point.
Detached/inductive proof
- token or coin agnostic; literally a way to take proof out of txid (by committing the hash).
- needs to be propagated for every tx involving an entity as long as it exists, script also needs to account for all scenarios it may be involved in (you can’t “turn it off” by just ignoring it), so less compact.
- can be stacked with a given token much better, as it’s an entirely independent facility from tokens. tokens enter and exit inductive covenant facilities just as easily as bch.
- born to be mutated, as long as the propagation script allows for it.
Note: “tokens” here refer to Group’s “native tokens” and their interaction with PMv3’s “detached proof” feature. Group tokens would be free P2PKH outputs so could be locked into P2SH same way as free BCH.
At first it seemed there’s feature overlap, and bitcoincashautist argued that Group’s carried commitment could functionally replace PMv3’s detached proofs feature by emulating it through successive group genesis operations.
Through some high-level examples it was demonstrated that it probably could, but it would burden application developers with additional complexity.
Quoting imaginary_username, the high-level example discussed was:
for example, i have my kitty-tokens. it’s created without frills, the groupId simply refers to a bog-standard genesis tx, p2pkh, all that. I want some of those kitty-tokens to enter an inductive contract (say, a kittyDAO, a kittyDAO2…) after the fact. how do i do that? or can my holders not do it without my baton approval?
Through discussion, a key difference revealed itself, quoting bitcoincashautist:
Both must compare some 2 contract steps, but group way compares N and N+1, while detached proof compares N and N-1. That is the key distinction, because only N and N+1 are easily accessible through introspection, N-1 requires embedding the parent and proving it through the prevout’s TXID or some other input’s prevout groupID if you made a disposable commitment in N-1
imaginary_username:
well it’s two different philosophies: it’s extremely easy for things to enter a covenant in the detached proof setup, and rightly so - “if it carries the right stuff and has the right spending condition, who cares where it came from?” is the question. we can restrict that one step further, but yes it is more complex to do that versus the groupID case. in exchange, well, the groupID case is more difficult to enter permissionlessly. which is the more important thing to people - entering a facility permissionlessly, or entering in a restricted way?
Later it was noted that the group way could also simply require payment to a P2SH address to enter the covenant, and the covenant itself could then require a group genesis.
This doesn’t remove complexity but allows it to be moved away from the end user.
It was agreed that both have merits, and an evaluation by a wider audience on picking either or both is worth conducting.
This is because:
- Superiority of the method depends on the problem being solved, so having both would make the blockchain overall more efficient, assuming the most efficient method would be used when adequate.
Having both would give more tools to application developers enabling them to reduce complexity of their solutions, and, through more compact transactions, reduce TX fees and UX complexity for their users.
- Synergy is possible, the carried commitment can commit to a bunch of prevout TXIDs to preserve them or carry them forward, even if all outputs from those TXID are later spent.
Later, it is possible to unpack the groupID to reveal TXIDs and use any of them to construct required proofs.
- In order to make P2PKH tokens possible, we require a Genesis operation and the “carry” aspect of
groupID anyway.
- Having the
groupID commit to the whole genesis TX instead of just the minimal source of entropy (one genesis transaction’s prevout and genesis output index) gives more “bang for the buck” and the “buck” (cost) is less than a single signature verification per genesis output, while benefits can be perpetually enjoyed by application developers and their users.
With all these said, having both increases complexity and can be a maintenance and robustness burden that node implementations are unwilling to bear, so we are looking for wider input on how to balance these aspects.
Detached Proofs Roll-out
The conversation moved on to discuss how exactly to roll out detached proofs without breaking the TX format which is seen as a no-go.
It was agreed that the least-invasive way is to change the TXID function so that it compresses input unlocking script field into a hash of itself.
The hash would never be recorded anywhere, it would be computed on-the-fly by upgraded software.
Inputs MUST opt-in to be compressed either through some opcode or a bool PFX on the inputs, otherwise existing Script contracts that rely on reconstructing TXID would break.
Problem would be that non-upgraded software obtaining a “raw” TX wouldn’t compute the correct TXID anymore and would find the TX invalid.
Solution would be to upgrade node APIs so that the rawtransaction call returns the TX with compressed inputs, while a new API endpoint would be used by upgraded software, quoting imaginary_username:
something like that, or op_hashedproof w/e
and then when applications ask for rawtransaction, give them the tx with hash but not the detached proof, so legacy apps won’t freak out
and newer apps who do want the detached proof can get it via a new command like rawtransactionproof
Appendix - Impact on Discussed CHIPs
- Detached Proofs can be extracted to a standalone CHIP from PMv3 CHIP, or PMv3 CHIP itself can be updated accordingly.
This would enable inputs to opt-in for having themselves compressed on-the-fly and would enable the “N-1” proving method in a non-breaking way.
- Unforgeable Groups (CHIP) will enable native P2PKH tokens and the “N+1” proving method.
The “NFT” and “satoshi tokens” group types will be dropped.
