diff options
author | Jimmy Song <jaejoon@gmail.com> | 2019-05-23 12:36:19 -0500 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2019-05-23 17:36:36 +0000 |
commit | 83f4c0ae675db4f97e21b129e014f15bcc73c751 (patch) | |
tree | 4926deaa97227f350f0d65a39b89a329ceb47667 /d0/f92df9895b3b7c1ac6bd8d2c8dfc82a4911ed0 | |
parent | 2eca8bc3ee09c96e7aa6642022543283efc0fc2d (diff) | |
download | pi-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/f92df9895b3b7c1ac6bd8d2c8dfc82a4911ed0 | 240 |
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'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'Connor via bitcoin= +-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d= +ev@lists.linuxfoundation.org</a>> 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 "Amortizing Secure Computation with= + Penalties" 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 '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 "programmable money".<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-- + |