path: root/e2/c2b12d23385686658b7597fb3554e4bab1d34d

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 60801949
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 24 Jun 2019 18:49:05 +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 102907FB
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 24 Jun 2019 18:49:03 +0000 (UTC)
Received: by mail-io1-f54.google.com with SMTP id e3so226921ioc.12
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 24 Jun 2019 11:49:03 -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=qqTNo7cRFlFS3aHPCUaTY4jFHH3+CRdI6cQvlqMgINk=;
	b=GT8UgmoNAm9os6x3XyCxFNLyH8OSSkbxxnzby+PyhCdTeZQz9JuhZ8UjxCtUmKg5S/
	SfG3VJttkcdO+QY/GyU3KB0EJ09mQIZKnaJIkTlkIWBb7VJdzJWn+1zaQXzR7JVde1WI
	NXbKDKZLHHqZY3Uhl/Faa1S7FBwLkzVDizZww=
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=qqTNo7cRFlFS3aHPCUaTY4jFHH3+CRdI6cQvlqMgINk=;
	b=XxC65VHCdB3cmHOh10ONcC0g1uGh9s5mVqx6R2ta+RaIAok+AXyxnMigrBSF66ud8h
	wJYoyvt5pPnjYf0A+SH8ZWkWx9I7S5UWTIKiA9GEq9ogvLC5NX4U0PZ+frg/O4jxWN+g
	HvyN6BTX59gb6h1qI+Yo5za8t7/LGQy3AxhzooGItSowTfQ8U0INYFWCmlznvCVYUi/R
	2PKFAF2hUYegeYSzHQIRSG90galIRiwPg2q+P8MzEP/jxc26/wIMfpOJnbFge3/fB7gP
	uwRrYKuMKJT6ob1uqt5kJ7TxoO6UKrSnnWXjY43AmgI1Muc0gVc+OxNdDw+JgD56rVEv
	xyKQ==
X-Gm-Message-State: APjAAAVEM8nafVeKZqOuaxI9z2OcFWrFH4R1vKwpAkDMzE90O7XM8RLz
	4Of4pmv2mNYcbgXn5OG/Q9+VSrTlVB27ZUaPgzhFEA==
X-Google-Smtp-Source: APXvYqwaDkW+qfcgDUGwQQM/KRw2GYQUEctTADDMYPT+Qs8y88u06X2PSd/9MWpwNbCd9rVuZ0PlronSp+kocFJMzh4=
X-Received: by 2002:a5d:948a:: with SMTP id v10mr16429910ioj.103.1561402143079;
	Mon, 24 Jun 2019 11:49:03 -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>
	<CAMZUoKkPUn01V7WruMqoYtwJ__ai-QPvD81ceoYC7j4+hC99gg@mail.gmail.com>
	<CAD5xwhi6QU5OZwSGMp4P3q7OYZMMZRUZgd2YOiUnv5tqgJxPSA@mail.gmail.com>
In-Reply-To: <CAD5xwhi6QU5OZwSGMp4P3q7OYZMMZRUZgd2YOiUnv5tqgJxPSA@mail.gmail.com>
From: "Russell O'Connor" <roconnor@blockstream.io>
Date: Mon, 24 Jun 2019 14:48:51 -0400
Message-ID: <CAMZUoKkorcO+CD6jcV5tyCtrKuHq_2hJhKE08FTrqJz7GgPM8Q@mail.gmail.com>
To: Jeremy <jlrubin@mit.edu>
Content-Type: multipart/alternative; boundary="000000000000171b4e058c164489"
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 18:49:05 -0000

--000000000000171b4e058c164489
Content-Type: text/plain; charset="UTF-8"

I suspect that your conjecture is true.  And given that it is plausible
that we would want to add an opcode to tweak public keys, it seems like a
reason design to avoid accidental covenants.
(That said, I strongly prefer that the SECURETHEBAG data be the 32-bytes
immediately following the opcode rather than a OP_PUSHDATA, and I'd be
willing to help code this up (see below)).

On Mon, Jun 24, 2019 at 2:07 PM Jeremy <jlrubin@mit.edu> wrote:

> Do you think the following hypothesis is more or less true:
>
> H: There is no set of pure extensions* to script E such that enabling E
> and OP_SECURETHEBAG as proposed enables recursive covenants, but E alone
> does not enable recursive covenants?
>
> * Of course there are things that specifically are specifically designed
> to switch on if OP_SECURETHEBAG, so pure means normal things like OP_CAT
> that are a function of the arguments on the stack or hashed txn data.
>
> This is the main draw of the design I proposed, it should be highly
> improbable or impossible to accidentally introduce more behavior than
> intended with a new opcode.
>
> I think that given that H is not true for the stack reading version of the
> opcode, we should avoid doing it unless strongly motivated, so as to permit
> more flexibility for which opcodes we can add in the future without
> introducing recursion unless it is explicitly intended.
>

On Sat, Jun 1, 2019 at 12:47 PM Jeremy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> A particularly useful topic of discussion is how best to eliminate the
> PUSHDATA and treat OP_SECURETHEBAG like a pushdata directly. I thought
> about how the interpreter works and is implemented and couldn't come up
> with something noninvasive.
>

We shouldn't be using the complexity of the changes to the Bitcoin Core a
measure of the complexity of a proposal.  That is looking the issue from
the wrong side.  If we measure the complexity of Script proposals by how
hard it is to change Bitcoin Core, what will happen is more and more of the
incidental details of Bitcoin Core's implementation will be pulled into the
semantics of Script (e.g. the fact that surrounding opcode values are
readily available in Bitcoin Core's particular implementation of its Script
interpreter).  Instead we should use the complexity of how hard it is to
reason about the new Script semantics.

The peeking semantics of OP_SECURETHEBAG is particularly awful because it
more-or-less breaks the fact that Bitcoin Script can be decomposed into
individual units of "opcodes" whose semantics and be individually
described, and it harms the composability of Bitcoin Script where you can
divide the script between any opcodes and the semantics of the
concatenation of those two scripts is simply the composition of the
semantics of the two halves.  (For those interested in formal semantics,
what we have here is a monoid homomorphism from list of opcodes (syntax) to
stack transformation functions (with side-effects) under (Kleisli)
composition (semantics).) Being able to decompose a Bitcoin Script this way
and reasoning about components is how one would reason about Bitcoin Script
in practice.  (Technically the structure is more involved than a list of
opcodes due to OP_IF, and instead you get a railroad diagram
<https://en.wikipedia.org/wiki/Syntax_diagram>).

Putting the 32 bytes of data required by OP_SECURETHEBAG immediately after
the opcode, like how OP_PUSHDATA* works, is a superior design choice.  It
lets us treat the opcodes and its immediate data as an atomic unit when
reasoning about Script and removes the need to define what happens when
OP_SECURETHEBAG is not followed by an OP_PUSDATA.

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

<div dir=3D"ltr"><div>I suspect that your conjecture is true.=C2=A0 And giv=
en that it is plausible that we would want to add an opcode to tweak public=
 keys, it seems like a reason design to avoid accidental covenants.</div><d=
iv>(That said, I strongly prefer that the SECURETHEBAG data be the 32-bytes=
 immediately following the opcode rather than a OP_PUSHDATA, and I&#39;d be=
 willing to help code this up (see below)).<br></div><br><div class=3D"gmai=
l_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Jun 24, 2019 at 2:07=
 PM Jeremy &lt;<a href=3D"mailto:jlrubin@mit.edu">jlrubin@mit.edu</a>&gt; w=
rote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"auto"><div dir=3D"auto">Do you think the following hypothesis is more o=
r less true:</div><div dir=3D"auto"><br></div><div dir=3D"auto">H: There is=
 no set of pure extensions* to script E such that enabling E and OP_SECURET=
HEBAG as proposed enables recursive covenants, but E alone does not enable =
recursive covenants?</div><div dir=3D"auto">=C2=A0</div>* Of course there a=
re things that specifically are specifically designed to switch on if OP_SE=
CURETHEBAG, so pure means normal things like OP_CAT that are a function of =
the arguments on the stack or hashed txn data.=C2=A0<div dir=3D"auto"><br><=
/div><div dir=3D"auto">This is the main draw of the design I proposed, it s=
hould be highly improbable or impossible to accidentally introduce more beh=
avior than intended with a new opcode.</div><div dir=3D"auto"><br></div><di=
v dir=3D"auto">I think that given that H is not true for the stack reading =
version of the opcode, we should avoid doing it unless strongly motivated, =
so as to permit more flexibility for which opcodes we can add in the future=
 without introducing recursion unless it is explicitly intended.=C2=A0</div=
></div></blockquote><div><br></div><div><div dir=3D"ltr" class=3D"gmail_att=
r">On Sat, Jun 1, 2019 at 12:47 PM Jeremy via bitcoin-dev &lt;<a href=3D"ma=
ilto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@l=
ists.linuxfoundation.org</a>&gt; wrote:<br></div></div><div><blockquote cla=
ss=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><div dir=3D"ltr" c=
lass=3D"gmail-m_-2481636322531322403gmail-m_-8983210578190892976gmail_signa=
ture"><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;=
color:rgb(0,0,0)">A
 particularly useful topic of discussion is how best to eliminate the=20
PUSHDATA and treat OP_SECURETHEBAG like a pushdata directly. I thought=20
about how the interpreter works and is implemented and couldn&#39;t come up=
=20
with something noninvasive.</div></div></div></div></blockquote><div><br>We
 shouldn&#39;t be using the complexity of the changes to the Bitcoin Core a=
=20
measure of the complexity of a proposal.=C2=A0 That is looking the issue fr=
om
 the wrong side.=C2=A0 If we measure the complexity
 of Script proposals by how hard it is to change Bitcoin Core, what will ha=
ppen is more and more of the incidental details of Bitcoin=20
Core&#39;s implementation will be pulled into the semantics of Script (e.g.=
 the fact that=20
surrounding opcode values are readily available in Bitcoin Core&#39;s=20
particular implementation of its Script interpreter).=C2=A0 Instead we shou=
ld use the complexity of how hard it is to reason about the new Script sema=
ntics.<br><br>The peeking semantics of=20
OP_SECURETHEBAG is particularly awful because it=20
more-or-less breaks the fact that Bitcoin Script can be decomposed into=20
individual units of &quot;opcodes&quot; whose semantics and be individually=
=20
described, and it harms the composability of Bitcoin Script where you=20
can divide the script between any opcodes and the semantics of the=20
concatenation of those two scripts is simply the composition of the=20
semantics of the two halves. =C2=A0(For those interested in formal semantic=
s,
 what we have here is a monoid homomorphism from list of opcodes=20
(syntax) to stack transformation functions (with side-effects) under=20
(Kleisli) composition (semantics).) Being able to decompose a Bitcoin=20
Script this way and reasoning about components is how one would reason=20
about Bitcoin Script in practice.=C2=A0 (Technically the structure is more=
=20
involved than a list of opcodes due to OP_IF, and instead you get a <a href=
=3D"https://en.wikipedia.org/wiki/Syntax_diagram">railroad diagram</a>).<br=
><br>Putting
 the 32 bytes of data required by OP_SECURETHEBAG immediately after the=20
opcode, like how OP_PUSHDATA* works, is a superior design choice.=C2=A0 It =
lets us treat=20
the opcodes and its immediate data as an atomic unit when reasoning=20
about Script and removes the need to define what happens when OP_SECURETHEB=
AG is not followed by an OP_PUSDATA.<br></div></div></div></div>

--000000000000171b4e058c164489--