Rusty Russell on Nostr: I'm a bit slow: to really understand something I usually need to design it myself, ...
I'm a bit slow: to really understand something I usually need to design it myself, then figure out the differences between my ugly creation and someone else's masterpiece. This is particularly hard in the Bitcoin space, where any significant change has to intersect with every other future change we expect (fees will rise and a few bytes will really matter, we never get to deprecate anything and L2 protocols of various kinds are going to be wild).
Consider OP_CHECKTEMPLATEVERIFY, from first principles. Where Script enhancements (introspection) allow you to check "is the tx spending this to the right place?" (which is harder than you'd think in the Bitcoin input/output model!) CTV simplifies this to approximately "is this the right tx?". If you try to design such a thing, you will immediately hit the following hurdles:
1. An opcode which says "you must spend this with the following txid" doesn't work, since you the txid of the spender depends on the txid of the current tx, which depends on the txid of the spender.
2. If you say "ok, let's use the txid, but put zeros in the current input's txid" you solve this, but now you have a validation problem. If every input in a giant tx uses this opcode, you have to rehash the entire tx every time.
3. OP_CTV gets around this by (obviously) not hashing the current input txid, but also hashing the *number* of inputs (not their contents). If that's one, problem solved. If it's not, you are kind of on your own.
4. The minimal solution to this (that I can see) is to hash the txid with *all* the input txids set to all zeroes (call this ztxid). Then hash the XOR of all the input txids bar the current one. You could use either H(H(ztxid) | H(xored-txins)) or H(ztid | xored-txins).
The absolute minimum here is to make this a raw output script. No scripting, it's just "you *will* use this tx to spend this output".
I don't think there's much point getting more complex than this: if you want to be more expressive, we should add introspection opcodes.
Consider OP_CHECKTEMPLATEVERIFY, from first principles. Where Script enhancements (introspection) allow you to check "is the tx spending this to the right place?" (which is harder than you'd think in the Bitcoin input/output model!) CTV simplifies this to approximately "is this the right tx?". If you try to design such a thing, you will immediately hit the following hurdles:
1. An opcode which says "you must spend this with the following txid" doesn't work, since you the txid of the spender depends on the txid of the current tx, which depends on the txid of the spender.
2. If you say "ok, let's use the txid, but put zeros in the current input's txid" you solve this, but now you have a validation problem. If every input in a giant tx uses this opcode, you have to rehash the entire tx every time.
3. OP_CTV gets around this by (obviously) not hashing the current input txid, but also hashing the *number* of inputs (not their contents). If that's one, problem solved. If it's not, you are kind of on your own.
4. The minimal solution to this (that I can see) is to hash the txid with *all* the input txids set to all zeroes (call this ztxid). Then hash the XOR of all the input txids bar the current one. You could use either H(H(ztxid) | H(xored-txins)) or H(ztid | xored-txins).
The absolute minimum here is to make this a raw output script. No scripting, it's just "you *will* use this tx to spend this output".
I don't think there's much point getting more complex than this: if you want to be more expressive, we should add introspection opcodes.