diff options
| author | Jeremy <jlrubin@mit.edu> | 2019-05-22 01:10:23 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2019-05-22 08:10:39 +0000 |
| commit | aa728b43b54d4903b46ffaeb6f8324955b2dccc5 (patch) | |
| tree | 6bc6644c332a39372c68e05ef0f9e56075d768e5 | |
| parent | a0103262b95a2c8839f524b7714498c33e57a7b9 (diff) | |
| download | pi-bitcoindev-aa728b43b54d4903b46ffaeb6f8324955b2dccc5.tar.gz pi-bitcoindev-aa728b43b54d4903b46ffaeb6f8324955b2dccc5.zip | |
Re: [bitcoin-dev] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY proposal
| -rw-r--r-- | 57/a416f21c696f6f6edfd669f7564e72fa117bcf | 317 |
1 files changed, 317 insertions, 0 deletions
diff --git a/57/a416f21c696f6f6edfd669f7564e72fa117bcf b/57/a416f21c696f6f6edfd669f7564e72fa117bcf new file mode 100644 index 000000000..d1be3a3bf --- /dev/null +++ b/57/a416f21c696f6f6edfd669f7564e72fa117bcf @@ -0,0 +1,317 @@ +Return-Path: <jlrubin@mit.edu> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 4C21BA70 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 22 May 2019 08:10:39 +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 103CA6C5 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 22 May 2019 08:10:37 +0000 (UTC) +Received: from mail-ed1-f48.google.com (mail-ed1-f48.google.com + [209.85.208.48]) (authenticated bits=0) + (User authenticated as jlrubin@ATHENA.MIT.EDU) + by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x4M8AZjv032581 + (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 22 May 2019 04:10:36 -0400 +Received: by mail-ed1-f48.google.com with SMTP id e24so2506724edq.6 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 22 May 2019 01:10:36 -0700 (PDT) +X-Gm-Message-State: APjAAAXsQ1KTGpwJKxGZIrBXCu0C1RBEgk7xrZxPrTB6QI//TwMlouLl + NIRrQcGnUlmWBB6zeSHt+vzYhe47ydStFak7yqE= +X-Google-Smtp-Source: APXvYqzelPMS5plN0MATMp9KNCrVtAnw7aRCaFFk2oT2hpXvbcT9ys6MzYn9ic2hV0arz4ri2KAxUXkMCVkyzjxHyug= +X-Received: by 2002:a17:906:66c9:: with SMTP id + k9mr20878945ejp.21.1558512635039; + Wed, 22 May 2019 01:10:35 -0700 (PDT) +MIME-Version: 1.0 +References: <CAD5xwhgHyR5qdd09ikvA_vgepj4o+Aqb0JA_T6FuqX56ZNe1RQ@mail.gmail.com> + <VU6YVz_dc9U4BhGd6WWNvYLS-DI1lBE14tpYdXEyIufTZ2OvqQfcWh6RVelCLWTQMWqiNsSf_AM3Pq2hzn3G62RIQwceLx54rRmD-zHCdNU=@protonmail.com> + <CAD5xwhixyvAA0zak86BwG3ZjinUJ37266K_wn_NCa-ECrVmouw@mail.gmail.com> + <CljXxJhTEILR7KZxgZ3o_yJm66XeySWzUY3abCm01blY9yX3AmMczvu41CAm9dr4ZQTDCTQqEM1D4MhEaGASuM54l51DaJmZSKv0eqtPjEo=@protonmail.com> +In-Reply-To: <CljXxJhTEILR7KZxgZ3o_yJm66XeySWzUY3abCm01blY9yX3AmMczvu41CAm9dr4ZQTDCTQqEM1D4MhEaGASuM54l51DaJmZSKv0eqtPjEo=@protonmail.com> +From: Jeremy <jlrubin@mit.edu> +Date: Wed, 22 May 2019 01:10:23 -0700 +X-Gmail-Original-Message-ID: <CAD5xwhiHHemzaRLC7WMeXQ5hgu0rwMKMUym34xTxWO81qqf-oQ@mail.gmail.com> +Message-ID: <CAD5xwhiHHemzaRLC7WMeXQ5hgu0rwMKMUym34xTxWO81qqf-oQ@mail.gmail.com> +To: ZmnSCPxj <ZmnSCPxj@protonmail.com> +Content-Type: multipart/alternative; boundary="000000000000fd54560589757fe4" +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: Wed, 22 May 2019 13:30:30 +0000 +Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +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 <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: Wed, 22 May 2019 08:10:39 -0000 + +--000000000000fd54560589757fe4 +Content-Type: text/plain; charset="UTF-8" + +> * I do not think CoinJoin is much improved by this opcode. +> Typically, you would sign off only if one of the outputs of the +CoinJoin transaction is yours, and this does not really improve this +situation. + +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. +Ideally a coinjoin creates a lot of outputs so that the ownership is +smeared more, but this has a cost at the time of the coinjoin. + +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 need +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. + +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 spendable +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. + + + + +> * Using this for congestion control increases blockchain usage by one TXO +and one input, ending up with *more* bytes onchain, and a UTXO that will be +removed later in (we hope) short time. +> I do not know if this is a good idea, to increase congestion by making +unnecessary intermediate transaction outputs, at times when congestion 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. certified +checks) is superior to having unconfirmed funds. + +For sending money, being able to clear all liabilities in a single txn +decreases 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 +late. If I have 10,000 employees this might be painful if fees are +currently up. + +It also helps to have a backlog of low priority txns to support the fee +market. + +Overall block bandwidth utilization is fairly spikey, so having long term +well known outputs that are not time sensitive can be used to better +utilize bandwidth. + +The total extra bandwidth btw is really small given the expansion factor +optimizations available. + + +> * I cannot find a way to implement Decker-Russell-Osuntokun (or any +offchain update mechanism) on top of this opcode, so I cannot support +replacing `SIGHASH_NOINPUT` with this opcode. +> In particular, while the finite loop support by this opcode appears (at +first glance) to be useable as the "stepper" for an offchain update +mechanism, I cannot find a good way to short-circuit the transaction chain +without `SIGHASH_NOINPUT` anyway. + +I'm not deeply familiar with DRO channels. This opcode isn't a replacement +for SIGHASH_NOINPUT -- SIGHASH_NOINPUT is mentioned merely to contrast +using SIGHASH_NOINPUT for the uses presented in this BIP. + +Lastly there's no 'replacing'. Neither NOINPUT nor COSHV are accepted by +the community at large yet, and they do different things. + + +> * Channel factories created by this opcode do not, by themselves, support +updates to the channel structure. +> But such simple "close only" channel factories can be done using n-of-n +and a pre-signed offchain transaction (especially since the entities +interested in the factory are known and enumerable, and thus can be induced +to sign in order to enter the factory). + +I'm not really an expert at Bitcoin Lightning, but this basic mechanism +should work. + +Imagine the script at a leaf node: + +Taproot([Alice, Bob], [OP_COSHV <H(H(2 coins to uncooperative script))>] +where uncooperative script is: + +Taproot([Alice, Bob], ["1 week" CHECKSEQUENCEVERIFY DROP OP_COSHV <H(H(Pay +alice 2 coins))>) + +Cooperative closing skips the extra transactions. Updates are signed +against the uncooperative script with repudation. E.g.: + + HASH160 <revokehash> EQUAL + IF + <Bob's pubkey> + ELSE + "1 week" CHECKSEQUENCEVERIFY DROP + <Alice's pubkey> + ENDIF + CHECKSIG + +It can even be optimized by letting the uncooperative script branches in +the leaf be blaming Alice or Bob. + +Does that not work? + +--000000000000fd54560589757fe4 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div style=3D"font-family:arial,helvetica,sans-serif;font-= +size:small;color:rgb(0,0,0)" class=3D"gmail_default"></div><br><br>> * I= + do not think CoinJoin is much improved by this opcode.<br><div>> =C2=A0= + Typically, you would sign off only if one of the outputs of the CoinJoin t= +ransaction is yours, and this does not really improve this situation.</div>= +<div><br></div><div><div style=3D"font-family:arial,helvetica,sans-serif;fo= +nt-size:small;color:rgb(0,0,0)" class=3D"gmail_default">Coinjoin benefits a= + lot I think.</div><br></div><br><div style=3D"font-family:arial,helvetica,= +sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">Coinjo= +in is improved because you can fit more users into the protocol and create = +many more outputs at lower cost or include more participants. Ideally a coi= +njoin creates a lot of outputs so that the ownership is smeared more, but t= +his has a cost at the time of the coinjoin.<br></div><div style=3D"font-fam= +ily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"g= +mail_default"><br></div><div style=3D"font-family:arial,helvetica,sans-seri= +f;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">Coinjoin is als= +o improved because you don't reveal the outputs created by the coinjoin= + until some time, perhaps very far in the future, when you need the coin. I= +n fact, you only need to reveal where you're moving the coins to partic= +ipants in your subtree because participants need only verify their branch.<= +br></div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:sma= +ll;color:rgb(0,0,0)" class=3D"gmail_default"><br></div><div style=3D"font-f= +amily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D= +"gmail_default">It also makes the protocol more stable with respect to inpu= +t choice. This is because, similar to how NOINPUT may work, OP_COSHV output= +s are spendable without knowing what the TXID will be. Therefore if someone= + changes their input or non segwit spend script, it won't break the pre= +signed txns. This also means that all the inputs can be ANYONECANPAY, so th= +ere is no need to reveal your inputs before anyone else.</div><div style=3D= +"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" c= +lass=3D"gmail_default"><br></div><div style=3D"font-family:arial,helvetica,= +sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">This c= +ulminates in being able to open channels from a coinjoin safely, I believe = +this is difficult/impossible to do currently.</div><div style=3D"font-famil= +y:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gma= +il_default"><br></div><div style=3D"font-family:arial,helvetica,sans-serif;= +font-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><br></div><div><b= +r></div><br>> * Using this for congestion control increases blockchain u= +sage by one TXO and one input, ending up with *more* bytes onchain, and a U= +TXO that will be removed later in (we hope) short time.<br><div>> =C2=A0= + I do not know if this is a good idea, to increase congestion by making unn= +ecessary intermediate transaction outputs, at times when congestion is a pr= +oblem.</div><div><br></div><div><div style=3D"font-family:arial,helvetica,s= +ans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">This is= + a good idea because it improves QoS for most users.<br></div><div style=3D= +"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" c= +lass=3D"gmail_default"><br></div><div style=3D"font-family:arial,helvetica,= +sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">For re= +ceiving money pending spendable but confirmed payment (i.e. certified check= +s) is superior to having unconfirmed funds.</div><div style=3D"font-family:= +arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail= +_default"><br></div><div style=3D"font-family:arial,helvetica,sans-serif;fo= +nt-size:small;color:rgb(0,0,0)" class=3D"gmail_default">For sending money, = +being able to clear all liabilities in a single txn decreases business expo= +sure 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 late. If I have 10,0= +00 employees this might be painful if fees are currently up.<br></div><div = +style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0= +,0,0)" class=3D"gmail_default"><br></div><div style=3D"font-family:arial,he= +lvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default= +">It also helps to have a backlog of low priority txns to support the fee m= +arket.</div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:= +small;color:rgb(0,0,0)" class=3D"gmail_default"><br></div><div style=3D"fon= +t-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class= +=3D"gmail_default">Overall block bandwidth utilization is fairly spikey, so= + having long term well known outputs that are not time sensitive can be use= +d to better utilize bandwidth.<br></div></div><div><br></div><div><div styl= +e=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0= +)" class=3D"gmail_default">The total extra bandwidth btw is really small gi= +ven the expansion factor optimizations available.</div><br></div><br>> *= + I cannot find a way to implement Decker-Russell-Osuntokun (or any offchain= + update mechanism) on top of this opcode, so I cannot support replacing `SI= +GHASH_NOINPUT` with this opcode.<br><div>> =C2=A0 In particular, while t= +he finite loop support by this opcode appears (at first glance) to be useab= +le as the "stepper" for an offchain update mechanism, I cannot fi= +nd a good way to short-circuit the transaction chain without `SIGHASH_NOINP= +UT` anyway.</div><div><br></div><div><div style=3D"font-family:arial,helvet= +ica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">I&= +#39;m not deeply familiar with DRO channels. This opcode isn't a replac= +ement for SIGHASH_NOINPUT -- SIGHASH_NOINPUT is mentioned merely to contras= +t using SIGHASH_NOINPUT for the uses presented in this BIP. </div><div styl= +e=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0= +)" class=3D"gmail_default"><br></div><div style=3D"font-family:arial,helvet= +ica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">La= +stly there's no 'replacing'. Neither NOINPUT nor COSHV are acce= +pted by the community at large yet, and they do different things.<br></div>= +<br></div><div><br></div>> * Channel factories created by this opcode do= + not, by themselves, support updates to the channel structure.<br><div>>= + =C2=A0 But such simple "close only" channel factories can be don= +e using n-of-n and a pre-signed offchain transaction (especially since the = +entities interested in the factory are known and enumerable, and thus can b= +e induced to sign in order to enter the factory).</div><div><br></div><div>= +<div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:= +rgb(0,0,0)" class=3D"gmail_default">I'm not really an expert at Bitcoin= + Lightning, but this basic mechanism should work. </div><br></div><div><div= + style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(= +0,0,0)" class=3D"gmail_default">Imagine the script at a leaf node:<br></div= +></div><div><br></div><div><div style=3D"font-family:arial,helvetica,sans-s= +erif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">Taproot([Ali= +ce, Bob], [OP_COSHV <H(H(2 coins to uncooperative script))>]<br></div= +></div><div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:= +small;color:rgb(0,0,0)" class=3D"gmail_default"></div><div style=3D"font-fa= +mily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"= +gmail_default">where uncooperative script is:</div><br><span class=3D"gmail= +_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c= +olor:rgb(0,0,0)"></span>Taproot([Alice, Bob], ["<span class=3D"gmail_d= +efault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;col= +or:rgb(0,0,0)">1 week</span>" CHECKSEQUENCEVERIFY DROP<span class=3D"g= +mail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:sma= +ll;color:rgb(0,0,0)"> </span>OP_COSHV <H(H(Pay alice <span class=3D"gmai= +l_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;= +color:rgb(0,0,0)">2 coins</span>))><span class=3D"gmail_default" style= +=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)= +">)</span></div><div><br></div><div><div style=3D"font-family:arial,helveti= +ca,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">Coo= +perative closing skips the extra transactions. Updates are signed against t= +he uncooperative script with repudation. E.g.:</div><div style=3D"font-fami= +ly:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gm= +ail_default"><br></div>=C2=A0 =C2=A0 HASH160 <revokehash> EQUAL<br>= +=C2=A0 =C2=A0 IF<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <Bob's pubkey><br= +>=C2=A0 =C2=A0 ELSE<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 "<span class=3D"gma= +il_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small= +;color:rgb(0,0,0)">1 week</span><span class=3D"gmail_default" style=3D"font= +-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"></span= +>" CHECKSEQUENCEVERIFY DROP<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <Alice&#= +39;s pubkey><br>=C2=A0 =C2=A0 ENDIF<br>=C2=A0 =C2=A0 CHECKSIG<div style= +=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)= +" class=3D"gmail_default"><br></div><div style=3D"font-family:arial,helveti= +ca,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">It = +can even be optimized by letting the uncooperative script branches in the l= +eaf be blaming Alice or Bob.<br></div><div style=3D"font-family:arial,helve= +tica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><= +br></div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:sma= +ll;color:rgb(0,0,0)" class=3D"gmail_default">Does that not work?<br></div><= +br></div></div> + +--000000000000fd54560589757fe4-- + |