path: root/a2/7aebfb174d3e66ddf051ae097647ed1eaefa11

Return-Path: <roconnor@blockstream.io>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 21CF5F7F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 24 Jun 2019 14:35:07 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io1-f54.google.com (mail-io1-f54.google.com
	[209.85.166.54])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 461917FB
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 24 Jun 2019 14:35:06 +0000 (UTC)
Received: by mail-io1-f54.google.com with SMTP id u19so1512249ior.9
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 24 Jun 2019 07:35:06 -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=TI9gNJq27y2b/oVN58IF2eV4FtvBDrXX2wtWxoO5vgs=;
	b=Cf2/Bf5lt51Dcos10STYLKL+LAr2iZZF2/g5xO9FLrdtlObBP2y3EGpBMc5ydSuzCr
	xuvNdwtUybXkbjrJULa20+zVWRjhqWmyzWAHPclJqtXv0IhdV8dmHWGiKAkY2iUHgnhp
	8+gtlNzc9yJdnlTRqhxkCPsbYeX1o/RTQX/xw=
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=TI9gNJq27y2b/oVN58IF2eV4FtvBDrXX2wtWxoO5vgs=;
	b=ltxKWonyDyTFSKqNMQb5skuCxHwAvBNnJOaU5uYvlJt9u2amwxDGqdRXZXQikO+d6u
	S7r2A6n117LN22fJJijFANGHOLJVexZmdilcT8dWUh/jlaKzGXkYNqEnP0e/ENX5YBzq
	jzQ/mwnzDKUnnaFRz1/8qt/atm+oPiIr3tuKndtmhoz7T9ai9y0kA0oQSH6hpQl7IxBN
	a5/x/mS1mSN2V8zlZZMFXeNFowaTUTyeiMYKELIRbWH8Kz750Fat7ETD2z8VnoqBHE12
	oAoJzCq276Fmv6vs11uIXVrstTBZtsH2o5LaKXj64Jird3SNFIgHwD9jnHciLpSyiewS
	t23g==
X-Gm-Message-State: APjAAAVFYIHO4dC1U7dTBK5HMBlbXKqzSH3IzEJNusCSWH+azPQI56Hw
	XjkgN79eZIjbxNIH38al9zdvQkrZCUAjGojnEiAD2A==
X-Google-Smtp-Source: APXvYqwBgOPevN2dzVmJvmPeqDPBGaXYUI8RL6/6/DcoFjlfe2SMl47zQFAnuYcO8OdU8yjaMYHN/3N9IVsdTgtPXik=
X-Received: by 2002:a6b:c9c1:: with SMTP id z184mr15068940iof.74.1561386905549;
	Mon, 24 Jun 2019 07:35:05 -0700 (PDT)
MIME-Version: 1.0
References: <CAD5xwhjSj82YYuQHHbwgSLvUNV2RDY0b=yMYeLj-p6j7PpS9-Q@mail.gmail.com>
	<20190605093039.xfo7lcylqkhsfncv@erisian.com.au>
	<im0q8670MxshmvMLmoJU0dv4rFhwWZNvQeQYv7i4fBWJOx0ghAdH8fYuQSqNxO2z8uxXGV-kurinUDfl0FsLWD0knw_U_h3zVZ0xy7vmn8o=@protonmail.com>
	<CAMZUoK=ZB06jwAbuX2D=aN8ztAqr_jSgEXS1z1ABjQYVawKCBQ@mail.gmail.com>
	<CAD5xwhj8o8Vbrk2KADBOFGfkD3fW3eMZo5aHJytGAj_5LLhYCg@mail.gmail.com>
In-Reply-To: <CAD5xwhj8o8Vbrk2KADBOFGfkD3fW3eMZo5aHJytGAj_5LLhYCg@mail.gmail.com>
From: "Russell O'Connor" <roconnor@blockstream.io>
Date: Mon, 24 Jun 2019 10:34:54 -0400
Message-ID: <CAMZUoKkPUn01V7WruMqoYtwJ__ai-QPvD81ceoYC7j4+hC99gg@mail.gmail.com>
To: Jeremy Rubin <jeremy.l.rubin@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000dcd58a058c12b7f6"
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: Tue, 25 Jun 2019 17:26:58 +0000
Cc: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Jun 2019 14:35:07 -0000

--000000000000dcd58a058c12b7f6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

OP_SECURETHEBAG doesn't include the script being executed (i.e the
scriptPubKey specified in the output that is redeemed by this input) in its
hash like ordinary signatures do
<https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp#=
L1271>.
Of course, this ScriptPubKey is indirectly committed to through the input's
prevoutpoint.  However Script isn't able to reconstruct this script being
executed from the prevoutpoint in tapscript without an implementation of
public key tweeking in Bitcoin Script.

On Sun, Jun 23, 2019 at 2:41 AM Jeremy Rubin <jeremy.l.rubin@gmail.com>
wrote:

> Can you clarify this comment?
>
> We do in fact commit to the script and scriptsig itself (not the witness
> stack) in OP_SECURETHEBAG (unless I'm missing what you meant)?
>
> On Thu, Jun 20, 2019, 10:59 AM Russell O'Connor via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> 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 t=
he
>> stack unless some OP_TWEEKPUBKEY operation is added to Script because th=
e
>> "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 pa=
rt
>> 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 Origina=
l 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 wrot=
e:
>>> >
>>> > > 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
>>> sighash
>>> > value corresponding to the set of info you want to include in the has=
h,
>>> > which I think sounds a bit like "SIGHASH_EXACTLY_ONE_INPUT |
>>> SIGHASH_ALL"
>>> >
>>> > FWIW, I'm not really seeing any reason to complicate the spec to ensu=
re
>>> > 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 spen=
ding
>>> transaction.
>>>
>>> Script verifies that the spending transaction witness value is indeed
>>> the spending transaction by `OP_SHA256 <SIGHASH_ALL> 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` in=
to
>>> bytes, and comparing the bytes to the bytes in the input of the spendin=
g
>>> 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 has=
h
>>> 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
>>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>

--000000000000dcd58a058c12b7f6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><span class=3D"gmail-m_743483921601803653=
3m_-216577082455711303m_2651264282820171888gmail-im"><span class=3D"gmail-m=
_7434839216018036533m_-216577082455711303m_2651264282820171888gmail-im">OP_=
SECURETHEBAG doesn&#39;t include the script being executed (i.e the scriptP=
ubKey specified in the output that is redeemed by this input) in its hash l=
ike <a href=3D"https://github.com/bitcoin/bitcoin/blob/master/src/script/in=
terpreter.cpp#L1271">ordinary signatures do</a>.=C2=A0 Of course, this Scri=
ptPubKey is indirectly committed to through the input&#39;s prevoutpoint.=
=C2=A0 However Script isn&#39;t able to reconstruct this script being execu=
ted from the <span class=3D"gmail-m_7434839216018036533m_-21657708245571130=
3m_2651264282820171888gmail-im"><span class=3D"gmail-m_7434839216018036533m=
_-216577082455711303m_2651264282820171888gmail-im">prevoutpoint in tapscrip=
t without an implementation of public key tweeking in Bitcoin Script.<br></=
span></span></span></span></div><br><div class=3D"gmail_quote"><div dir=3D"=
ltr" class=3D"gmail_attr">On Sun, Jun 23, 2019 at 2:41 AM Jeremy Rubin &lt;=
<a href=3D"mailto:jeremy.l.rubin@gmail.com">jeremy.l.rubin@gmail.com</a>&gt=
; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div di=
r=3D"ltr"><div dir=3D"auto"><div>Can you clarify this comment?</div><div><b=
r></div><div><div style=3D"font-family:arial,helvetica,sans-serif;font-size=
:small;color:rgb(0,0,0)">We do in fact commit to the script and scriptsig i=
tself (not the witness stack) in OP_SECURETHEBAG (unless I&#39;m missing wh=
at you meant)?</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=
=3D"gmail_attr">On Thu, Jun 20, 2019, 10:59 AM Russell O&#39;Connor via bit=
coin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targe=
t=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Jus=
t to be clear, while <span class=3D"gmail-m_7434839216018036533m_-216577082=
455711303m_2651264282820171888gmail-im">OP_CHECKTXDIGESTVERIFY would enable=
 this style of covenants if it pulled data from the stack, the <span class=
=3D"gmail-m_7434839216018036533m_-216577082455711303m_2651264282820171888gm=
ail-im">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 &quot;commitment of the script itself&quot; isn&#39;=
t part of the OP_SECURETHEBAG.</span></span></div><div><span class=3D"gmail=
-m_7434839216018036533m_-216577082455711303m_2651264282820171888gmail-im"><=
span class=3D"gmail-m_7434839216018036533m_-216577082455711303m_26512642828=
20171888gmail-im"><br></span></span></div><div><span class=3D"gmail-m_74348=
39216018036533m_-216577082455711303m_2651264282820171888gmail-im"><span cla=
ss=3D"gmail-m_7434839216018036533m_-216577082455711303m_2651264282820171888=
gmail-im">So with regards to OP_SECURETHEBAG, I am also<span class=3D"gmail=
-m_7434839216018036533m_-216577082455711303m_2651264282820171888gmail-im"> =
&quot;not really seeing any reason to complicate the spec to ensure the dig=
est is precommitted as part of the opcode.&quot;</span></span></span></div>=
<div><span class=3D"gmail-m_7434839216018036533m_-216577082455711303m_26512=
64282820171888gmail-im"><span class=3D"gmail-m_7434839216018036533m_-216577=
082455711303m_2651264282820171888gmail-im"></span></span></div></div><br><d=
iv class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Jun =
6, 2019 at 3:33 AM ZmnSCPxj via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-d=
ev@lists.linuxfoundation.org" rel=3D"noreferrer" target=3D"_blank">bitcoin-=
dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex">Good morning aj,<br>
<br>
<br>
Sent with ProtonMail Secure Email.<br>
<br>
=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<br>
On Wednesday, June 5, 2019 5:30 PM, Anthony Towns via bitcoin-dev &lt;<a hr=
ef=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer" targ=
et=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
<br>
&gt; On Fri, May 31, 2019 at 10:35:45PM -0700, Jeremy via bitcoin-dev wrote=
:<br>
&gt;<br>
&gt; &gt; OP_CHECKOUTPUTSHASHVERIFY is retracted in favor of OP_SECURETHEBA=
G*.<br>
&gt;<br>
&gt; I think you could generalise that slightly and make it fit in<br>
&gt; with the existing opcode naming by calling it something like<br>
&gt; &quot;OP_CHECKTXDIGESTVERIFY&quot; and pull a 33-byte value from the s=
tack,<br>
&gt; consisting of a sha256 hash and a sighash-byte, and adding a new sigha=
sh<br>
&gt; value corresponding to the set of info you want to include in the hash=
,<br>
&gt; which I think sounds a bit like &quot;SIGHASH_EXACTLY_ONE_INPUT | SIGH=
ASH_ALL&quot;<br>
&gt;<br>
&gt; FWIW, I&#39;m not really seeing any reason to complicate the spec to e=
nsure<br>
&gt; the digest is precommitted as part of the opcode.<br>
&gt;<br>
<br>
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`?<br>
<br>
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.<br>
<br>
Script verifies that the spending transaction witness value is indeed the s=
pending transaction by `OP_SHA256 &lt;SIGHASH_ALL&gt; OP_SWAP OP_CAT OP_CHE=
CKTXDIGESTVERIFY`.<br>
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).<br>
<br>
Then the Script can extract a commitment of itself by extracting the output=
 of the spent transaction.<br>
This lets the Script check that the spending transaction also pays to the s=
ame script.<br>
<br>
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.<br>
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.<br>
<br>
I believe this is the primary reason against not pulling data from the stac=
k.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer"=
 target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer"=
 target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div></div></div>
</div>
</blockquote></div></div>

--000000000000dcd58a058c12b7f6--