Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 11588FB3 for ; Thu, 23 May 2019 22:01:13 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-it1-f177.google.com (mail-it1-f177.google.com [209.85.166.177]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E074A829 for ; Thu, 23 May 2019 22:01:11 +0000 (UTC) Received: by mail-it1-f177.google.com with SMTP id m140so10832646itg.2 for ; Thu, 23 May 2019 15:01:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blockstream.io; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZhDjm/N1dg8ZZq29aVNUJK3cGhI2zF1wDFlwLn3TcNs=; b=HE+AE5KHXihz1RgSG1y9Q1ECKqGGKTbeQjY+wP6yL1mP22jZlpb/EcZ3YaUxt7FGY5 rhLZUG+E7MngAmt7f8Ccv3PLhTa6eOUZJCoqHAKTv8hC8+C4km2aPpuDyMqtp4T33RzP ECYrwrW7TSCQmguUcMfXDZnx3eh/Avii8jqPM= 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:cc; bh=ZhDjm/N1dg8ZZq29aVNUJK3cGhI2zF1wDFlwLn3TcNs=; b=JjjmvU6ZlG0ueaOe7sGWbTD+pPt+7adQO0GxdkEQJxqm7fK47mPPo9d1lRzFLCf3uh /Z0H1e6RlK8vjGSofVgQ9gPurPPG4HAgjc5wNBTONJaZEyYtZ2yPAUYOyXBWc3wQXk9M 8IqWBsG6IBcKYOoLALREmQL7n5Eg+dCmacwCrk8vw6hIWNnx/gRpAlaANlunS14GxZIR xtYj7EhHwQeQjvJO4/meX609OnE9x4YaqBmgGFNupSxwFYi2sXL5ilkyJN7jqXvjZOgy aPnHSGeqZZOlFx3SWGXkZfXtL/TvdqQBQO/Ts65HLEZn6o3up43fFvlmPO2BsKKSMt08 piTQ== X-Gm-Message-State: APjAAAW50HBuwKG+U+WxjTDisWl8AFFbhraZeO6anzhS+OQzCfi4exuh YwdiR9BRklcOhllqoWSNiz+Fn5ryqdWQIsvSz7+WL7u1 X-Google-Smtp-Source: APXvYqzw871B39kZLh2FY1S/RZ5g+WiEZs3epiTq4QisYjJMg8eHZz9Hx02dyMKV1e1kdC4WHEB2caUO/vJqXgh7SkQ= X-Received: by 2002:a05:660c:50:: with SMTP id p16mr14578784itk.146.1558648871075; Thu, 23 May 2019 15:01:11 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Russell O'Connor" Date: Thu, 23 May 2019 18:00:59 -0400 Message-ID: To: Jimmy Song Content-Type: multipart/alternative; boundary="0000000000004a5be9058995383f" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, 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: Fri, 24 May 2019 14:39:19 +0000 Cc: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2019 22:01:13 -0000 --0000000000004a5be9058995383f Content-Type: text/plain; charset="UTF-8" Hi Jimmy, The message could really be anything. For example, in discreet log contracts, AFAIU, you might have a specific public key from a trusted third party (the Oracle) that is signs the closing price of corn in BTC on 2019-05-23 with a particular nonce dedicated to that product-date pair, in which case the message would be the price expressed in binary. In the case of amortized secure multiparty computations, the message is protocol specific binary data that consists of a counter (or counters), concatenated with shares of secret data that is used to construct the result of the multiparty computation. In the case of transaction reflection, the message would be a duplicate copy of the tapscript signed transaction data (about 244 bytes of data plus a 64 byte prefix). As you note, the message is likely to constructed from a value computed from a mix of witness and committed data, though the message might be pure witness data, as in the discreet log contract example. In that the discreet log contract example, you'd probably duplicate the integer value and do further processing (e.g. compare it to some other committed value). On Thu, May 23, 2019 at 1:36 PM Jimmy Song wrote: > 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 >> > --0000000000004a5be9058995383f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jimmy,

The message co= uld really be anything.=C2=A0 For example, in discreet log contracts, AFAIU= , you might have a specific public key from a trusted third party (the Orac= le) that is signs the closing price of corn in BTC on 2019-05-23 with a par= ticular nonce dedicated to that product-date pair, in which case the messag= e would be the price expressed in binary.=C2=A0 In the case of amortized se= cure multiparty computations, the message is protocol specific binary data = that consists of a counter (or counters), concatenated with shares of secre= t data that is used to construct the result of the multiparty computation.= =C2=A0 In the case of transaction reflection, the message would be a duplic= ate copy of the tapscript signed transaction data (about 244 bytes of data = plus a 64 byte prefix).

As you note, the messa= ge is likely to constructed from a value computed from a mix of witness and= committed data, though the message might be pure witness data, as in the d= iscreet log contract example.=C2=A0 In that the discreet log contract examp= le, you'd probably duplicate the integer value and do further processin= g (e.g. compare it to some other committed value).

=
On Thu, Ma= y 23, 2019 at 1:36 PM Jimmy Song <jaejoon@gmail.com> wrote:
Hi Russell,

This is probably a dumb question, but I'd like to get some clari= ty on your proposal.

OP_CHECKSIGFROMSTACKVERIFY wo= uld pop off a signature, message and pubkey. Presumably, the message would = then have to get constructed as part of the Script execution. What would su= ch a message look like? What, in other words, would you be signing and woul= d that be similar to what signatures sign now? Would it be a single blob th= at incorporates all the input/output information in some hashed manner (lik= e 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 A= M Russell O'Connor via bitcoin-dev <bitcoin-dev@lists.linuxfoundatio= n.org> wrote:
Recently there have been some tapscript proposals, SIGH= ASH_ANYPREVOUT and OP_CHECKOUTPUTHASHVERIFY, that aim 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 Bitco= in Script and language features.

Bitcoin Script ap= pears designed to be a flexible programmable system that provides generic f= eatures to be composed to achieve various purposes.=C2=A0 Thus, when we des= ign new language features for Script, we should be striving, as much as pos= sible, to similarly build general purpose tools which can in turn be used = for a variety of purposes.

I feel the SIGHASH_ANYP= REVOUT and OP_CHECKOUTPUTHASHVERIFY proposals fail to achieve these design = goals.=C2=A0 They are both are designed with very narrow applications in mi= nd, while also going out of their way to extend the semantic domain of the = interpretation of Bitcoin operations in new ways that complicate their spec= ification.=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 signa= ture types.=C2=A0 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.=C2=A0 OP_CAT pops t= wo byte arrays off the stack and pushes their concatenation back onto the s= tack.=C2=A0 OP_CHECKSIGFROMSTACKVERIFY pops a signature, message, and pubke= y off the stack and performs a bip-schnorr verification on the SHA256 hash = of the message.

In concert, these two operatio= ns enable:

* Oracle signature verification, includ= ing discrete log contracts.
* Amortized secure multiparty computa= tions (see "Amortizing Secure Computation with Penalties" by Kuma= resan and Bentov).
* Transaction introspection including:
+=C2= =A0Simulated 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 s= cripts to see if they are among a set of predefined values or verify the ou= tput hash.

and presumably more applications as= well.

For better or for worse, without an OP_= PUBKEYTWEEK operation available, the more interesting recursive-covenants r= emain 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 accomplish= ed by two straightforward opcodes whose semantics are pure computational op= erations on stack values.=C2=A0 The only semantic side-effect is that OP_CH= ECKSIGFROMSTACKVERIFY would count towards the existing 'sigops_passed&#= 39; count.=C2=A0 Moreover, I feel that adding these operations does not pre= clude 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 tr= uly embodies what is meant by "programmable money".
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--0000000000004a5be9058995383f--