From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <lf-lists@mattcorallo.com> Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 337FFCAB; Fri, 25 Oct 2019 17:30:47 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.bluematt.me (mail.bluematt.me [69.59.18.99]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 042F287B; Fri, 25 Oct 2019 17:30:45 +0000 (UTC) Received: from [69.59.18.158] (unknown [69.59.18.158]) by mail.bluematt.me (Postfix) with ESMTPSA id 44B27E242E; Fri, 25 Oct 2019 17:30:43 +0000 (UTC) Content-Type: multipart/alternative; boundary=Apple-Mail-A6774A8C-632A-4A79-AD73-EF0AE036EE83 Content-Transfer-Encoding: 7bit From: Matt Corallo <lf-lists@mattcorallo.com> Mime-Version: 1.0 (1.0) Date: Fri, 25 Oct 2019 07:30:41 -1000 Message-Id: <6728FF51-E378-4AED-99BA-ECB83688AA9C@mattcorallo.com> References: <CAD3i26Cf+QpbFXh63NiMig9eceeKaezZwk89A_h_76S_XKkQ9g@mail.gmail.com> In-Reply-To: <CAD3i26Cf+QpbFXh63NiMig9eceeKaezZwk89A_h_76S_XKkQ9g@mail.gmail.com> To: =?utf-8?Q?Johan_Tor=C3=A5s_Halseth?= <johanth@gmail.com> X-Mailer: iPhone Mail (17A878) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE, MIME_QP_LONG_LINE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>, lightning-dev <lightning-dev@lists.linuxfoundation.org> Subject: Re: [bitcoin-dev] [Lightning-dev] CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning) 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: Fri, 25 Oct 2019 17:30:47 -0000 --Apple-Mail-A6774A8C-632A-4A79-AD73-EF0AE036EE83 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I don=E2=80=99te see how? Let=E2=80=99s imagine Party A has two spendable ou= tputs, now they stuff the package size on one of their spendable outlets unt= il it is right at the limit, add one more on their other output (to meet the= Carve-Out), and now Party B can=E2=80=99t do anything. > On Oct 24, 2019, at 21:05, Johan Tor=C3=A5s Halseth <johanth@gmail.com> wr= ote: >=20 > =EF=BB=BF > It essentially changes the rule to always allow CPFP-ing the commitment as= long as there is an output available without any descendants. It changes th= e commitment from "you always need at least, and exactly, one non-CSV output= per party. " to "you always need at least one non-CSV output per party. " >=20 > I realize these limits are there for a reason though, but I'm wondering if= could relax them. Also now that jeremyrubin has expressed problems with the= current mempool limits. >=20 >> On Thu, Oct 24, 2019 at 11:25 PM Matt Corallo <lf-lists@mattcorallo.com> w= rote: >> I may be missing something, but I'm not sure how this changes anything? >>=20 >> If you have a commitment transaction, you always need at least, and >> exactly, one non-CSV output per party. The fact that there is a size >> limitation on the transaction that spends for carve-out purposes only >> effects how many other inputs/outputs you can add, but somehow I doubt >> its ever going to be a large enough number to matter. >>=20 >> Matt >>=20 >> On 10/24/19 1:49 PM, Johan Tor=C3=A5s Halseth wrote: >> > Reviving this old thread now that the recently released RC for bitcoind= >> > 0.19 includes the above mentioned carve-out rule. >> >=20 >> > In an attempt to pave the way for more robust CPFP of on-chain contract= s >> > (Lightning commitment transactions), the carve-out rule was added in >> > https://github.com/bitcoin/bitcoin/pull/15681. However, having worked o= n >> > an implementation of a new commitment format for utilizing the Bring >> > Your Own Fees strategy using CPFP, I=E2=80=99m wondering if the special= case >> > rule should have been relaxed a bit, to avoid the need for adding a 1 >> > CSV to all outputs (in case of Lightning this means HTLC scripts would >> > need to be changed to add the CSV delay). >> >=20 >> > Instead, what about letting the rule be >> >=20 >> > The last transaction which is added to a package of dependent >> > transactions in the mempool must: >> > * Have no more than one unconfirmed parent. >> >=20 >> > This would of course allow adding a large transaction to each output of= >> > the unconfirmed parent, which in effect would allow an attacker to >> > exceed the MAX_PACKAGE_VIRTUAL_SIZE limit in some cases. However, is >> > this a problem with the current mempool acceptance code in bitcoind? I >> > would imagine evicting transactions based on feerate when the max >> > mempool size is met handles this, but I=E2=80=99m asking since it seems= like >> > there has been several changes to the acceptance code and eviction >> > policy since the limit was first introduced. >> >=20 >> > - Johan >> >=20 >> >=20 >> > On Wed, Feb 13, 2019 at 6:57 AM Rusty Russell <rusty@rustcorp.com.au >> > <mailto:rusty@rustcorp.com.au>> wrote: >> >=20 >> > Matt Corallo <lf-lists@mattcorallo.com >> > <mailto:lf-lists@mattcorallo.com>> writes: >> > >>> Thus, even if you imagine a steady-state mempool growth, unless= the >> > >>> "near the top of the mempool" criteria is "near the top of the n= ext >> > >>> block" (which is obviously *not* incentive-compatible) >> > >> >> > >> I was defining "top of mempool" as "in the first 4 MSipa", ie. n= ext >> > >> block, and assumed you'd only allow RBF if the old package wasn'= t >> > in the >> > >> top and the replacement would be. That seems incentive >> > compatible; more >> > >> than the current scheme? >> > > >> > > My point was, because of block time variance, even that criteria >> > doesn't hold up. If you assume a steady flow of new transactions an= d >> > one or two blocks come in "late", suddenly "top 4MWeight" isn't >> > likely to get confirmed until a few blocks come in "early". Given >> > block variance within a 12 block window, this is a relatively likel= y >> > scenario. >> >=20 >> > [ Digging through old mail. ] >> >=20 >> > Doesn't really matter. Lightning close algorithm would be: >> >=20 >> > 1. Give bitcoind unileratal close. >> > 2. Ask bitcoind what current expidited fee is (or survey your memp= ool). >> > 3. Give bitcoind child "push" tx at that total feerate. >> > 4. If next block doesn't contain unilateral close tx, goto 2. >> >=20 >> > In this case, if you allow a simpified RBF where 'you can replace i= f >> > 1. feerate is higher, 2. new tx is in first 4Msipa of mempool, 3. >> > old tx isnt', >> > it works. >> >=20 >> > It allows someone 100k of free tx spam, sure. But it's simple. >> >=20 >> > We could further restrict it by marking the unilateral close someho= w to >> > say "gonna be pushed" and further limiting the child tx weight (say= , >> > 5kSipa?) in that case. >> >=20 >> > Cheers, >> > Rusty. >> > _______________________________________________ >> > Lightning-dev mailing list >> > Lightning-dev@lists.linuxfoundation.org >> > <mailto:Lightning-dev@lists.linuxfoundation.org> >> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >> >=20 --Apple-Mail-A6774A8C-632A-4A79-AD73-EF0AE036EE83 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D= utf-8"></head><body dir=3D"auto"><div dir=3D"ltr">I don=E2=80=99te see how? L= et=E2=80=99s imagine Party A has two spendable outputs, now they stuff the p= ackage size on one of their spendable outlets until it is right at the limit= , add one more on their other output (to meet the Carve-Out), and now Party B= can=E2=80=99t do anything.</div><div dir=3D"ltr"><br><blockquote type=3D"ci= te">On Oct 24, 2019, at 21:05, Johan Tor=C3=A5s Halseth <johanth@gmail.co= m> wrote:<br><br></blockquote></div><blockquote type=3D"cite"><div dir=3D= "ltr">=EF=BB=BF<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr">It essenti= ally changes the rule to always allow CPFP-ing the commitment as long as the= re is an output available without any descendants. It changes the commitment= from "you always need at least, and exactly, one non-CSV output per party. "= to "you always need at least one non-CSV output per party. "</div><div dir=3D= "ltr"><br></div><div>I realize these limits are there for a reason though, b= ut I'm wondering if could relax them. Also now that jeremyrubin has expresse= d problems with the current mempool limits.</div></div></div><br><div class=3D= "gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Oct 24, 2019 at 1= 1:25 PM Matt Corallo <<a href=3D"mailto:lf-lists@mattcorallo.com">lf-list= s@mattcorallo.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote" s= tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd= ing-left:1ex">I may be missing something, but I'm not sure how this changes a= nything?<br> <br> If you have a commitment transaction, you always need at least, and<br> exactly, one non-CSV output per party. The fact that there is a size<br> limitation on the transaction that spends for carve-out purposes only<br> effects how many other inputs/outputs you can add, but somehow I doubt<br> its ever going to be a large enough number to matter.<br> <br> Matt<br> <br> On 10/24/19 1:49 PM, Johan Tor=C3=A5s Halseth wrote:<br> > Reviving this old thread now that the recently released RC for bitcoind= <br> > 0.19 includes the above mentioned carve-out rule.<br> > <br> > In an attempt to pave the way for more robust CPFP of on-chain contract= s<br> > (Lightning commitment transactions), the carve-out rule was added in<br= > > <a href=3D"https://github.com/bitcoin/bitcoin/pull/15681" rel=3D"norefe= rrer" target=3D"_blank">https://github.com/bitcoin/bitcoin/pull/15681</a>. H= owever, having worked on<br> > an implementation of a new commitment format for utilizing the Bring<br= > > Your Own Fees strategy using CPFP, I=E2=80=99m wondering if the special= case<br> > rule should have been relaxed a bit, to avoid the need for adding a 1<b= r> > CSV to all outputs (in case of Lightning this means HTLC scripts would<= br> > need to be changed to add the CSV delay).<br> > <br> > Instead, what about letting the rule be<br> > <br> > The last transaction which is added to a package of dependent<br> > transactions in the mempool must:<br> > * Have no more than one unconfirmed parent.<br> > <br> > This would of course allow adding a large transaction to each output of= <br> > the unconfirmed parent, which in effect would allow an attacker to<br> > exceed the MAX_PACKAGE_VIRTUAL_SIZE limit in some cases. However, is<br= > > this a problem with the current mempool acceptance code in bitcoind? I<= br> > would imagine evicting transactions based on feerate when the max<br> > mempool size is met handles this, but I=E2=80=99m asking since it seems= like<br> > there has been several changes to the acceptance code and eviction<br> > policy since the limit was first introduced.<br> > <br> > - Johan<br> > <br> > <br> > On Wed, Feb 13, 2019 at 6:57 AM Rusty Russell <<a href=3D"mailto:rus= ty@rustcorp.com.au" target=3D"_blank">rusty@rustcorp.com.au</a><br> > <mailto:<a href=3D"mailto:rusty@rustcorp.com.au" target=3D"_blank">r= usty@rustcorp.com.au</a>>> wrote:<br> > <br> > Matt Corallo <<a href=3D"mailto:lf-lists@mattcora= llo.com" target=3D"_blank">lf-lists@mattcorallo.com</a><br> > <mailto:<a href=3D"mailto:lf-lists@mattcorallo.co= m" target=3D"_blank">lf-lists@mattcorallo.com</a>>> writes:<br> > >>> Thus, even if you imagine a steady-stat= e mempool growth, unless the<br> > >>> "near the top of the mempool" criteria i= s "near the top of the next<br> > >>> block" (which is obviously *not* incent= ive-compatible)<br> > >><br> > >> I was defining "top of mempool" as "in the f= irst 4 MSipa", ie. next<br> > >> block, and assumed you'd only allow RBF if t= he old package wasn't<br> > in the<br> > >> top and the replacement would be. Tha= t seems incentive<br> > compatible; more<br> > >> than the current scheme?<br> > ><br> > > My point was, because of block time variance, e= ven that criteria<br> > doesn't hold up. If you assume a steady flow of new t= ransactions and<br> > one or two blocks come in "late", suddenly "top 4MWe= ight" isn't<br> > likely to get confirmed until a few blocks come in "= early". Given<br> > block variance within a 12 block window, this is a r= elatively likely<br> > scenario.<br> > <br> > [ Digging through old mail. ]<br> > <br> > Doesn't really matter. Lightning close algorit= hm would be:<br> > <br> > 1. Give bitcoind unileratal close.<br> > 2. Ask bitcoind what current expidited fee is (= or survey your mempool).<br> > 3. Give bitcoind child "push" tx at that total= feerate.<br> > 4. If next block doesn't contain unilateral cl= ose tx, goto 2.<br> > <br> > In this case, if you allow a simpified RBF where 'yo= u can replace if<br> > 1. feerate is higher, 2. new tx is in first 4Msipa o= f mempool, 3.<br> > old tx isnt',<br> > it works.<br> > <br> > It allows someone 100k of free tx spam, sure. B= ut it's simple.<br> > <br> > We could further restrict it by marking the unilater= al close somehow to<br> > say "gonna be pushed" and further limiting the child= tx weight (say,<br> > 5kSipa?) in that case.<br> > <br> > Cheers,<br> > Rusty.<br> > _______________________________________________<br> > Lightning-dev mailing list<br> > <a href=3D"mailto:Lightning-dev@lists.linuxfoundatio= n.org" target=3D"_blank">Lightning-dev@lists.linuxfoundation.org</a><br> > <mailto:<a href=3D"mailto:Lightning-dev@lists.lin= uxfoundation.org" target=3D"_blank">Lightning-dev@lists.linuxfoundation.org<= /a>><br> > <a href=3D"https://lists.linuxfoundation.org/mailman= /listinfo/lightning-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.= linuxfoundation.org/mailman/listinfo/lightning-dev</a><br> > <br> </blockquote></div> </div></blockquote></body></html>= --Apple-Mail-A6774A8C-632A-4A79-AD73-EF0AE036EE83--