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 C2EA0AA5 for ; Sun, 2 Jun 2019 21:32:37 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D8965844 for ; Sun, 2 Jun 2019 21:32:36 +0000 (UTC) Received: from mail-ed1-f44.google.com (mail-ed1-f44.google.com [209.85.208.44]) (authenticated bits=0) (User authenticated as jlrubin@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x52LWYve003684 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Sun, 2 Jun 2019 17:32:35 -0400 Received: by mail-ed1-f44.google.com with SMTP id w37so23926043edw.4 for ; Sun, 02 Jun 2019 14:32:35 -0700 (PDT) X-Gm-Message-State: APjAAAW6P85Ll1jtTd3uiXtd1Ya10AzIPW6BYCgnOILkMCqK4YBAnFz4 w0jjAVEOuXX9o4rnp9nmFyh/YtmkRMZNzacBqp8= X-Google-Smtp-Source: APXvYqw9IxWIVeVmuekFpAJEjKVMTMyU13BLJIuDbuGxN8CP1gORVWr3Ci+Shoukk2/tQhBkfC7JAKnUfB3VRtp20UQ= X-Received: by 2002:a17:906:30c4:: with SMTP id b4mr3062002ejb.276.1559511153764; Sun, 02 Jun 2019 14:32:33 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jeremy Date: Sun, 2 Jun 2019 14:32:20 -0700 X-Gmail-Original-Message-ID: Message-ID: To: "Russell O'Connor" Content-Type: multipart/alternative; boundary="00000000000057f178058a5dfcde" X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED 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 Cc: Bitcoin Protocol Discussion 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 21:32:37 -0000 --00000000000057f178058a5dfcde Content-Type: text/plain; charset="UTF-8" Hi Russell, Thanks for the response. I double checked my work in drafting my response and realized I didn't address all the malleability concerns, I believe I have now (fingers crossed) addressed all points of malleability. *The malleability concerns are as follows:* A TXID is computed as: def txid(self): r = b"" r += struct.pack("
Hi Russe= ll,

Thanks for the response. I double checked my work in drafting my = response and realized I didn't address all the malleability concerns, I= believe I have now (fingers crossed) addressed all points of malleability.=

The malleability concerns are as follows:

A TXID is com= puted as:

def txid(self):
= =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 r =3D b""
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0r +=3D struct.pack("<i", self.nVersion)
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r +=3D ser_vector(self.vin)
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0r +=3D ser_vector(self.vout)
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0r +=3D struct.pack("<I", self.nLockTime)
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return sha256(r)

if the bag has= h is just:

def get_bag_hash(self)= :
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 r =3D b""
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r +=3D ser_= vector(self.vout)
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0return TaggedHash("BagHash", r)

W= e allow changing a few things: nVersion, nLockTime, scriptSig (per input), = number of inputs, nSequence (per input) which can change the TXID/what the = transaction does.

changing nVersion: can disable BIP68, change = TXID
changing nLockTime: can chang= e TXID
changing nSequence: can cha= nge TXID
changing number of inputs= : half spend problem, change TXID
changing scriptsigs: change TXID if co-spent with legacy input
<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ;font-size:small;color:rgb(0,0,0)">
Instead, we can use the following digest:

=C2=A0 =C2= =A0 def get_bag_hash(self):
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r =3D b&qu= ot;"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r +=3D struct.pack("<= ;i", self.nVersion)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r +=3D struct= .pack("<I", self.nLockTime)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0r +=3D sha256(b"".join(out.serialize() for out in self.vout))<= br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r +=3D sha256(b"".join(struc= t.pack("<I", inp.nSequence) for inp in self.vin))
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0r +=3D struct.pack("<Q", len(self.v= in))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0for inp in self.vin:
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r +=3D ser_string(inp.scriptSig)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return TaggedHash("BagHash", = r)

which should lock in all the relevant bits. The only par= t left out is the COutpoint, which can't be known ahead of time (becaus= e it depends on the creating txn). Technically, len(vin) is redundant with = sha256(b"".join(struct.pack("<I", inp.nSequence) for= inp in self.vin)), because the length padding on the hash implied the numb= er of inputs, but I figured it's best to err on explicit.

A= further benefit (in a CISC sense) of committing to all these values is tha= t we enforce CLTV and CSV semantics for free on OP_SECURETHEBAG scripts, wh= ich helps with channels.

<= /div>


Treating OP_SE= CURETHEBAG as a PUSHDATA:
<= br>
I agree in theory it's= nicer, and am 100% open to implementing it that way. The only concern I ha= ve with doing it this way is that it means that a flags must be added to Ge= tOp (or GetOp must be modularized to be per-script version) because it affe= cts script parsing, as opposed to using a multibyte opcode which contains a= pushdata, which remain compatible with prior script parsing.

I'd like to get rough consensus on the best approach for compatibili= ty with downstream software, hence choosing this option for the draft.

Personally, my preference is to *not* do flags and just have a sepa= rate parser version which cleans up some of our past sins. We can experimen= t with a fancier parser (as you've shown in Haskell/Rust/Coq), perhaps = even bitwise huffman encoding opcodes to save space on scripts (i.e. the 7 = most common opcodes could fit within 3 bits) or whatever else we like. I ju= st didn't want to have the scope creep too far on this particular BIP, = but I'm with you that lookahead is a hack compared to an actual paramet= rized argument.

I think you'd also appreciate the templ= ate script expansion approach mentioned in the BIP -- it gets around some o= f these concerns, but requires changes to Taproot.


<= /div>


--00000000000057f178058a5dfcde--