Return-Path: <johanth@gmail.com> Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 84ACFD12; Fri, 25 Oct 2019 07:05:32 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lj1-f178.google.com (mail-lj1-f178.google.com [209.85.208.178]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 275F014D; Fri, 25 Oct 2019 07:05:29 +0000 (UTC) Received: by mail-lj1-f178.google.com with SMTP id c4so1419453lja.11; Fri, 25 Oct 2019 00:05:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=A+CnRHVqxVE4r6jQSRR7R5qUe8g/lngmG4J3gZc6MzQ=; b=X1sHaGE+Hr4W5BGQHyMaGFTcKiiP9U7v3seUgPnh1RwIG4tmzZt2YCq54RiPoesT6e 4dTsYc1eFXJFD3HXrmXv+rv+0fQBtNKn5nR9Nms7qQgVBdK4B5R6sBOhy251a+ZSh0wT DCMQSbzI/+ji9/3epcAoaWLQxxbkYjhO+LAlnuL2hzQCoUgYP4NT8yroSpBmSjYY3/Ty mJSF75LNpYDZR5LpA3b6MyD3/RmvDrD83gNo8/K2GgsxhZlYfeCmMzkM2deAcq8haUNx PDpZkzTpwhO2JXZA7hAjIbBDxWi9q09+dUerjC+NZcpJAdsigaRMajslpKdrA0Hxa3LV YjsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=A+CnRHVqxVE4r6jQSRR7R5qUe8g/lngmG4J3gZc6MzQ=; b=PAy+nFokA+b5JvCawmvIkn7APoHJLlGP09xVWNnWhmh17uxjvpgvINwI2WwUlCURnY E4+W60pN4oUeptE4locDVz2kNfeuWEYuYqP2nm9jKU0SDRZZDaxdpOvRHXURpKSfBRYb AMcu3oO0IhDqGoy232zOeUBjHwDuMHExowmi5TPblFsLBuWXPMrk/fhR/yCq7o35IK4Q HIV0FfaLFaIUwrAIAh4v2pDKOsJk4xORATNLqt6jDwE9NWjyVY8iwy7I9nGpCoK7Ts6H d6Co11jMiRtzXEq4oLzaVR1f+sQJvT4NmVDCS96TnySDt5pgwL4umE1OCnRnzRi0Nqyz CWQg== X-Gm-Message-State: APjAAAWlivMByG1OPnzydOLkzBJUvLxW6QRwdXXuyqYb+0zLs1O1vK9h 49RaUY+Igl5T5+JJmIWpFINOCH1T1Gx88RGG0rEmKSiQ X-Google-Smtp-Source: APXvYqx2guSpgXDAzdSAGbUWyME0v3mDl0jaRYCjOp76p7h+7U884JrK+ankLAv8TY0j8HVENPahoFDlIwyo4w8iHr8= X-Received: by 2002:a2e:9ace:: with SMTP id p14mr1225808ljj.222.1571987127108; Fri, 25 Oct 2019 00:05:27 -0700 (PDT) MIME-Version: 1.0 References: <c3f68b73-84c6-7428-4bf6-b47802141392@mattcorallo.com> <878t163qzi.fsf@rustcorp.com.au> <725fc55a-6263-a9fc-74a5-1017cb1cc885@mattcorallo.com> <87wonfem03.fsf@rustcorp.com.au> <D072562F-5AD0-4B38-94D1-A0AEF04C3DEB@mattcorallo.com> <87zhr0gvw0.fsf@rustcorp.com.au> <CAD3i26AjhQ9VkCo_5y8aqZ_8YvSqKP2MCkdRv8YunjAhmmXz=Q@mail.gmail.com> <83915e8a-f49a-8233-0389-934c189f770c@mattcorallo.com> In-Reply-To: <83915e8a-f49a-8233-0389-934c189f770c@mattcorallo.com> From: =?UTF-8?Q?Johan_Tor=C3=A5s_Halseth?= <johanth@gmail.com> Date: Fri, 25 Oct 2019 09:05:15 +0200 Message-ID: <CAD3i26Cf+QpbFXh63NiMig9eceeKaezZwk89A_h_76S_XKkQ9g@mail.gmail.com> To: Matt Corallo <lf-lists@mattcorallo.com> Content-Type: multipart/alternative; boundary="0000000000004d89f10595b6c676" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DOS_RCVD_IP_TWICE_B, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE 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, 28 Oct 2019 10:06:48 +0000 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 07:05:32 -0000 --0000000000004d89f10595b6c676 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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. " 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. On Thu, Oct 24, 2019 at 11:25 PM Matt Corallo <lf-lists@mattcorallo.com> wrote: > I may be missing something, but I'm not sure how this changes anything? > > 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. > > Matt > > 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. > > > > 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). > > > > Instead, what about letting the rule be > > > > The last transaction which is added to a package of dependent > > transactions in the mempool must: > > * Have no more than one unconfirmed parent. > > > > 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. > > > > - Johan > > > > > > On Wed, Feb 13, 2019 at 6:57 AM Rusty Russell <rusty@rustcorp.com.au > > <mailto:rusty@rustcorp.com.au>> wrote: > > > > 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 > next > > >>> block" (which is obviously *not* incentive-compatible) > > >> > > >> I was defining "top of mempool" as "in the first 4 MSipa", ie. > next > > >> 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. > > > > [ Digging through old mail. ] > > > > Doesn't really matter. Lightning close algorithm would be: > > > > 1. Give bitcoind unileratal close. > > 2. Ask bitcoind what current expidited fee is (or survey your > mempool). > > 3. Give bitcoind child "push" tx at that total feerate. > > 4. If next block doesn't contain unilateral close tx, goto 2. > > > > 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. > > > > It allows someone 100k of free tx spam, sure. But it's simple. > > > > 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. > > > > 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 > > > --0000000000004d89f10595b6c676 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr">It essentially changes t= he rule to always allow CPFP-ing the commitment as long as there is an outp= ut 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. "</di= v><div dir=3D"ltr"><br></div><div>I realize these limits are there for a re= ason though, but I'm wondering if could relax them. Also now that jerem= yrubin has expressed problems with the current mempool limits.</div></div><= /div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">O= n Thu, Oct 24, 2019 at 11:25 PM Matt Corallo <<a href=3D"mailto:lf-lists= @mattcorallo.com">lf-lists@mattcorallo.com</a>> wrote:<br></div><blockqu= ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px= solid rgb(204,204,204);padding-left:1ex">I may be missing something, but I= 'm not sure how this changes anything?<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 bitcoin= d<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 contrac= ts<br> > (Lightning commitment transactions), the carve-out rule was added in<b= r> > <a href=3D"https://github.com/bitcoin/bitcoin/pull/15681" rel=3D"noref= errer" target=3D"_blank">https://github.com/bitcoin/bitcoin/pull/15681</a>.= However, having worked on<br> > an implementation of a new commitment format for utilizing the Bring<b= r> > Your Own Fees strategy using CPFP, I=E2=80=99m wondering if the specia= l case<br> > rule should have been relaxed a bit, to avoid the need for adding a 1<= br> > 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> > =C2=A0 * Have no more than one unconfirmed parent.<br> > <br> > This would of course allow adding a large transaction to each output o= f<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<b= r> > 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 seem= s 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:ru= sty@rustcorp.com.au" target=3D"_blank">rusty@rustcorp.com.au</a><br> > <mailto:<a href=3D"mailto:rusty@rustcorp.com.au" target=3D"_blank">= rusty@rustcorp.com.au</a>>> wrote:<br> > <br> >=C2=A0 =C2=A0 =C2=A0Matt Corallo <<a href=3D"mailto:lf-lists@mattcor= allo.com" target=3D"_blank">lf-lists@mattcorallo.com</a><br> >=C2=A0 =C2=A0 =C2=A0<mailto:<a href=3D"mailto:lf-lists@mattcorallo.c= om" target=3D"_blank">lf-lists@mattcorallo.com</a>>> writes:<br> >=C2=A0 =C2=A0 =C2=A0>>> Thus, even if you imagine a steady-sta= te mempool growth, unless the<br> >=C2=A0 =C2=A0 =C2=A0>>> "near the top of the mempool"= ; criteria is "near the top of the next<br> >=C2=A0 =C2=A0 =C2=A0>>> block" (which is obviously *not* = incentive-compatible)<br> >=C2=A0 =C2=A0 =C2=A0>><br> >=C2=A0 =C2=A0 =C2=A0>> I was defining "top of mempool" = as "in the first 4 MSipa", ie. next<br> >=C2=A0 =C2=A0 =C2=A0>> block, and assumed you'd only allow RB= F if the old package wasn't<br> >=C2=A0 =C2=A0 =C2=A0in the<br> >=C2=A0 =C2=A0 =C2=A0>> top and the replacement would be.=C2=A0 Th= at seems incentive<br> >=C2=A0 =C2=A0 =C2=A0compatible; more<br> >=C2=A0 =C2=A0 =C2=A0>> than the current scheme?<br> >=C2=A0 =C2=A0 =C2=A0><br> >=C2=A0 =C2=A0 =C2=A0> My point was, because of block time variance, = even that criteria<br> >=C2=A0 =C2=A0 =C2=A0doesn't hold up. If you assume a steady flow of= new transactions and<br> >=C2=A0 =C2=A0 =C2=A0one or two blocks come in "late", suddenl= y "top 4MWeight" isn't<br> >=C2=A0 =C2=A0 =C2=A0likely to get confirmed until a few blocks come in = "early". Given<br> >=C2=A0 =C2=A0 =C2=A0block variance within a 12 block window, this is a = relatively likely<br> >=C2=A0 =C2=A0 =C2=A0scenario.<br> > <br> >=C2=A0 =C2=A0 =C2=A0[ Digging through old mail. ]<br> > <br> >=C2=A0 =C2=A0 =C2=A0Doesn't really matter.=C2=A0 Lightning close al= gorithm would be:<br> > <br> >=C2=A0 =C2=A0 =C2=A01.=C2=A0 Give bitcoind unileratal close.<br> >=C2=A0 =C2=A0 =C2=A02.=C2=A0 Ask bitcoind what current expidited fee is= (or survey your mempool).<br> >=C2=A0 =C2=A0 =C2=A03.=C2=A0 Give bitcoind child "push" tx at= that total feerate.<br> >=C2=A0 =C2=A0 =C2=A04.=C2=A0 If next block doesn't contain unilater= al close tx, goto 2.<br> > <br> >=C2=A0 =C2=A0 =C2=A0In this case, if you allow a simpified RBF where &#= 39;you can replace if<br> >=C2=A0 =C2=A0 =C2=A01. feerate is higher, 2. new tx is in first 4Msipa = of mempool, 3.<br> >=C2=A0 =C2=A0 =C2=A0old tx isnt',<br> >=C2=A0 =C2=A0 =C2=A0it works.<br> > <br> >=C2=A0 =C2=A0 =C2=A0It allows someone 100k of free tx spam, sure.=C2=A0= But it's simple.<br> > <br> >=C2=A0 =C2=A0 =C2=A0We could further restrict it by marking the unilate= ral close somehow to<br> >=C2=A0 =C2=A0 =C2=A0say "gonna be pushed" and further limitin= g the child tx weight (say,<br> >=C2=A0 =C2=A0 =C2=A05kSipa?) in that case.<br> > <br> >=C2=A0 =C2=A0 =C2=A0Cheers,<br> >=C2=A0 =C2=A0 =C2=A0Rusty.<br> >=C2=A0 =C2=A0 =C2=A0_______________________________________________<br> >=C2=A0 =C2=A0 =C2=A0Lightning-dev mailing list<br> >=C2=A0 =C2=A0 =C2=A0<a href=3D"mailto:Lightning-dev@lists.linuxfoundati= on.org" target=3D"_blank">Lightning-dev@lists.linuxfoundation.org</a><br> >=C2=A0 =C2=A0 =C2=A0<mailto:<a href=3D"mailto:Lightning-dev@lists.li= nuxfoundation.org" target=3D"_blank">Lightning-dev@lists.linuxfoundation.or= g</a>><br> >=C2=A0 =C2=A0 =C2=A0<a href=3D"https://lists.linuxfoundation.org/mailma= n/listinfo/lightning-dev" rel=3D"noreferrer" target=3D"_blank">https://list= s.linuxfoundation.org/mailman/listinfo/lightning-dev</a><br> > <br> </blockquote></div> --0000000000004d89f10595b6c676--