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 632BFDC3 for ; Sun, 2 Jun 2019 05:35:51 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40136.protonmail.ch (mail-40136.protonmail.ch [185.70.40.136]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6E7B819B for ; Sun, 2 Jun 2019 05:35:50 +0000 (UTC) Date: Sun, 02 Jun 2019 05:35:43 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1559453748; bh=ovNnGZWrIA6lJ1TipLbCtTR+XqkKf1S7p9QwXNiKLf4=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID: From; b=qb3jpI1uZ+xJm/5jYKXVXEbw1cH2Ahf2LVqKv1RX09fF5nb66FY4mgDbB0g7wPhSI pcEhP4T1IUsGpna3scQkfucjn3Ahl6eZuFOIWmO/2R6wb/xsAEhMgHDbbRYwMlcs6r HYwzdHh694UNSyp15vpX2QvhE+lyu4RKgLi1+HDA= To: Jeremy , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL, RCVD_IN_DNSWL_LOW 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: Sun, 02 Jun 2019 13:20:57 +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 05:35:51 -0000 > Using an OP_SECURETHEBAG Taproot, the recipient may even give the sender = an address which makes a channel unbeknownst to them. This requires special design to be safe. Every offchain protocol requires a backout transaction to be created before= the funding transaction output is committed onchain. This backout transaction ensures that the funder of the channel can back ou= t if the other side aborts the protocol. For Poon-Dryja channels this is the initial commitment transaction. The continued operation of the protocol requires the initial commitment to = be revoked at the next update. So we need a plausible backout for the receiver first. To do so, we make the funding transaction address a Taproot with internal p= ubkey 2-of-2 of the receiver and its channel counterparty. The Taproot hides a single script alternative, a `OP_SECURETHEBAG` that ens= ures it is paid out to a pure script (i.e. Taproot internal key is a NUMS p= oint), the scripts forming a revocable output to the receiver (let receiver= claim with `OP_CHECKSEQUENCEVERIFY`, or counterparty to revoke immediately= if it knows revocation key). This is essentially a walletless channel open, which I described before wit= h `SIGHASH_NOINPUT`. Channel factories using `OP_SECURETHEBAG` cannot be updated (i.e. not able = to close channels and reuse funds to open new channels offchain), i.e. clos= e-only factories. The above revocation trick only works with two participants, and it would b= e largely pointless to have 2-participant factories (unless you were e.g. t= ransporting HTLCs separately from DLCs in two channels of the same factory)= . Channel factories based on the Decker-Russell-Osuntokun mechanism ("eltoo")= allow reorganizing channels offchain, without hitting the chain at all. These need `SIGHASH_NOINPUT`/`SIGHASH_ANYPREVOUT`. For channel factories, `SIGHASH_NOINPUT` is better. `OP_SECURETHEBAG` requires the funding output to commit to a particular out= put set. `SIGHASH_NOINPUT` lets the signatories introduce a new possible output set = later. One might compare `OP_SECURETHEBAG` to MAST, while `SIGHASH_NOINPUT` is com= parable to Graftroot. MAST has a fixed set of alternatives, while Graftroot allows signatories to= add new alternatives later. Regards, ZmnSCPxj 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 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Saturday, June 1, 2019 1:35 PM, Jeremy via bitcoin-dev wrote: > Hi All, > > OP_CHECKOUTPUTSHASHVERIFY is retracted in favor of OP_SECURETHEBAG*. OP_S= ECURETHEBAG does more or less the same thing, but fixes malleability issues= and lifts the single output restriction to a known number of inputs restri= ction. > > OP_CHECKOUTPUTSVERIFY had some issues with malleability of version and lo= cktime. OP_SECURETHEBAG commits to both of these values. > > 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-secur= e-the-bag.mediawiki > Implementation: https://github.com/JeremyRubin/bitcoin/tree/secure_the_ba= g > > A particularly useful topic of discussion is how best to eliminate the PU= SHDATA and treat OP_SECURETHEBAG like a pushdata directly. I thought about = how the interpreter works and is implemented and couldn't come up with some= thing noninvasive. > > Thank you for your review and discussion, > > Jeremy > > * Plus the name is better