From: Anthony Towns <aj@erisian•com.au>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Cc: Jeremy <jlrubin@mit•edu>
Subject: Re: [bitcoin-dev] Why CTV, why now?
Date: Wed, 2 Feb 2022 11:28:49 +1000 [thread overview]
Message-ID: <20220202012849.GA5140@erisian.com.au> (raw)
In-Reply-To: <CAD5xwhg-uxvJ4BCEeo5h2BxvCo87xwZ6r7cT-=u5PT9yskpbJQ@mail.gmail.com>
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/
next prev parent reply other threads:[~2022-02-02 1:29 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-05 22:44 [bitcoin-dev] Why CTV, why now? Was RE: Stumbling into a contentious soft fork activation attempt Jeremy
2022-02-02 1:28 ` Anthony Towns [this message]
2022-02-02 1:43 ` [bitcoin-dev] Why CTV, why now? Jeremy Rubin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220202012849.GA5140@erisian.com.au \
--to=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jlrubin@mit$(echo .)edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox