diff options
author | Anthony Towns <aj@erisian.com.au> | 2022-02-02 11:28:49 +1000 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2022-02-02 01:29:02 +0000 |
commit | 1e0d4a25f89f45a24bcb0ed32ece60b9736b3145 (patch) | |
tree | 880f07c6bf45a509cb1bf2050d98c715cc854ee5 | |
parent | ecf7518e101fd0e3e97ba5fab3c44254dc7be086 (diff) | |
download | pi-bitcoindev-1e0d4a25f89f45a24bcb0ed32ece60b9736b3145.tar.gz pi-bitcoindev-1e0d4a25f89f45a24bcb0ed32ece60b9736b3145.zip |
Re: [bitcoin-dev] Why CTV, why now?
-rw-r--r-- | 15/523c1053da44717838a6f855e133526b6ae1cb | 120 |
1 files changed, 120 insertions, 0 deletions
diff --git a/15/523c1053da44717838a6f855e133526b6ae1cb b/15/523c1053da44717838a6f855e133526b6ae1cb new file mode 100644 index 000000000..07bb031c3 --- /dev/null +++ b/15/523c1053da44717838a6f855e133526b6ae1cb @@ -0,0 +1,120 @@ +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/ + + |