Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 9C7F49C for ; Thu, 3 Nov 2016 07:37:42 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk0-f180.google.com (mail-qk0-f180.google.com [209.85.220.180]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C69D78E for ; Thu, 3 Nov 2016 07:37:41 +0000 (UTC) Received: by mail-qk0-f180.google.com with SMTP id x190so45127191qkb.0 for ; Thu, 03 Nov 2016 00:37:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=+E20lkAOjFBhk8eWz6ESpVnHL0N0cM4eVd2nwOD9WeA=; b=EHl7RFH+oAUH9V47p305eKYIy0bQnCPgIUaLeTd1tGHp4fueHx7cCj3oUE51H5v82P G5hrZQXf8scd7kQFwxnuLKyF0Io2YKbnNqD5g0ulLI2dBix+IGe4PngF9WrbGGVCe2Cn 05uFFUSp416DdfQQJyL70/eadtpfczreZ9OAUTh2zsrCzYxaLi2PZYv0vNzpoMxwYSYI AEWjzUqcn8PZXWrFh243dP3kDTD3zf/OLiU2yQxyDU38e/HHdb+j6a13nvPiuHNX9kaC /w2IotR7hrGz0PwvePevFPeOmmfQRFj5Dfqe7J0EXeFi0ZIYA820tzLhb919a2WO/a5K bSEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=+E20lkAOjFBhk8eWz6ESpVnHL0N0cM4eVd2nwOD9WeA=; b=gr8StVyDob6x5JHWRP1Nt01HRfF+pUrzMhC0LsOB40xtZefc5CoJkXEjquGSgsW/71 yRD84pB02eCgoZdN9wvNCGy23g4p85kUQdD4VI7c+odHkVjUSogjKf2ZCPWABwhknbqb JUCMFJeJ7qQrdk7EmMgiKbFPaUaAyLSODGT36ZzxXv9G8P+ohnKQwys+WM+kPvvXBhuN HfJmlCg2zZIaVypLO4TlaTkWkVkP5n2wl7IjiaHcSrZvUymCLjcb71OoFoJCcDCrbgNe zI1cUVtzmrep1b6UZOE83TPcZE7GW139qgqlHCOMKlMBgseW5u6PB4ljVSN/wbklGZzc AuVQ== X-Gm-Message-State: ABUngveU9jM0FbtCmTsgLC3ZaZ0jv/OZmAXRnHIbrsarbgnVrI1xGpBZy+81BUG0QG/pAz863RwXBeMnc14mbA== X-Received: by 10.55.68.80 with SMTP id r77mr7236181qka.318.1478158660986; Thu, 03 Nov 2016 00:37:40 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Daniel Robinson Date: Thu, 03 Nov 2016 07:37:29 +0000 Message-ID: To: "Russell O'Connor" , Bitcoin Protocol Discussion , Johnson Lau Content-Type: multipart/alternative; boundary=001a11489cfce8ee68054060a101 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_LOW, RCVD_IN_SORBS_SPAM 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, 03 Nov 2016 07:55:11 +0000 Subject: Re: [bitcoin-dev] Implementing Covenants with OP_CHECKSIGFROMSTACKVERIFY 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, 03 Nov 2016 07:37:42 -0000 --001a11489cfce8ee68054060a101 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Really cool! How about "poison transactions," the other covenants use case proposed by M=C3=B6ser, Eyal, and Sirer? (I think OP_CHECKSIGFROMSTACKVERIFY will also = make it easier to check fraud proofs, the other prerequisite for poison transactions.) Seems a little wasteful to do those two "unnecessary" signature checks, and to have to construct the entire transaction data structure, just to verify a single output in the transaction. Any plans to add more flexible introspection opcodes to Elements, such as OP_CHECKOUTPUTVERIFY? Really minor nit: "Notice that we have appended 0x83 to the end of the transaction data"=E2=80=94should this say "to the end of the signature"? On Thu, Nov 3, 2016 at 12:28 AM Russell O'Connor via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: Right. There are minor trade-offs to be made with regards to that design point of OP_CHECKSIGFROMSTACKVERIFY. Fortunately this covenant construction isn't sensitive to that choice and can be made to work with either implementation of OP_CHECKSIGFROMSTACKVERIFY. On Wed, Nov 2, 2016 at 11:35 PM, Johnson Lau wrote: Interesting. I have implemented OP_CHECKSIGFROMSTACKVERIFY in a different way from the Elements. Instead of hashing the data on stack, I directly put the 32 byte hash to the stack. This should be more flexible as not every system are using double-SHA256 https://github.com/jl2012/bitcoin/commits/mast_v3_master On 3 Nov 2016, at 01:30, Russell O'Connor via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: Hi all, It is possible to implement covenants using two script extensions: OP_CAT and OP_CHECKSIGFROMSTACKVERIFY. Both of these op codes are already available in the Elements Alpha sidechain, so it is possible to construct covenants in Elements Alpha today. I have detailed how the construction works in a blog post at < https://blockstream.com/2016/11/02/covenants-in-elements-alpha.html>. As an example, I've constructed scripts for the Moeser-Eyal-Sirer vault. I'm interested in collecting and implementing other useful covenants, so if people have ideas, please post them. If there are any questions, I'd be happy to answer. --=20 Russell O'Connor _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --001a11489cfce8ee68054060a101 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Really cool!

How about "poison transactions," the other covenan= ts use case proposed by M=C3=B6ser, Eyal, and Sirer? (I think OP_CHECKSIGFR= OMSTACKVERIFY will also make it easier to check fraud proofs, the other pre= requisite for poison transactions.)

Seems a little wasteful to do those two "unn= ecessary" signature checks, and to have to construct the entire transa= ction data structure, just to verify a single output in the transaction. An= y plans to add more flexible introspection opcodes to Elements, such as OP_= CHECKOUTPUTVERIFY?

Really minor nit: "Notice that we have ap= pended 0x83 to the end of the transaction data"=E2=80=94should this sa= y "to the end of the signature"?

On Thu= , Nov 3, 2016 at 12:28 AM Russell O'Connor via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
Right.=C2=A0 There are minor trade-offs to be made = with regards to that design point of OP_CHECKSIGFROMSTACKVERIFY.=C2=A0 Fort= unately this covenant construction isn't sensitive to that choice and c= an be made to work with either implementation of OP_CHECKSIGFROMSTACKVERIFY= .

On Wed, Nov 2, 2016 at 11:35 PM, Johnson Lau <jl2012@xbt.hk> wrote:
=
Interesting. I have implemente= d=C2=A0OP_CHECKSIGFROMSTACKVERIFY in a different way from the Elements. Ins= tead of hashing the data on stack, I directly put the 32 byte hash to the s= tack. This should be more flexible as not every system are using double-SHA= 256

https://github.com/jl2012/bi= tcoin/commits/mast_v3_master


= On 3 Nov 2016, at 01:30, Russell O'Connor via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

<= /blockquote>
Hi all,

It is= possible to implement covenants using two script extensions: OP_CAT and OP= _CHECKSIGFROMSTACKVERIFY.=C2=A0 Both of these op codes are already availabl= e in the Elements Alpha sidechain, so it is possible to construct covenants= in Elements Alpha today.=C2=A0 I have detailed how the construction works = in a blog post at <https://bl= ockstream.com/2016/11/02/covenants-in-elements-alpha.html>.=C2=A0 As= an example, I've constructed scripts for the Moeser-Eyal-Sirer vault.<= br class=3D"gmail_msg">
I'm interested in collec= ting and implementing other useful covenants, so if people have ideas, plea= se post them.

If there are a= ny questions, I'd be happy to answer.=C2=A0
--
Russell O'Connor
_______________________________________________
bitc= oin-dev mailing list
bitcoin-dev= @lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin= -dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linu= xfoundation.org/mailman/listinfo/bitcoin-dev
--001a11489cfce8ee68054060a101--