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 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: <878t163qzi.fsf@rustcorp.com.au> <725fc55a-6263-a9fc-74a5-1017cb1cc885@mattcorallo.com> <87wonfem03.fsf@rustcorp.com.au> <87zhr0gvw0.fsf@rustcorp.com.au> <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?= Date: Fri, 25 Oct 2019 09:05:15 +0200 Message-ID: To: Matt Corallo 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 , lightning-dev 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 > > wrote: > > > > Matt Corallo > > 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 > > > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > > --0000000000004d89f10595b6c676 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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. "

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>
O= n 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 bitcoin= d
> 0.19 includes the above mentioned carve-out rule.
>
> In an attempt to pave the way for more robust CPFP of on-chain contrac= ts
> (Lightning commitment transactions), the carve-out rule was added in > https://github.com/bitcoin/bitcoin/pull/15681.= However, having worked on
> an implementation of a new commitment format for utilizing the Bring > Your Own Fees strategy using CPFP, I=E2=80=99m wondering if the specia= l case
> 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=
> 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:
> =C2=A0 * Have no more than one unconfirmed parent.
>
> This would of course allow adding a large transaction to each output o= f
> 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 seem= s 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:
>
>=C2=A0 =C2=A0 =C2=A0Matt Corallo <lf-lists@mattcorallo.com
>=C2=A0 =C2=A0 =C2=A0<mailto:lf-lists@mattcorallo.com>> writes:
>=C2=A0 =C2=A0 =C2=A0>>> Thus, even if you imagine a steady-sta= te mempool growth, unless the
>=C2=A0 =C2=A0 =C2=A0>>> "near the top of the mempool"= ; criteria is "near the top of the next
>=C2=A0 =C2=A0 =C2=A0>>> block" (which is obviously *not* = incentive-compatible)
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> I was defining "top of mempool" = as "in the first 4 MSipa", ie. next
>=C2=A0 =C2=A0 =C2=A0>> block, and assumed you'd only allow RB= F if the old package wasn't
>=C2=A0 =C2=A0 =C2=A0in the
>=C2=A0 =C2=A0 =C2=A0>> top and the replacement would be.=C2=A0 Th= at seems incentive
>=C2=A0 =C2=A0 =C2=A0compatible; more
>=C2=A0 =C2=A0 =C2=A0>> than the current scheme?
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> My point was, because of block time variance, = even that criteria
>=C2=A0 =C2=A0 =C2=A0doesn't hold up. If you assume a steady flow of= new transactions and
>=C2=A0 =C2=A0 =C2=A0one or two blocks come in "late", suddenl= y "top 4MWeight" isn't
>=C2=A0 =C2=A0 =C2=A0likely to get confirmed until a few blocks come in = "early". Given
>=C2=A0 =C2=A0 =C2=A0block variance within a 12 block window, this is a = relatively likely
>=C2=A0 =C2=A0 =C2=A0scenario.
>
>=C2=A0 =C2=A0 =C2=A0[ Digging through old mail. ]
>
>=C2=A0 =C2=A0 =C2=A0Doesn't really matter.=C2=A0 Lightning close al= gorithm would be:
>
>=C2=A0 =C2=A0 =C2=A01.=C2=A0 Give bitcoind unileratal close.
>=C2=A0 =C2=A0 =C2=A02.=C2=A0 Ask bitcoind what current expidited fee is= (or survey your mempool).
>=C2=A0 =C2=A0 =C2=A03.=C2=A0 Give bitcoind child "push" tx at= that total feerate.
>=C2=A0 =C2=A0 =C2=A04.=C2=A0 If next block doesn't contain unilater= al close tx, goto 2.
>
>=C2=A0 =C2=A0 =C2=A0In this case, if you allow a simpified RBF where &#= 39;you can replace if
>=C2=A0 =C2=A0 =C2=A01. feerate is higher, 2. new tx is in first 4Msipa = of mempool, 3.
>=C2=A0 =C2=A0 =C2=A0old tx isnt',
>=C2=A0 =C2=A0 =C2=A0it works.
>
>=C2=A0 =C2=A0 =C2=A0It allows someone 100k of free tx spam, sure.=C2=A0= But it's simple.
>
>=C2=A0 =C2=A0 =C2=A0We could further restrict it by marking the unilate= ral close somehow to
>=C2=A0 =C2=A0 =C2=A0say "gonna be pushed" and further limitin= g the child tx weight (say,
>=C2=A0 =C2=A0 =C2=A05kSipa?) in that case.
>
>=C2=A0 =C2=A0 =C2=A0Cheers,
>=C2=A0 =C2=A0 =C2=A0Rusty.
>=C2=A0 =C2=A0 =C2=A0_______________________________________________
>=C2=A0 =C2=A0 =C2=A0Lightning-dev mailing list
>=C2=A0 =C2=A0 =C2=A0Lightning-dev@lists.linuxfoundation.org
>=C2=A0 =C2=A0 =C2=A0<mailto:Lightning-dev@lists.linuxfoundation.or= g>
>=C2=A0 =C2=A0 =C2=A0https://list= s.linuxfoundation.org/mailman/listinfo/lightning-dev
>
--0000000000004d89f10595b6c676--