path: root/a0/551affde786d3c40476170adbf2faa01f62b15

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 8E86A927
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun,  2 Jun 2019 14:32:46 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-it1-f175.google.com (mail-it1-f175.google.com
	[209.85.166.175])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E05D482B
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun,  2 Jun 2019 14:32:45 +0000 (UTC)
Received: by mail-it1-f175.google.com with SMTP id j17so15127706itk.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 02 Jun 2019 07:32:45 -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; 
	bh=my2SOpWkWHYlhlLKCpVMAheI0NKRC+7CGybNAPeMoJk=;
	b=c33nIP39ryMiEkDHdB688XKsUg1EGhE9HuG2u9ciKCr7Jfkft7pmvT2Urf6HYVHYi0
	WrU76cMqbX+JiziagCyEl+XSyb4lQuGSIm/YFbXVGRnRO33TDLCUzQf3Ns/i8P+dqJRE
	EZA9FdqKwoglynVYXlAA0mqEhky5ddWBk5ZNo=
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;
	bh=my2SOpWkWHYlhlLKCpVMAheI0NKRC+7CGybNAPeMoJk=;
	b=CDsCcq+CCHFt8kmcRYE6zcb1FuTM7LrSjQbKHhs0mPU0/tK1gfdW98kP6sB+zeX6rL
	RcZDn5q4ufFCnv/Yi+8vdy9DO12S/I7WLdMyh+bW/I9raRpq12kze6Kz2QVjXjFRby4q
	n4GWg77MygRs0W6LDDMV83HrS9kzlJZ16LAUH5/R7j0xTSL2y8LNDWOEsGlZ6nItUqNu
	zVOD0uO8aiRcaSSxDkEJ9lKcUdRirMIoF0oAKquL0LrCKDHpwhA+uuyTg7xRaYyufXGM
	DeffxHIfOJjNbgyXERElOdgb0i5rBOXcZ0UVLkOlv30lpYNOMaWTsMoTXj4llSG/cLjg
	VCPA==
X-Gm-Message-State: APjAAAVqBJeTbidE3lxXxTMDymmJRWwcWDxXQrbVqevOiKRx9GAbz03u
	f4gmTlnSB5U0DxTu7U6E8eaFxdUtL8Pj40UnIw+Ipg==
X-Google-Smtp-Source: APXvYqwjCzGklzhxI8kaRsknC0SXKyyPiM8cEyhsnHerh0aza65hUJnMXYsd2MMUMBvxQYrecZOfKki6FBBXHsY0l1I=
X-Received: by 2002:a05:660c:1cc:: with SMTP id
	s12mr12630018itk.170.1559485965075; 
	Sun, 02 Jun 2019 07:32:45 -0700 (PDT)
MIME-Version: 1.0
References: <CAD5xwhjSj82YYuQHHbwgSLvUNV2RDY0b=yMYeLj-p6j7PpS9-Q@mail.gmail.com>
In-Reply-To: <CAD5xwhjSj82YYuQHHbwgSLvUNV2RDY0b=yMYeLj-p6j7PpS9-Q@mail.gmail.com>
From: "Russell O'Connor" <roconnor@blockstream.io>
Date: Sun, 2 Jun 2019 10:32:33 -0400
Message-ID: <CAMZUoKm9aZMCnJzP3YvLZ5oycDG-pss8cYZwan2N71_gc95GDg@mail.gmail.com>
To: Jeremy <jlrubin@mit.edu>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000fb216a058a581e2a"
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: Mon, 03 Jun 2019 15:10:25 +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 <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: Sun, 02 Jun 2019 14:32:46 -0000

--000000000000fb216a058a581e2a
Content-Type: text/plain; charset="UTF-8"

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

> Hi All,
>
> OP_CHECKOUTPUTSHASHVERIFY is retracted in favor of OP_SECURETHEBAG*.
> OP_SECURETHEBAG does more or less the same thing, but fixes malleability
> issues and lifts the single output restriction to a known number of inputs
> restriction.
>
> OP_CHECKOUTPUTSVERIFY had some issues with malleability of version and
> locktime. OP_SECURETHEBAG commits to both of these values.
>

Can you elaborate a bit more on what the issues were?


> OP_SECURETHEBAG also lifts the restriction that OP_CHECKOUTPUTSVERIFY had
> to be spent as only a single input, and instead just commits to the number
> of inputs. This allows for more flexibility, but keeps it easy to get the
> same single output restriction.
>
> BIP:
> https://github.com/JeremyRubin/bips/blob/op-secure-the-bag/bip-secure-the-bag.mediawiki
> Implementation: https://github.com/JeremyRubin/bitcoin/tree/secure_the_bag
>
> 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.
>

I'm not a Core developer but from what I understand, I'd be inclined to to
treat OP_SECURETHEBAG as with an immediate 32-byte parameter by modifying
GetScriptOp to return the 32-byte parameter through pvchRet.

bool GetScriptOp(CScriptBase::const_iterator& pc,
CScriptBase::const_iterator end, opcodetype& opcodeRet,
std::vector<unsigned char>* pvchRet)
{
    opcodeRet = OP_INVALIDOPCODE;
    if (pvchRet)
        pvchRet->clear();
    if (pc >= end)
        return false;

    // Read instruction
    if (end - pc < 1)
        return false;
    unsigned int opcode = *pc++;

    // Immediate operand
    if (opcode <= OP_PUSHDATA4)
    {
        // ...
    }

    if (opcode == OP_SECURETHEBAG) {
        if (end - pc < 0 || (unsigned int)(end - pc) < 32)
            return false;
        if (pvchRet)
            pvchRet->assign(pc, pc + 32);
        pc += 32;
    }

    opcodeRet = static_cast<opcodetype>(opcode);
    return true;
}

and go from there.

Thank you for your review and discussion,
>
> Jeremy
>
> * Plus the name is better
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Sat, Jun 1, 2019 at 12:47 PM Jerem=
y via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.o=
rg">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquo=
te 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 style=3D"fon=
t-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Hi Al=
l,</div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:smal=
l;color:rgb(0,0,0)"><br></div><div style=3D"font-family:arial,helvetica,san=
s-serif;font-size:small;color:rgb(0,0,0)"><div style=3D"font-family:arial,h=
elvetica,sans-serif;font-size:small;color:rgb(0,0,0)">OP_CHECKOUTPUTSHASHVE=
RIFY is retracted in favor of OP_SECURETHEBAG*. OP_SECURETHEBAG does more o=
r less the same thing, but fixes malleability issues and lifts the single o=
utput restriction to a known number of inputs restriction.<br></div></div><=
div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:r=
gb(0,0,0)"><br></div><div style=3D"font-family:arial,helvetica,sans-serif;f=
ont-size:small;color:rgb(0,0,0)">OP_CHECKOUTPUTSVERIFY had some issues with=
 malleability of version and locktime. OP_SECURETHEBAG commits to both of t=
hese values. <br></div></div></blockquote><div><br></div><div>Can you elabo=
rate a bit more on what the issues were?<br></div><div>=C2=A0</div><blockqu=
ote 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 style=3D"fo=
nt-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"></di=
v><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;colo=
r:rgb(0,0,0)">OP_SECURETHEBAG also lifts the restriction that OP_CHECKOUTPU=
TSVERIFY had to be spent as only a single input, and instead just commits t=
o the number of inputs. This allows for more flexibility, but keeps it easy=
 to get the same single output restriction.<br></div><div style=3D"font-fam=
ily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div>=
<div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:=
rgb(0,0,0)">BIP: <a href=3D"https://github.com/JeremyRubin/bips/blob/op-sec=
ure-the-bag/bip-secure-the-bag.mediawiki" target=3D"_blank">https://github.=
com/JeremyRubin/bips/blob/op-secure-the-bag/bip-secure-the-bag.mediawiki</a=
></div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small=
;color:rgb(0,0,0)">Implementation: <a href=3D"https://github.com/JeremyRubi=
n/bitcoin/tree/secure_the_bag" target=3D"_blank">https://github.com/JeremyR=
ubin/bitcoin/tree/secure_the_bag</a></div><div><div dir=3D"ltr" class=3D"gm=
ail-m_-8983210578190892976gmail_signature"><div dir=3D"ltr"><br></div><div =
dir=3D"ltr"><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 be=
st to eliminate the PUSHDATA and treat OP_SECURETHEBAG like a pushdata dire=
ctly. I thought about how the interpreter works and is implemented and coul=
dn&#39;t come up with something noninvasive.</div></div></div></div></div><=
/blockquote><div><br></div><div>I&#39;m not a Core developer but from what =
I understand, I&#39;d be inclined to to treat OP_SECURETHEBAG as with an im=
mediate 32-byte parameter by modifying <span style=3D"font-family:courier n=
ew,monospace">GetScriptOp</span> to return the 32-byte parameter through <s=
pan style=3D"font-family:courier new,monospace">pvchRet</span>.<br></div><d=
iv><br></div><div><span style=3D"font-family:courier new,monospace">bool Ge=
tScriptOp(CScriptBase::const_iterator&amp; pc, CScriptBase::const_iterator =
end, opcodetype&amp; opcodeRet, std::vector&lt;unsigned char&gt;* pvchRet)<=
br>{<br>=C2=A0 =C2=A0 opcodeRet =3D OP_INVALIDOPCODE;<br>=C2=A0 =C2=A0 if (=
pvchRet)<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 pvchRet-&gt;clear();<br>=C2=A0 =C2=
=A0 if (pc &gt;=3D end)<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 return false;<br><br=
>=C2=A0 =C2=A0 // Read instruction<br>=C2=A0 =C2=A0 if (end - pc &lt; 1)<br=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 return false;<br>=C2=A0 =C2=A0 unsigned int op=
code =3D *pc++;<br><br>=C2=A0 =C2=A0 // Immediate operand<br>=C2=A0 =C2=A0 =
if (opcode &lt;=3D OP_PUSHDATA4)<br>=C2=A0 =C2=A0 {</span></div><div><span =
style=3D"font-family:courier new,monospace">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 // ...<br></span></div><div><span style=3D"font-family:courier=
 new,monospace">=C2=A0 =C2=A0 }</span></div><div><span style=3D"font-family=
:courier new,monospace"><br></span></div><div><span style=3D"font-family:co=
urier new,monospace">=C2=A0=C2=A0=C2=A0 if (<span style=3D"font-family:cour=
ier new,monospace">opcode =3D=3D </span>OP_SECURETHEBAG) {</span></div><div=
><span style=3D"font-family:courier new,monospace">=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 =C2=A0 if (end - pc &lt; 0 || (unsigned int)(end - pc) &lt; 32)<br>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return false;<br>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 if (pvchRet)<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 pvc=
hRet-&gt;assign(pc, pc + 32);<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 pc +=3D 32;</span></div><div><span style=3D"font-family:courier new,monosp=
ace">=C2=A0=C2=A0=C2=A0 }<br></span></div><div><br><span style=3D"font-fami=
ly:courier new,monospace"></span></div><div><span style=3D"font-family:cour=
ier new,monospace">=C2=A0 =C2=A0 opcodeRet =3D static_cast&lt;opcodetype&gt=
;(opcode);<br>=C2=A0 =C2=A0 return true;<br>}</span></div><div>=C2=A0</div>=
<div>and go from there.<br></div><div><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><div dir=3D"ltr" class=3D"gmai=
l-m_-8983210578190892976gmail_signature"><div style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Thank you for your rev=
iew and discussion,<br></div><div dir=3D"ltr"><div style=3D"font-family:ari=
al,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div st=
yle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0=
,0)">Jeremy</div></div><div dir=3D"ltr"><br></div><div dir=3D"ltr"><div sty=
le=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,=
0)">* Plus the name is better</div><br></div></div></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div></div>

--000000000000fb216a058a581e2a--