Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 41EF7F22 for ; Thu, 23 May 2019 03:45:47 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch [185.70.40.133]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0666E5D0 for ; Thu, 23 May 2019 03:45:45 +0000 (UTC) Date: Thu, 23 May 2019 03:45:39 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1558583143; bh=8aNYDKIMxpTzvD5nRmJyevsq+mpCAXZfCMgVl/hMQbY=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=s27eU7QO8V1nIX5epW7GDyfn05Ygg/PxiqOrLrkDEYtwF+2JG/lvj84inGRphzozg NaMZrKZPljg1B2F7572GWKlTzdgNou8iE1/BTzRYuAUDMQakS8gV4OfY3c763Q825z I/0/qQhb3WUAqVRnt1+cCjTuoCllwTHJSsgjOtf8= To: Jeremy 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=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL, RCVD_IN_DNSWL_LOW, URI_NOVOWEL 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: Thu, 23 May 2019 13:31:42 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY proposal 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: Thu, 23 May 2019 03:45:47 -0000 Good morning Jeremy, 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 Wednesday, May 22, 2019 4:10 PM, Jeremy wrote: > > * I do not think CoinJoin is much improved by this opcode. > > =C2=A0 Typically, you would sign off only if one of the outputs of the = CoinJoin transaction is yours, and this does not really improve this situat= ion. > > Coinjoin benefits a lot I think. > > Coinjoin is improved because you can fit more users into the protocol and= create many more outputs at lower cost or include more participants. Ideal= ly a coinjoin creates a lot of outputs so that the ownership is smeared mor= e, but this has a cost at the time of the coinjoin. But the separate outputs still need to be published at some point in the fu= ture. Further, ideally CoinJoin should be as indistinguishable from normal transa= ctions as possible. (admittedly, the equal-sized outputs often recommended for CoinJoin tend to= blatantly signal "this is a CoinJoin!!", but in any case that "should" be = fixed with some kind of future Confidential Transactions) > > Coinjoin is also improved because you don't reveal the outputs created by= the coinjoin until some time, perhaps very far in the future, when you nee= d the coin. In fact, you only need to reveal where you're moving the coins = to participants in your subtree because participants need only verify their= branch. The same technique of congestion control can still be used with only an "or= dinary" MuSig of all participant keys on the output of the "funding" transa= ction, forming a sort of very tiny CoinJoinXT. This has the advantage that the MuSig is indistinguishable from 1-of-1 spen= ds, which is important for a privacy technique like CoinJoin. Even in the future and we have published the output-side transaction of the= CoinJoin, the transaction chain *could* be interpreted as "one person cons= olidated all his coins in an ordinary 1-of-1 UTXO, then spent on several th= ings at once" whereas use of the `OP_CHECKOUTPUTSHASHVERIFY` is a blatant "= several people agreed to put in their coins provided these outputs were on = the second transaction, i.e. some kind of attempt at hiding their coins". > > It also makes the protocol more stable with respect to input choice. This= is because, similar to how NOINPUT may work, OP_COSHV outputs are spendabl= e without knowing what the TXID will be. Therefore if someone changes their= input or non segwit spend script, it won't break the presigned txns. This = also means that all the inputs can be ANYONECANPAY, so there is no need to = reveal your inputs before anyone else. > > This culminates in being able to open channels from a coinjoin safely, I = believe this is difficult/impossible to do currently. This is already *technically* possible, though no software exists to do so = (sorry, we have bugs between interop of c-lightning and lnd that take up ou= r debugging time already, we cannot spare it for this *yet*). SegWit by itself already allows child transactions to be signed before pare= nt transactions are signed. This safety underlies *all* offchain protocols. See: https://zmnscpxj.github.io/offchain/generalized.html This is sufficient to ensure that channels can be opened from whatever tran= sactions you want, though having to interop with other software that *also*= has to coordinate with other participants in a different protocol is much = more difficult than having to interop with other software using the same pr= otocol. Finally, `SIGHASH_ANYPREVOUT` can *also* do this, since the txid becomes mo= oted. And `SIGHASH_ANYPREVOUT` *also* enables a better offchain update mechanism = (Decker-Russell-Osuntokun, more commonly known as "eltoo") whereas I am una= ble to derive a similar offchain update mechanism using `OP_CHECKOUTPUTSHAS= HVERIFY` (though possibly for lack of trying). > > > * Using this for congestion control increases blockchain usage by one T= XO and one input, ending up with *more* bytes onchain, and a UTXO that will= be removed later in (we hope) short time. > > =C2=A0 I do not know if this is a good idea, to increase congestion by = making unnecessary intermediate transaction outputs, at times when congesti= on is a problem. > > This is a good idea because it improves QoS for most users. > > For receiving money pending spendable but confirmed payment (i.e. certifi= ed checks) is superior to having unconfirmed funds. > > For sending money, being able to clear all liabilities in a single txn de= creases business exposure to fee variance and confirmation time variance. E= .g., if I'm doing payroll in Bitcoin I will pay big fines if I am a day lat= e. If I have 10,000 employees this might be painful if fees are currently u= p. > > It also helps to have a backlog of low priority txns to support the fee m= arket. > > Overall block bandwidth utilization is fairly spikey, so having long term= well known outputs that are not time sensitive can be used to better utili= ze bandwidth. > > The total extra bandwidth btw is really small given the expansion factor = optimizations available. Okay, you have convinced me regarding this point, at least. > > * Channel factories created by this opcode do not, by themselves, suppo= rt updates to the channel structure. > > =C2=A0 But such simple "close only" channel factories can be done using= n-of-n and a pre-signed offchain transaction (especially since the entitie= s interested in the factory are known and enumerable, and thus can be induc= ed to sign in order to enter the factory). > > I'm not really an expert at Bitcoin Lightning, but this basic mechanism s= hould work. > Imagine the script at a leaf node: > > Taproot([Alice, Bob], [OP_COSHV ] > > where uncooperative script is: > > Taproot([Alice, Bob], ["1 week" CHECKSEQUENCEVERIFY DROP OP_COSHV ) > > Cooperative closing skips the extra transactions. Updates are signed agai= nst the uncooperative script with repudation. E.g.: > > =C2=A0 =C2=A0 HASH160 EQUAL > =C2=A0 =C2=A0 IF > =C2=A0 =C2=A0 =C2=A0 =C2=A0 > =C2=A0 =C2=A0 ELSE > =C2=A0 =C2=A0 =C2=A0 =C2=A0 "1 week" CHECKSEQUENCEVERIFY DROP > =C2=A0 =C2=A0 =C2=A0 =C2=A0 > =C2=A0 =C2=A0 ENDIF > =C2=A0 =C2=A0 CHECKSIG > > It can even be optimized by letting the uncooperative script branches in = the leaf be blaming Alice or Bob. > > Does that not work? Possibly, but the point is that an n-of-n MuSig will work just as well and = we would not need to reveal the Taproot key (33 bytes) and the specific scr= ipt containing the output hash (1+32 bytes) we want, we just have to reveal= a single 64-byte signature. My objection here is simply that n-of-n already exists, it will work alread= y using that (and it is much more likely to be assured of getting into base= layer). Again, we only need to use SegWit and sign transactions in reverse order to= ensure proper operation. This is already what is done for normal channel opens (the initial commitme= nt transactions are signed first, then the funding transaction is signed an= d confirmed onchain). Regards, ZmnSCPxj