Re: [bitcoin-dev] Why CTV, why now?

[Anthony Towns <aj@erisian.com.au>]

On Wed, Jan 05, 2022 at 02:44:54PM -0800, Jeremy via bitcoin-dev wrote:
> CTV was an output of my personal "research program" on how to make simple
> covenant types without undue validation burdens. It is designed to be the
> simplest and least risky covenant specification you can do that still
> delivers sufficient flexibility and power to build many useful applications.

I believe the new elements opcodes [0] allow simulating CTV on the liquid
blockchain (or liquid-testnet [1] if you'd rather use fake money but not
use Jeremy's CTV signet). It's very much not as efficient as having a
dedicated opcode, of course, but I think the following script template
would work:

INSPECTVERSION SHA256INITIALIZE
INSPECTLOCKTIME SHA256UPDATEE
INSPECTNUMINPUTS SCRIPTNUMTOLE64 SHA256UPDATE
INSPECTNUMOUTPUTS SCRIPTNUMTOLE64 SHA256UPDATE

PUSHCURRENTINPUTINDEX SCRIPTNUMTOLE64 SHA256UPDATE
PUSHCURRENTINPUTINDEX INSPECTINPUTSEQUENCE SCRIPTNUMTOLE64 SHA256UPDATE

{ for <x> in 0..<numoutputs-1>
<x> INSPECTOUTPUTASSET CAT SHA256UPDATE
<x> INSPECTOUTPUTVALUE DROP SIZE SCRIPTNUMTOLE64 SWAP CAT SHA256UPDATE
<x> INSPECTOUTPUTNONCE SIZE SCRIPTNUMTOLE64 SWAP CAT SHA256UPDATE
<x> INSPECTOUTPUTSCRIPTPUBKEY SWAP SIZE SCRIPTNUMTOLE64 SWAP CAT CAT SHA256UPDATE
}

SHA256FINALIZE <expectedhash> EQUAL

Provided NUMINPUTS is one, this also means the txid of the spending tx is
fixed, I believe (since these are tapoot only opcodes, scriptSig
malleability isn't possible); if NUMINPUTS is greater than one, you'd
need to limit what other inputs could be used somehow which would be
application specific, I think.

I think that might be compatible with confidential assets/values, but
I'm not really sure.

I think it should be possible to use a similar approach with
CHECKSIGFROMSTACK instead of "<expectedhash> EQUAL" to construct APO-style
signatures on elements/liquid. Though you'd probably want to have the
output inspction blocks wrapped with "INSPECTNUMOUTPUTS <x> GREATERTHAN
IF .. ENDIF". (In that case, beginning with "PUSH[FakeAPOSig] SHA256
DUP SHA256INITIALIZE SHA256UPDATE" might also be sensible, so you're
not signing something that might be misused in a different context later)


Anyway, since liquid isn't congested, and mostly doesn't have lightning
channels built on top of it, probably the vaulting application is the
only interesting one to build on top on liquid today? There's apparently
about $120M worth of BTC and $36M worth of USDT on liquid, which seems
like it could justify some vault-related work. And real experience with
CTV-like constructs seems like it would be very informative.

Cheers,
aj

[0] https://github.com/ElementsProject/elements/blob/master/doc/tapscript_opcodes.md
[1] https://liquidtestnet.com/