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

From: Jeremy Rubin <jeremy.l.rubin@gmail•com>
To: Anthony Towns <aj@erisian•com.au>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Cc: Jeremy <jlrubin@mit•edu>
Subject: Re: [bitcoin-dev] Why CTV, why now?
Date: Tue, 1 Feb 2022 17:43:38 -0800	[thread overview]
Message-ID: <CAD5xwhgCNbQkCMWRY_saAfQRXUXo7+DUHQkqv_um6UG_E0dNpA@mail.gmail.com> (raw)
In-Reply-To: <20220202012849.GA5140@erisian.com.au>

[-- Attachment #1: Type: text/plain, Size: 3266 bytes --]

I agree this emulation seems sound but also tap out at how the CT stuff
works with this type of covenant as well.

Happy hacking!

On Tue, Feb 1, 2022, 5:29 PM Anthony Towns via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:

> 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/
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 4374 bytes --]