Return-Path: <aj@erisian.com.au>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id AB50CC000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  2 Feb 2022 01:29:02 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 855864035D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  2 Feb 2022 01:29:02 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.62
X-Spam-Level: 
X-Spam-Status: No, score=-1.62 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.276, LOTS_OF_MONEY=0.001,
 SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001]
 autolearn=no autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 2gs2YHp1zuv2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  2 Feb 2022 01:29:01 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 3AD6A40321
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  2 Feb 2022 01:29:01 +0000 (UTC)
Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au)
 by azure.erisian.com.au with esmtpsa (Exim 4.92 #3 (Debian))
 id 1nF4S7-0000EH-HB; Wed, 02 Feb 2022 11:28:57 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
 Wed, 02 Feb 2022 11:28:49 +1000
Date: Wed, 2 Feb 2022 11:28:49 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20220202012849.GA5140@erisian.com.au>
References: <CAD5xwhg-uxvJ4BCEeo5h2BxvCo87xwZ6r7cT-=u5PT9yskpbJQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAD5xwhg-uxvJ4BCEeo5h2BxvCo87xwZ6r7cT-=u5PT9yskpbJQ@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
X-Spam-Score-int: -18
X-Spam-Bar: -
Cc: Jeremy <jlrubin@mit.edu>
Subject: Re: [bitcoin-dev] Why CTV, why now?
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Feb 2022 01:29:02 -0000

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/