summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAnthony Towns <aj@erisian.com.au>2022-02-02 11:28:49 +1000
committerbitcoindev <bitcoindev@gnusha.org>2022-02-02 01:29:02 +0000
commit1e0d4a25f89f45a24bcb0ed32ece60b9736b3145 (patch)
tree880f07c6bf45a509cb1bf2050d98c715cc854ee5
parentecf7518e101fd0e3e97ba5fab3c44254dc7be086 (diff)
downloadpi-bitcoindev-1e0d4a25f89f45a24bcb0ed32ece60b9736b3145.tar.gz
pi-bitcoindev-1e0d4a25f89f45a24bcb0ed32ece60b9736b3145.zip
Re: [bitcoin-dev] Why CTV, why now?
-rw-r--r--15/523c1053da44717838a6f855e133526b6ae1cb120
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/
+
+