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 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 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: In-Reply-To: To: =?utf-8?Q?Johan_Tor=C3=A5s_Halseth?= 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 , 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 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 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 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 > > > wrote: >> >=20 >> > 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 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 >> > >> > 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
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.

On Oct 24, 2019, at 21:05, Johan Tor=C3=A5s Halseth <johanth@gmail.co= m> wrote:

=EF=BB=BF
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. "

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.

On Thu, Oct 24, 2019 at 1= 1:25 PM Matt Corallo <lf-list= s@mattcorallo.com> wrote:
I may be missing something, but I'm not sure how this changes a= nything?

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. H= owever, 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 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<= br> > 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<= br> > 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:r= usty@rustcorp.com.au>> wrote:
>
>     Matt Corallo <lf-lists@mattcorallo.com
>     <mailto:lf-lists@mattcorallo.com>> writes:
>     >>> Thus, even if you imagine a steady-stat= e mempool growth, unless the
>     >>> "near the top of the mempool" criteria i= s "near the top of the next
>     >>> block" (which is obviously *not* incent= ive-compatible)
>     >>
>     >> I was defining "top of mempool" as "in the f= irst 4 MSipa", ie. next
>     >> block, and assumed you'd only allow RBF if t= he old package wasn't
>     in the
>     >> top and the replacement would be.  Tha= t seems incentive
>     compatible; more
>     >> than the current scheme?
>     >
>     > My point was, because of block time variance, e= ven that criteria
>     doesn't hold up. If you assume a steady flow of new t= ransactions and
>     one or two blocks come in "late", suddenly "top 4MWe= ight" isn't
>     likely to get confirmed until a few blocks come in "= early". Given
>     block variance within a 12 block window, this is a r= elatively likely
>     scenario.
>
>     [ Digging through old mail. ]
>
>     Doesn't really matter.  Lightning close algorit= hm 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 cl= ose tx, goto 2.
>
>     In this case, if you allow a simpified RBF where 'yo= u can replace if
>     1. feerate is higher, 2. new tx is in first 4Msipa o= f mempool, 3.
>     old tx isnt',
>     it works.
>
>     It allows someone 100k of free tx spam, sure.  B= ut it's simple.
>
>     We could further restrict it by marking the unilater= al close somehow 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<= /a>>
>     https://lists.= linuxfoundation.org/mailman/listinfo/lightning-dev
>
= --Apple-Mail-A6774A8C-632A-4A79-AD73-EF0AE036EE83--