@harding Thank you for the feedback! I’ll focus on your second point about introspection, as that is perhaps more interesting. I’ll come back to your first point later when I’ve had more time to gather my thoughts.
For point 2 (additional introspection opcodes), this is heavily discussed. The novelty in your proposal is potentially only allowing certain types of introspection during delegation rather than original script creation. Do you have any examples of how that might be useful?
Sure! Full introspection during “delegation” would be useful for non-interactive single-transaction protocols where a user needs to commit to many possible transaction templates with a single signature. This is particularly valuable if we want two-sided bitcoin-native markets to develop without enabling recursive covenants.
The bidding problem
Let’s suppose that there exists some fungible asset A held across N UTXOs, transferrable according to some metaprotocol. Ideally, this would represent equity in some bitcoin-aligned public company, but for now, let’s assume it is a token that already exists, like a rune.
Suppose that a user wishes to make an offer to buy X_A of asset A for b bitcoin, which anyone can accept if they own a UTXO with sufficient A. Today, the bidder would need to produce separately signed PSBTs for every offer they wish to make, using sighash ALL. This is impractical without a hot wallet, if there are thousands of UTXOs they need to bid on.
For this reason, non-interactive bitcoin markets are one-sided. If we want to see two-sided markets without trusted escrow agents, we need introspection.
Why introspection helps
Suppose that an introspection opcode exists. Let’s put delegation / subscripting aside for the moment and assume this opcode can be used anywhere. As we’ll see, introspection would make non-interactive buy offers practical, by using a single signature to commit to thousands of possible transaction templates.
Here’s how it might work:
- The bidder creates a staging transaction T_0 spending to a taproot output, which anyone can spend by satisfying any one of thousands of possible locking scripts.
- Using an introspection opcode, each locking script commits to a single transaction template, spending from a UTXO holding A. The template sends X_A to the bidder’s output and lets the seller take b bitcoin from the bidder’s input.
- The bidder broadcasts T_0 alongside the data necessary for anyone to derive the locking scripts.
- A seller accepts the offer by signing a second transaction T_1, spending from T_0 by revealing the locking script it satisfies.
Avoiding recursive covenants
The approach outlined above has two problems:
-
It requires two transactions, rather than one.
-
It uses functionality that would enable recursive covenants.
Any opcode that can 1) encumber a UTXO, and 2) enable full introspection (including of the spent outpoints) can enable recursive covenants. On the other hand, an opcode that cannot encumber a UTXO cannot enable multi-transaction covenants.
A locking subscript merely adds spending conditions to a transaction input after it has been signed. It is impossible for a UTXO to commit to these conditions ahead of time. Therefore, we can safely turn on introspection during “delegation” / subscripting without enabling recursive covenants.
In summary, “delegated” introspection would add meaningful expressivity to PSBT offers and facilitate the creation of non-interactive two-sided bitcoin-native markets, without enabling recursive covenants.
Follow up
I thought I might add a few additional “minor” use cases that would benefit from introspection during delegation / subscripting:
-
Non-interactive multi-input offers: If Alice wishes to make an offer to sell exactly X_A held across two or more of her UTXOs, which anyone can accept, she needs to make two transactions today (one to consolidate her balances, and one to make the offer). If she can introspect, however, through delegation / locking subscripts, each input can commit to the presence of the other, and she can make her offer in a single transaction.
-
Non-interactive multi-output offers: I understand that proposals have been made to add new types of sighashes, like SIGHASH_GROUP. Enabling introspection during delegation / subscripting could provide a highly generic alternative.
I hope that’s helpful! Let me know if any of what I said would benefit from clarification.