Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 607C6BB3 for ; Tue, 18 Jun 2019 20:57:47 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io1-f49.google.com (mail-io1-f49.google.com [209.85.166.49]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id AB8DB180 for ; Tue, 18 Jun 2019 20:57:46 +0000 (UTC) Received: by mail-io1-f49.google.com with SMTP id n5so33076594ioc.7 for ; Tue, 18 Jun 2019 13:57:46 -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=oquKweOiF2wh7gmq0K6heUHEhKNbIGXGp7h2Wbr9eJ4=; b=3PNxEz5b75E0LIpgqBjeM82kTZmABLOn6cGAEQjB6LOhOnLb7367vKZOT5oLfl3jMa RGQJO31MHuvmfNLOTNy5envOOc80VRGjSaBTpEAe8BHc2jSQTdH+rGtj6zHEP/emfPlM va8kiGriiE4Lds1n0UPVx+NNobjHWW3Ze2vT0= 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=oquKweOiF2wh7gmq0K6heUHEhKNbIGXGp7h2Wbr9eJ4=; b=qqB93ORb/XAsifG/JLAyS2D54q9UBQJKPmEeTHIRk9mHA1qDM7IZp81+OyABkSq/Zr zuBfQyUAk9wifosYc47+2b0DgntHpWIJHUir98mfcQdoVRgqEHjCrZCxeD4c7z8lOKON R6rFYIZKgapBQrixAGoGc0/6G4LJ3D9HNu2madj9CbE3ym6PR5/nLh/jHZJRpu6DVT3d X5Q/SJ+OudZqv8vKslnrUContjLl5kclw4QWIOZpeOa+e2JWJ8V1DqSYDsoX5Q6ZtgkP C/lJc+3uxyvQlH8oWJMGN0uDqCz1G+ctqxSmee5EH5+V3tdu71JHP8ExtMVm82aoai3+ Or4w== X-Gm-Message-State: APjAAAXeAV5YX/Y9Vb5bExWYLovg7RtYMf77RoLuZ6V2mwfRqIaUUmFV u+aQa71Z4jocrVLe3MPx/AjrDCxL3Gfi2LA4Qt1UGKk7M28= X-Google-Smtp-Source: APXvYqxpyvZOVha0S+BQDGqc03MNWYT9Qp76Tpq0qAGCpg+qyAo5KzKFHnZ/fPb5huHTNIwnPnReCqd+vMt1snOqhsc= X-Received: by 2002:a6b:7208:: with SMTP id n8mr7222366ioc.151.1560891465846; Tue, 18 Jun 2019 13:57:45 -0700 (PDT) MIME-Version: 1.0 References: <20190605093039.xfo7lcylqkhsfncv@erisian.com.au> In-Reply-To: From: "Russell O'Connor" Date: Tue, 18 Jun 2019 16:57:34 -0400 Message-ID: To: ZmnSCPxj , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000005aec7d058b9f5d9c" 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: Thu, 20 Jun 2019 17:59:07 +0000 Subject: Re: [bitcoin-dev] OP_SECURETHEBAG (supersedes OP_CHECKOUTPUTSVERIFY) 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: Tue, 18 Jun 2019 20:57:47 -0000 --0000000000005aec7d058b9f5d9c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Just to be clear, while OP_CHECKTXDIGESTVERIFY would enable this style of covenants if it pulled data from the stack, the OP_SECURETHEBAG probably cannot create covenants even if it were to pull the data from the stack unless some OP_TWEEKPUBKEY operation is added to Script because the "commitment of the script itself" isn't part of the OP_SECURETHEBAG. So with regards to OP_SECURETHEBAG, I am also "not really seeing any reason to complicate the spec to ensure the digest is precommitted as part of the opcode." On Thu, Jun 6, 2019 at 3:33 AM ZmnSCPxj via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Good morning aj, > > > 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 = Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 > On Wednesday, June 5, 2019 5:30 PM, Anthony Towns via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > On Fri, May 31, 2019 at 10:35:45PM -0700, Jeremy via bitcoin-dev wrote: > > > > > OP_CHECKOUTPUTSHASHVERIFY is retracted in favor of OP_SECURETHEBAG*. > > > > I think you could generalise that slightly and make it fit in > > with the existing opcode naming by calling it something like > > "OP_CHECKTXDIGESTVERIFY" and pull a 33-byte value from the stack, > > consisting of a sha256 hash and a sighash-byte, and adding a new sighas= h > > value corresponding to the set of info you want to include in the hash, > > which I think sounds a bit like "SIGHASH_EXACTLY_ONE_INPUT | SIGHASH_AL= L" > > > > FWIW, I'm not really seeing any reason to complicate the spec to ensure > > the digest is precommitted as part of the opcode. > > > > I believe in combination with `OP_LEFT` and `OP_CAT` this allows > Turing-complete smart contracts, in much the same way as > `OP_CHECKSIGFROMSTACK`? > > Pass in the spent transaction (serialised for txid) and the spending > transaction (serialised for sighash) as part of the witness of the spendi= ng > transaction. > > Script verifies that the spending transaction witness value is indeed the > spending transaction by `OP_SHA256 OP_SWAP OP_CAT > OP_CHECKTXDIGESTVERIFY`. > Script verifies the spent transaction witness value is indeed the spent > transaction by hashing it, then splitting up the hash with `OP_LEFT` into > bytes, and comparing the bytes to the bytes in the input of the spending > transaction witness value (txid being the bytes in reversed order). > > Then the Script can extract a commitment of itself by extracting the > output of the spent transaction. > This lets the Script check that the spending transaction also pays to the > same script. > > The Script can then access a state value, for example from an `OP_RETURN` > output of the spent transaction, and enforce that a correct next-state is > used in the spending transaction. > If the state is too large to fit in a standard `OP_RETURN`, then the > current state can be passed in as a witness and validated against a hash > commitment in an `OP_RETURN` output. > > I believe this is the primary reason against not pulling data from the > stack. > > Regards, > ZmnSCPxj > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --0000000000005aec7d058b9f5d9c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just to be clear, while OP_C= HECKTXDIGESTVERIFY would enable this style of covenants if it pulled data f= rom the stack, the OP_SECURETHEBAG probably cannot= create covenants even if it were to pull the data from the stack unless so= me OP_TWEEKPUBKEY operation is added to Script because the "commitment= of the script itself" isn't part of the OP_SECURETHEBAG.

So wi= th regards to OP_SECURETHEBAG, I am also "not= really seeing any reason to complicate the spec to ensure the digest is pr= ecommitted as part of the opcode."
On Thu, J= un 6, 2019 at 3:33 AM ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org&= gt; wrote:
Good = morning aj,


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 Wednesday, June 5, 2019 5:30 PM, Anthony Towns via bitcoin-dev <bitco= in-dev@lists.linuxfoundation.org> wrote:

> On Fri, May 31, 2019 at 10:35:45PM -0700, Jeremy via bitcoin-dev wrote= :
>
> > OP_CHECKOUTPUTSHASHVERIFY is retracted in favor of OP_SECURETHEBA= G*.
>
> I think you could generalise that slightly and make it fit in
> with the existing opcode naming by calling it something like
> "OP_CHECKTXDIGESTVERIFY" and pull a 33-byte value from the s= tack,
> consisting of a sha256 hash and a sighash-byte, and adding a new sigha= sh
> value corresponding to the set of info you want to include in the hash= ,
> which I think sounds a bit like "SIGHASH_EXACTLY_ONE_INPUT | SIGH= ASH_ALL"
>
> FWIW, I'm not really seeing any reason to complicate the spec to e= nsure
> the digest is precommitted as part of the opcode.
>

I believe in combination with `OP_LEFT` and `OP_CAT` this allows Turing-com= plete smart contracts, in much the same way as `OP_CHECKSIGFROMSTACK`?

Pass in the spent transaction (serialised for txid) and the spending transa= ction (serialised for sighash) as part of the witness of the spending trans= action.

Script verifies that the spending transaction witness value is indeed the s= pending transaction by `OP_SHA256 <SIGHASH_ALL> OP_SWAP OP_CAT OP_CHE= CKTXDIGESTVERIFY`.
Script verifies the spent transaction witness value is indeed the spent tra= nsaction by hashing it, then splitting up the hash with `OP_LEFT` into byte= s, and comparing the bytes to the bytes in the input of the spending transa= ction witness value (txid being the bytes in reversed order).

Then the Script can extract a commitment of itself by extracting the output= of the spent transaction.
This lets the Script check that the spending transaction also pays to the s= ame script.

The Script can then access a state value, for example from an `OP_RETURN` o= utput of the spent transaction, and enforce that a correct next-state is us= ed in the spending transaction.
If the state is too large to fit in a standard `OP_RETURN`, then the curren= t state can be passed in as a witness and validated against a hash commitme= nt in an `OP_RETURN` output.

I believe this is the primary reason against not pulling data from the stac= k.

Regards,
ZmnSCPxj
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--0000000000005aec7d058b9f5d9c--