From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 7EB41B88 for ; Fri, 24 May 2019 03:51:20 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch [185.70.40.135]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0F2E9F4 for ; Fri, 24 May 2019 03:51:18 +0000 (UTC) Date: Fri, 24 May 2019 03:51:13 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1558669876; bh=YnDKj+mLjRct+CzsepcHGwBUA0cdxpISp2XcdIyhm/M=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=D9G/RGXDDpVFoxkF2uKg7XKRpJc/o7Jf53PPUBaWhxCEtFvr1F33YBaxWXfx9UG4v W68SZlG72f7Ipu6y7g2LDJP+rBuA2XVmwer3IICPLy2pVAjqh0cgyK5YgCkbwAg/vG uDJgBwLEyFhaZ7BnvL9rNP67cb1NYvJ4N4Q2JbvM= To: Jimmy Song , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL, RCVD_IN_DNSWL_LOW 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 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: Fri, 24 May 2019 03:51:20 -0000 Good morning Jimmy, =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Friday, May 24, 2019 1:36 AM, Jimmy Song via bitcoin-dev wrote: > Hi Russell, > > This is probably a dumb question, but I'd like to get some clarity on you= r 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 no= w? Would it be a single blob that incorporates all the input/output informa= tion in some hashed manner (like BIP143)? Or would you need separate signat= ures for different parts of the transaction? Or is it something more compli= cated like aggregating multiple signatures over different parts of the tran= saction? In order to use `OP_CHECKSIGFROMSTACK` work to allow transaction introspect= ion, the message to be signed would be the equivalent of the sighash digest= using `SIGHASH_ALL`. As a general pattern, if you want a SCRIPT that imposes some rule on some f= ield in the sighash digest of the transaction: 1. You would require that the transaction be split into three parts, with = those parts provided in the witness stack. One would be "data before the field", then "the field", then "data afte= r the field". 2. In addition, you would require a signature for the transaction in addit= ion to the transaction parts above. 3. You would ensure that "data before the field" is the correct size, so t= hat you know "the field" is at the correct location in the transaction. Alternately you might need to also introspect some other fields in orde= r to ensure other details like number of inputs, number of outputs, value o= f inputs etc. etc. are what you expect. 4. You would check that the given signature is `SIGHASH_ALL` (most easily = by checking its size --- proposed Schnorr signatures have a fixed size, and= the lack of an extra sighash flags byte means `SIGHASH_ALL` by default, so= if the signature is exactly the fixed Schnorr signature size, it is `SIGHA= SH_ALL`). 5. You would use normal `OP_CHECKSIGVERIFY` to ensure that the signature s= igns the actual transaction. 6. You would concatenate the supposed parts of the transaction together an= d use `OP_CHECKSIGFROMSTACKVERIFY` to ensure that the signature *also* is v= alid for that. Since you know the signature is valid for the transaction itself, if it= *also* is valid for this, then the concatenation of the input "data before= the field", "the field", and "data after the field" is exactly the same si= ghash digest as the actual transaction, and thus is accurate to the transac= tion. 7. Finally, you would actually validate the field you want to impose some = rule on. `SIGHASH_ALL` is suggested since it allows you to introspect all fields, bu= t also because ensuring that the signature is indeed a `SIGHASH_ALL` signat= ure is easier (just do the size check). Alternately you can use some other flag, but you would require the signatur= e on the stack to be flagless and concat the flag yourself before using `OP= _CHECKSIGVERIFY`. This mechanism is very general and allows SCRIPT to introspect *any* field = of the transactions. Indeed, one can argue that `OP_CHECKLOCKTIMEVERIFY` and `OP_CHECKSEQUENCEVE= RIFY` are both superfluous in a system with `OP_CAT` and `OP_CHECKSIGFROMST= ACK`. OF course, these operations are significantly more optimized since they do = not require that you quine the transaction. Regards, ZmnSCPxj > > Best, > > Jimmy > > On Thu, May 23, 2019 at 8:35 AM Russell O'Connor via bitcoin-dev wrote: > > > Recently there have been some tapscript proposals, SIGHASH_ANYPREVOUT a= nd OP_CHECKOUTPUTHASHVERIFY, that aim to enable particular new features for= Bitcoin via new Script operations.=C2=A0 However, I think that these propo= sals miss the mark when it comes to how they approach Bitcoin Script and la= nguage features. > > > > Bitcoin Script appears designed to be a flexible programmable system th= at 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 whi= ch can in turn be used for a variety of purposes. > > > > I feel the SIGHASH_ANYPREVOUT and OP_CHECKOUTPUTHASHVERIFY proposals fa= il to achieve these design goals.=C2=A0 They are both are designed with ver= y 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.=C2=A0 In the case of SIGHASH_ANYPREVO= UT, 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_CHECKOUTPUTH= ASHVERIFY, it employs a new context-sensitive operation that peeks at the v= alue of surrounding opcodes. > > > > Instead, I propose that, for the time being, we simply implement OP_CAT= and OP_CHECKSIGFROMSTACKVERIFY.=C2=A0 OP_CAT pops two byte arrays off the = stack and pushes their concatenation back onto the stack.=C2=A0 OP_CHECKSIG= FROMSTACKVERIFY pops a signature, message, and pubkey off the stack and per= forms 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 Comp= utation with Penalties" by Kumaresan and Bentov). > > * Transaction introspection including: > > +=C2=A0Simulated SIGHASH_ANYPREVOUT, which are necessarily chaperoned s= imply 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 am= ong 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 it= s 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.=C2=A0 The only semantic= side-effect is that OP_CHECKSIGFROMSTACKVERIFY would count towards the exi= sting 'sigops_passed' count.=C2=A0 Moreover, I feel that adding these opera= tions 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 i= s meant by "programmable money". > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev