summaryrefslogtreecommitdiff
path: root/d0/f92df9895b3b7c1ac6bd8d2c8dfc82a4911ed0
diff options
context:
space:
mode:
authorJimmy Song <jaejoon@gmail.com>2019-05-23 12:36:19 -0500
committerbitcoindev <bitcoindev@gnusha.org>2019-05-23 17:36:36 +0000
commit83f4c0ae675db4f97e21b129e014f15bcc73c751 (patch)
tree4926deaa97227f350f0d65a39b89a329ceb47667 /d0/f92df9895b3b7c1ac6bd8d2c8dfc82a4911ed0
parent2eca8bc3ee09c96e7aa6642022543283efc0fc2d (diff)
downloadpi-bitcoindev-83f4c0ae675db4f97e21b129e014f15bcc73c751.tar.gz
pi-bitcoindev-83f4c0ae675db4f97e21b129e014f15bcc73c751.zip
Re: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK
Diffstat (limited to 'd0/f92df9895b3b7c1ac6bd8d2c8dfc82a4911ed0')
-rw-r--r--d0/f92df9895b3b7c1ac6bd8d2c8dfc82a4911ed0240
1 files changed, 240 insertions, 0 deletions
diff --git a/d0/f92df9895b3b7c1ac6bd8d2c8dfc82a4911ed0 b/d0/f92df9895b3b7c1ac6bd8d2c8dfc82a4911ed0
new file mode 100644
index 000000000..7b2f2a84d
--- /dev/null
+++ b/d0/f92df9895b3b7c1ac6bd8d2c8dfc82a4911ed0
@@ -0,0 +1,240 @@
+Return-Path: <jaejoon@gmail.com>
+Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
+ [172.17.192.35])
+ by mail.linuxfoundation.org (Postfix) with ESMTPS id AFDE6F0A
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Thu, 23 May 2019 17:36:36 +0000 (UTC)
+X-Greylist: whitelisted by SQLgrey-1.7.6
+Received: from mail-vs1-f52.google.com (mail-vs1-f52.google.com
+ [209.85.217.52])
+ by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BE91287D
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Thu, 23 May 2019 17:36:35 +0000 (UTC)
+Received: by mail-vs1-f52.google.com with SMTP id c24so4089239vsp.7
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Thu, 23 May 2019 10:36:35 -0700 (PDT)
+DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
+ h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
+ bh=KmeA6I4FoQeOE/zbt5K4ykl0pP3UtekncJ7OuKUix2Q=;
+ b=bsk3o5rFk5xy5TP+Amruhl77cg8OgTxSsrtj66vdO0yCCai8GOse9/smTo59qa1Y8r
+ zGT+yAtPDC4kMNo47yweTxH/bd8lvbQxfiP0XZiVPgsjem6wistY2whtqRQIZpNFP73F
+ JCmS69OZvPWRDcMMJWHeoWs2P7tJKJXlEY1UTAS3WQ+xzca8RWbg5HNZJ7PH+9tPhWDb
+ tBTMujRqkLbHsMPEkpRgYFYekKZBK/g7LIagQuu2LjRGrJ4y9tXaxLI/k7Hlm7KbCRQR
+ wLy4nFNahETNF3svcXquTTMlsir+nEU8NglqjbSZe6nHMQtbgYUlA/yonxjAxie4Dc9q
+ csGw==
+X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
+ d=1e100.net; s=20161025;
+ h=x-gm-message-state:mime-version:references:in-reply-to:from:date
+ :message-id:subject:to;
+ bh=KmeA6I4FoQeOE/zbt5K4ykl0pP3UtekncJ7OuKUix2Q=;
+ b=GTTASsBMT9b9E5l5mo5bQww+Cgr7jKhT/sREBMsohwWp/tC0sF3jLxTf4HWZ33AXDA
+ NRPtEOXZaLp+TTvdQEEIzqG0foonrC3OO0Aa/aP5PWZ+hxvwuUCbuW584YLQziOlLJo1
+ ZvzcRU0/XWJSdkQYTbFeavnNtMOxGgMEsi2EtLgsJuafg4MkC94TeTVA0hC5afTYid1W
+ kv7bsJbvmTmKY85fPZ/L5G2jCAVYt9f2LXZjsHvHmviOe1fpLBhyXHvbDnSmasQ+rBc8
+ 8Ce+t+zIfw76S+L46rvUtmQAx4G8BxYt6Ok/4pTg8Y7hLOjBnZ1HS5v/hxINXt+RqDp4
+ 79vA==
+X-Gm-Message-State: APjAAAVYkktJFAsmQqVPm6FN/EpkOIu3ZWs0pWD/WEWPLF5o8oRzZosR
+ Ne/Tt7TncVMG858qm1EUl9KfX7lfbpo9uWBDGgI=
+X-Google-Smtp-Source: APXvYqwe6BzrdhxFsvYheKP943LbG3nalNgV/C3KolBzObgDtWUFmU6s/sTMsNJCDXNbRsSLM/FM6p/jnRsQ/HJP6gw=
+X-Received: by 2002:a67:ed55:: with SMTP id m21mr47062500vsp.201.1558632994711;
+ Thu, 23 May 2019 10:36:34 -0700 (PDT)
+MIME-Version: 1.0
+References: <CAMZUoK=0YhqxguphmaKsMGZCy_NYVE_i53qGBfPVES=GAYTy1g@mail.gmail.com>
+In-Reply-To: <CAMZUoK=0YhqxguphmaKsMGZCy_NYVE_i53qGBfPVES=GAYTy1g@mail.gmail.com>
+From: Jimmy Song <jaejoon@gmail.com>
+Date: Thu, 23 May 2019 12:36:19 -0500
+Message-ID: <CAJR7vkqogCzy8_SpCxcAhnEdkS6DRKaDtvJa8Wc-TNGsCcjM5g@mail.gmail.com>
+To: "Russell O'Connor" <roconnor@blockstream.io>,
+ Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
+Content-Type: multipart/alternative; boundary="000000000000fc2edc0589918517"
+X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
+ DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
+ RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
+X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
+ smtp1.linux-foundation.org
+X-Mailman-Approved-At: Thu, 23 May 2019 18:31:16 +0000
+Subject: Re: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK
+X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
+X-Mailman-Version: 2.1.12
+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: Thu, 23 May 2019 17:36:36 -0000
+
+--000000000000fc2edc0589918517
+Content-Type: text/plain; charset="UTF-8"
+
+Hi Russell,
+
+This is probably a dumb question, but I'd like to get some clarity on your
+proposal.
+
+OP_CHECKSIGFROMSTACKVERIFY would pop off a signature, message and pubkey.
+Presumably, the message would then have to get constructed as part of the
+Script execution. What would such a message look like? What, in other
+words, would you be signing and would that be similar to what signatures
+sign now? Would it be a single blob that incorporates all the input/output
+information in some hashed manner (like BIP143)? Or would you need separate
+signatures for different parts of the transaction? Or is it something more
+complicated like aggregating multiple signatures over different parts of
+the transaction?
+
+Best,
+
+Jimmy
+
+On Thu, May 23, 2019 at 8:35 AM Russell O'Connor via bitcoin-dev <
+bitcoin-dev@lists.linuxfoundation.org> wrote:
+
+> Recently there have been some tapscript proposals, SIGHASH_ANYPREVOUT and
+> OP_CHECKOUTPUTHASHVERIFY, that aim to enable particular new features for
+> Bitcoin via new Script operations. However, I think that these proposals
+> miss the mark when it comes to how they approach Bitcoin Script and
+> language features.
+>
+> Bitcoin Script appears designed to be a flexible programmable system that
+> provides generic features to be composed to achieve various purposes.
+> Thus, when we design new language features for Script, we should be
+> striving, as much as possible, to similarly build general purpose tools
+> which can in turn be used for a variety of purposes.
+>
+> I feel the SIGHASH_ANYPREVOUT and OP_CHECKOUTPUTHASHVERIFY proposals fail
+> to achieve these design goals. They are both are designed with very narrow
+> applications in mind, while also going out of their way to extend the
+> semantic domain of the interpretation of Bitcoin operations in new ways
+> that complicate their specification. In the case of SIGHASH_ANYPREVOUT,
+> the semantic domain is extended by adding new counters to track the use of
+> various v0 and v2 signature types. In the case of
+> OP_CHECKOUTPUTHASHVERIFY, it employs a new context-sensitive operation that
+> peeks at the value of surrounding opcodes.
+>
+> Instead, I propose that, for the time being, we simply implement OP_CAT
+> and OP_CHECKSIGFROMSTACKVERIFY. OP_CAT pops two byte arrays off the stack
+> and pushes their concatenation back onto the stack.
+> OP_CHECKSIGFROMSTACKVERIFY pops a signature, message, and pubkey off the
+> stack and performs a bip-schnorr verification on the SHA256 hash of the
+> message.
+>
+> In concert, these two operations enable:
+>
+> * Oracle signature verification, including discrete log contracts.
+> * Amortized secure multiparty computations (see "Amortizing Secure
+> Computation with Penalties" by Kumaresan and Bentov).
+> * Transaction introspection including:
+> + Simulated SIGHASH_ANYPREVOUT, which are necessarily chaperoned simply
+> by the nature of the construction.
+> + Decide if a transaction has exactly one input or not. (etc.)
+> + Weak covenants, which can verify output scripts to see if they are among
+> a set of predefined values or verify the output hash.
+>
+> and presumably more applications as well.
+>
+> For better or for worse, without an OP_PUBKEYTWEEK operation available,
+> the more interesting recursive-covenants remain largely out of reach, with
+> the exception of a recursive covenant that is only able to send back to its
+> own address, possibly abusing its own TXO value as a state variable.
+>
+> All this is accomplished by two straightforward opcodes whose semantics
+> are pure computational operations on stack values. The only semantic
+> side-effect is that OP_CHECKSIGFROMSTACKVERIFY would count towards the
+> existing 'sigops_passed' count. Moreover, I feel that adding these
+> operations does not preclude adding more specialized opcodes in the future
+> as an optimization for whatever popular constructions come up, once we know
+> what those are.
+>
+> I feel that this style of generic building blocks truly embodies what is
+> meant by "programmable money".
+> _______________________________________________
+> bitcoin-dev mailing list
+> bitcoin-dev@lists.linuxfoundation.org
+> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
+>
+
+--000000000000fc2edc0589918517
+Content-Type: text/html; charset="UTF-8"
+Content-Transfer-Encoding: quoted-printable
+
+<div dir=3D"ltr">Hi Russell,<div><br></div><div>This is probably a dumb que=
+stion, but I&#39;d like to get some clarity on your proposal.</div><div><br=
+></div><div>OP_CHECKSIGFROMSTACKVERIFY would pop off a signature, message a=
+nd pubkey. Presumably, the message would then have to get constructed as pa=
+rt of the Script execution. What would such a message look like? What, in o=
+ther words, would you be signing and would that be similar to what signatur=
+es sign now? Would it be a single blob that incorporates all the input/outp=
+ut information in some hashed manner (like BIP143)? Or would you need separ=
+ate signatures for different parts of the transaction? Or is it something m=
+ore complicated like aggregating multiple signatures over different parts o=
+f the transaction?</div><div><br></div><div>Best,</div><div><br></div><div>=
+Jimmy</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"g=
+mail_attr">On Thu, May 23, 2019 at 8:35 AM Russell O&#39;Connor via bitcoin=
+-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d=
+ev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"g=
+mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
+,204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"l=
+tr"><div dir=3D"ltr"><div dir=3D"ltr"><div>Recently there have been some ta=
+pscript proposals, SIGHASH_ANYPREVOUT and OP_CHECKOUTPUTHASHVERIFY, that ai=
+m to enable particular new features for Bitcoin via new Script operations.=
+=C2=A0 However, I think that these proposals miss the mark when it comes to=
+ how they approach Bitcoin Script and language features.</div><div><br></di=
+v><div>Bitcoin Script appears designed to be a flexible programmable system=
+ that provides generic features to be composed to achieve various purposes.=
+=C2=A0 Thus, when we design new language features for Script, we should be =
+striving, as much as possible, to similarly build general purpose tools wh=
+ich can in turn be used for a variety of purposes.</div><div><br></div><div=
+>I feel the SIGHASH_ANYPREVOUT and OP_CHECKOUTPUTHASHVERIFY proposals fail =
+to achieve these design goals.=C2=A0 They are both are designed with very n=
+arrow applications in mind, while also going out of their way to extend the=
+ semantic domain of the interpretation of Bitcoin operations in new ways th=
+at complicate their specification.=C2=A0 In the case of SIGHASH_ANYPREVOUT,=
+ the semantic domain is extended by adding new counters to track the use of=
+ various v0 and v2 signature types.=C2=A0 In the case of OP_CHECKOUTPUTHASH=
+VERIFY, it employs a new context-sensitive operation that peeks at the valu=
+e of surrounding opcodes.</div><div><br></div><div>Instead, I propose that,=
+ for the time being, we simply implement OP_CAT and OP_CHECKSIGFROMSTACKVER=
+IFY.=C2=A0 OP_CAT pops two byte arrays off the stack and pushes their conca=
+tenation back onto the stack.=C2=A0 OP_CHECKSIGFROMSTACKVERIFY pops a signa=
+ture, message, and pubkey off the stack and performs a bip-schnorr verifica=
+tion on the SHA256 hash of the message.<br></div><div><br></div><div>In con=
+cert, these two operations enable:</div><div><br></div><div>* Oracle signat=
+ure verification, including discrete log contracts.</div><div>* Amortized s=
+ecure multiparty computations (see &quot;Amortizing Secure Computation with=
+ Penalties&quot; by Kumaresan and Bentov).</div><div>* Transaction introspe=
+ction including:<br></div><div><a class=3D"gmail_plusreply" id=3D"gmail-m_-=
+496123689612879534gmail-plusReplyChip-0">+</a>=C2=A0Simulated SIGHASH_ANYPR=
+EVOUT, which are necessarily chaperoned simply by the nature of the constru=
+ction.<br></div><div><a class=3D"gmail_plusreply" id=3D"gmail-m_-4961236896=
+12879534gmail-plusReplyChip-1">+</a> Decide if a transaction has exactly on=
+e input or not. (etc.)</div><div>+ Weak covenants, which can verify output =
+scripts to see if they are among a set of predefined values or verify the o=
+utput hash.<br></div><div><br></div><div>and presumably more applications a=
+s well.<br></div><div><br></div><div>For better or for worse, without an OP=
+_PUBKEYTWEEK operation available, the more interesting recursive-covenants =
+remain largely out of reach, with the exception of a recursive covenant tha=
+t is only able to send back to its own address, possibly abusing its own TX=
+O value as a state variable.</div><div><br></div><div>All this is accomplis=
+hed by two straightforward opcodes whose semantics are pure computational o=
+perations on stack values.=C2=A0 The only semantic side-effect is that OP_C=
+HECKSIGFROMSTACKVERIFY would count towards the existing &#39;sigops_passed&=
+#39; count.=C2=A0 Moreover, I feel that adding these operations does not pr=
+eclude adding more specialized opcodes in the future as an optimization for=
+ whatever popular constructions come up, once we know what those are.<br></=
+div><div><br></div><div>I feel that this style of generic building blocks t=
+ruly embodies what is meant by &quot;programmable money&quot;.<br></div></d=
+iv></div></div></div></div>
+_______________________________________________<br>
+bitcoin-dev mailing list<br>
+<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
+bitcoin-dev@lists.linuxfoundation.org</a><br>
+<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
+rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
+man/listinfo/bitcoin-dev</a><br>
+</blockquote></div>
+
+--000000000000fc2edc0589918517--
+