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 E5F99C9F for ; Thu, 23 May 2019 16:59:25 +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 DD28E7FB for ; Thu, 23 May 2019 16:59:24 +0000 (UTC) Date: Thu, 23 May 2019 16:59:15 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1558630762; bh=MWs4f8qv30e7PMlO4x2bVVktmOtJNmFruVpQcPXln2k=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID: From; b=l24xRn5TVrcWPprgKbXs8Wypl5L3ODq0QMoY3EtjdUip7lWUkEhSjTj8GPfIP4S0l UWtfgSL9Ar+BquvBTYpgfn9J0w3agJeIwPuYPnx31Hqehl5CBXQLusXeqBIAnEM9M8 3Pt73vZrUsIdEAO/UHYjREvAmW3Eatx7mx2fo8Q0= To: Russell O'Connor , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: <-doGGpQeidaYIWCJLexeiJPyi1leWSjZ4nMdO6K2CmhnaTLLtJCz4kOTY5stLEuly0qe7TUSYjzqoksbiXPp7IrA-qk0c8Abr_2Nad7ZJks=@protonmail.com> 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: Thu, 23 May 2019 17:02:47 +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: Thu, 23 May 2019 16:59:26 -0000 Good morning Russell, While I am sympathetic to this argument from first principles, as I underst= and it, it requires that provided witness inputs will become larger, compar= ed to "shortcuts" like `SIGHASH_ANYPREVOUT` and `OP_CHECKOUTPUTSHASHVERIFY`= . For instance, to simulate `SIGHASH_ANYPREVOUT` with `OP_CAT` and `OP_CHECKS= IGFROMSTACK`, I would effectively split the unsigned transaction into its "= inputs" and "outputs" part, concat them and use `OP_CHECKSIGFROMSTACK` on t= he chaperone signature, and also use a normal `OP_CHECKSIGVERIFY` on that s= ame chaperone signature, then dup the "outputs" part and use `OP_CHECKSIGFR= OMSTACK` on the "any prevout"/"noinput" signature. I would effectively give the transaction to itself as part of the witness, = and further, I would also have to very carefully write the script (admitted= ly the writing of the template could be done once, but it would require far= more review than simple usages of the "limited" operations like `SIGHASH_A= NYPREVOUT`). So my witness stack would contain two signatures, and a duplicate of the tr= ansaction itself, plus a very much complicated script, whereas use of `SIGH= ASH_ANYPREVOUT` just requires two signatures and a script not much longer t= han pre-Schnorr multisig scripts. It seems to me desirable, to try to reduce bandwidth consumption on the Bit= coin blockchain, including witness data. Indeed, I had thought the whole exercise of putting `OP_CHECKSIGFROMSTACK` = in a federated sidechain (Elements/Liquid) was to try to identify common pa= tterns of usage for that opcode, and *then* to propose those common pattern= s as specific "optimized" opcodes as a sort of "jet" for Bitcoin itself (bu= t not `OP_CHECKSIGFROMSTACK` itself). Regards, ZmnSCPxj Sent with ProtonMail Secure Email. =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 Thursday, May 23, 2019 5:01 AM, Russell O'Connor via bitcoin-dev wrote: > Recently there have been some tapscript proposals, SIGHASH_ANYPREVOUT and= OP_CHECKOUTPUTHASHVERIFY, that aim to enable particular new features for B= itcoin via new Script operations.=C2=A0 However, I think that these proposa= ls miss the mark when it comes to how they approach Bitcoin Script and lang= uage features. > > 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 whi= ch 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.=C2=A0 They are both are designed with very = narrow applications in mind, while also going out of their way to extend th= e semantic domain of the interpretation of Bitcoin operations in new ways t= hat complicate their specification.=C2=A0 In the case of SIGHASH_ANYPREVOUT= , the semantic domain is extended by adding new counters to track the use o= f various v0 and v2 signature types.=C2=A0 In the case of OP_CHECKOUTPUTHAS= HVERIFY, it employs a new context-sensitive operation that peeks at the val= ue of surrounding opcodes. > > Instead, I propose that, for the time being, we simply implement OP_CAT a= nd OP_CHECKSIGFROMSTACKVERIFY.=C2=A0 OP_CAT pops two byte arrays off the st= ack and pushes their concatenation back onto the stack.=C2=A0 OP_CHECKSIGFR= OMSTACKVERIFY pops a signature, message, and pubkey off the stack and perfo= rms 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 Comput= ation with Penalties" by Kumaresan and Bentov). > * Transaction introspection including: > +=C2=A0Simulated SIGHASH_ANYPREVOUT, which are necessarily chaperoned sim= ply 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 amon= g 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, t= he more interesting recursive-covenants remain largely out of reach, with t= he 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 a= re pure computational operations on stack values.=C2=A0 The only semantic s= ide-effect is that OP_CHECKSIGFROMSTACKVERIFY would count towards the exist= ing 'sigops_passed' count.=C2=A0 Moreover, I feel that adding these operati= ons does not preclude adding more specialized opcodes in the future as an o= ptimization for whatever popular constructions come up, once we know what t= hose are. > > I feel that this style of generic building blocks truly embodies what is = meant by "programmable money".