Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 7BF54C000B for ; Wed, 2 Feb 2022 01:43:52 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 5774C8126B for ; Wed, 2 Feb 2022 01:43:52 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBLGfWsMk2DA for ; Wed, 2 Feb 2022 01:43:51 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) by smtp1.osuosl.org (Postfix) with ESMTPS id EF2F281247 for ; Wed, 2 Feb 2022 01:43:50 +0000 (UTC) Received: by mail-lj1-x22f.google.com with SMTP id c15so26652287ljf.11 for ; Tue, 01 Feb 2022 17:43:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=idIhFQG8mK/bicxh2Zi1T5SGNLeMWnjsgp25L2X2fhQ=; b=M+WnUf+6sxCsvoIlLzWGXnDyndUanJv9F1ebaIIIGiW/CO7L3hfYKQEQVfNcv7bRlw A8Yv1JyxAcAaMlPxvsFHEneoVN4FwCMKnfZSlnmObm3/iq6dzSEot9JDVkP37UyTURuA 7dtK6XXEZZnCUFdU2LvvWErkiNNm664tz0yW/9/gd0AtiHG93+iExjpCCjkxjgLxoQxx lzUmSIWmPO7uuqzVaCSnJhSrA6NY/7JUrweV8y3JKS8OzF6QjM3kstAcbIWwdXlXjLEe v5jxGTIyEWjckOPXNvBKTmLBFpqlFmx0906o39yx9fciQCmycahKlSwMkjhP6VYr7V+j krlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=idIhFQG8mK/bicxh2Zi1T5SGNLeMWnjsgp25L2X2fhQ=; b=2w1H9AVcnafVvvhfg7pGY+AHQa8MzmnVfeZtqG6o0q2uVTiE7TVZhES+ASbB3ANgCI RcTsGkyzNKodHG4AVOypubJYkzEfX4mt2AhKDhYFYk5dbmQouJGI7WJY1NDqudrPdKIV JcO+/vjvN9NVmWTU2m90NV9SRgEme3kog+fom7hHSMaK/STZr9nf+ZjKjRn1Mfk7l1C0 X3yR/3+LtisHLx/x6Mb//zbK6QByq2wHB18hiLBpZwWk3pYWSAYYHqtqvdXeAnenGppV VmOV0h9xf7NGbptk4EJZKMhpDjn6pP/7e7ECmHlTIDXWJCTI1cxr8pF7jPN2pT23oTac tSzw== X-Gm-Message-State: AOAM5332WqVYR0OU7ZQEy2Y2eFWaWmi7y2q3NB2/5LjHqlQn8+0HRX0/ uBCrmaoV1GbwcbSuJUjhlrH+qsJYqPeJOhdlJHw= X-Google-Smtp-Source: ABdhPJwvfWfPSrMfFqGnVFlIHCPBVsr8aoSLEjfSLl49yNWFNjnXUJ44qZd4XOfuJ23Ht3ayZM/HMv/uesT/bFYiNYc= X-Received: by 2002:a2e:a5c3:: with SMTP id n3mr9911548ljp.212.1643766228660; Tue, 01 Feb 2022 17:43:48 -0800 (PST) MIME-Version: 1.0 References: <20220202012849.GA5140@erisian.com.au> In-Reply-To: <20220202012849.GA5140@erisian.com.au> From: Jeremy Rubin Date: Tue, 1 Feb 2022 17:43:38 -0800 Message-ID: To: Anthony Towns , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="00000000000027372905d6ff26b1" Cc: Jeremy 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2022 01:43:52 -0000 --00000000000027372905d6ff26b1 Content-Type: text/plain; charset="UTF-8" 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 in 0.. > INSPECTOUTPUTASSET CAT SHA256UPDATE > INSPECTOUTPUTVALUE DROP SIZE SCRIPTNUMTOLE64 SWAP CAT SHA256UPDATE > INSPECTOUTPUTNONCE SIZE SCRIPTNUMTOLE64 SWAP CAT SHA256UPDATE > INSPECTOUTPUTSCRIPTPUBKEY SWAP SIZE SCRIPTNUMTOLE64 SWAP CAT CAT > SHA256UPDATE > } > > SHA256FINALIZE 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 " EQUAL" to construct APO-style > signatures on elements/liquid. Though you'd probably want to have the > output inspction blocks wrapped with "INSPECTNUMOUTPUTS 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 > --00000000000027372905d6ff26b1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree this emulation seems sound but also tap out at ho= w the CT stuff works with this type of covenant as well.
<= br>
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 t= o 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<= br> > delivers sufficient flexibility and power to build many useful applica= tions.

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 no= t
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 SHA256UPDAT= E
<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 cons= truct APO-style
signatures on elements/liquid. Though you'd probably want to have the output inspction blocks wrapped with "INSPECTNUMOUTPUTS <x> GREA= TERTHAN
IF .. ENDIF". (In that case, beginning with "PUSH[FakeAPOSig] SHA= 256
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 light= ning
channels built on top of it, probably the vaulting application is the
only interesting one to build on top on liquid today? There's apparentl= y
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.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev
--00000000000027372905d6ff26b1--