From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 8E86A927 for ; 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 ; Sun, 2 Jun 2019 14:32:45 +0000 (UTC) Received: by mail-it1-f175.google.com with SMTP id j17so15127706itk.0 for ; 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: In-Reply-To: From: "Russell O'Connor" Date: Sun, 2 Jun 2019 10:32:33 -0400 Message-ID: To: Jeremy , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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* 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(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


=
On Sat, Jun 1, 2019 at 12:47 PM Jerem= y via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
Hi Al= l,

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.
<= div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:r= gb(0,0,0)">
OP_CHECKOUTPUTSVERIFY had some issues with= malleability of version and locktime. OP_SECURETHEBAG commits to both of t= hese values.

Can you elabo= rate a bit more on what the issues were?
=C2=A0
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.

=

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't come up with something noninvasive.
<= /blockquote>

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

bool Ge= tScriptOp(CScriptBase::const_iterator& pc, CScriptBase::const_iterator = end, opcodetype& opcodeRet, std::vector<unsigned char>* pvchRet)<= br>{
=C2=A0 =C2=A0 opcodeRet =3D OP_INVALIDOPCODE;
=C2=A0 =C2=A0 if (= pvchRet)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 pvchRet->clear();
=C2=A0 =C2= =A0 if (pc >=3D end)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 return false;
=C2=A0 =C2=A0 // Read instruction
=C2=A0 =C2=A0 if (end - pc < 1)=C2=A0 =C2=A0 =C2=A0 =C2=A0 return false;
=C2=A0 =C2=A0 unsigned int op= code =3D *pc++;

=C2=A0 =C2=A0 // Immediate operand
=C2=A0 =C2=A0 = if (opcode <=3D OP_PUSHDATA4)
=C2=A0 =C2=A0 {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 // ...
=C2=A0 =C2=A0 }

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

=C2=A0 =C2=A0 opcodeRet =3D static_cast<opcodetype>= ;(opcode);
=C2=A0 =C2=A0 return true;
}
=C2=A0
=
and go from there.

Thank you for your rev= iew and discussion,

Jeremy

* Plus the name is better

_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000fb216a058a581e2a--