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 &quot;=
you always need at least, and exactly, one non-CSV output per party. &quot;=
 to &quot;you always need at least one non-CSV output per party. &quot;</di=
v><div dir=3D"ltr"><br></div><div>I realize these limits are there for a re=
ason though, but I&#39;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 &lt;<a href=3D"mailto:lf-lists=
@mattcorallo.com">lf-lists@mattcorallo.com</a>&gt; 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=
&#39;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>
&gt; Reviving this old thread now that the recently released RC for bitcoin=
d<br>
&gt; 0.19 includes the above mentioned carve-out rule.<br>
&gt; <br>
&gt; In an attempt to pave the way for more robust CPFP of on-chain contrac=
ts<br>
&gt; (Lightning commitment transactions), the carve-out rule was added in<b=
r>
&gt; <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>
&gt; an implementation of a new commitment format for utilizing the Bring<b=
r>
&gt; Your Own Fees strategy using CPFP, I=E2=80=99m wondering if the specia=
l case<br>
&gt; rule should have been relaxed a bit, to avoid the need for adding a 1<=
br>
&gt; CSV to all outputs (in case of Lightning this means HTLC scripts would=
<br>
&gt; need to be changed to add the CSV delay).<br>
&gt; <br>
&gt; Instead, what about letting the rule be<br>
&gt; <br>
&gt; The last transaction which is added to a package of dependent<br>
&gt; transactions in the mempool must:<br>
&gt; =C2=A0 * Have no more than one unconfirmed parent.<br>
&gt; <br>
&gt; This would of course allow adding a large transaction to each output o=
f<br>
&gt; the unconfirmed parent, which in effect would allow an attacker to<br>
&gt; exceed the MAX_PACKAGE_VIRTUAL_SIZE limit in some cases. However, is<b=
r>
&gt; this a problem with the current mempool acceptance code in bitcoind? I=
<br>
&gt; would imagine evicting transactions based on feerate when the max<br>
&gt; mempool size is met handles this, but I=E2=80=99m asking since it seem=
s like<br>
&gt; there has been several changes to the acceptance code and eviction<br>
&gt; policy since the limit was first introduced.<br>
&gt; <br>
&gt; - Johan<br>
&gt; <br>
&gt; <br>
&gt; On Wed, Feb 13, 2019 at 6:57 AM Rusty Russell &lt;<a href=3D"mailto:ru=
sty@rustcorp.com.au" target=3D"_blank">rusty@rustcorp.com.au</a><br>
&gt; &lt;mailto:<a href=3D"mailto:rusty@rustcorp.com.au" target=3D"_blank">=
rusty@rustcorp.com.au</a>&gt;&gt; wrote:<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0Matt Corallo &lt;<a href=3D"mailto:lf-lists@mattcor=
allo.com" target=3D"_blank">lf-lists@mattcorallo.com</a><br>
&gt;=C2=A0 =C2=A0 =C2=A0&lt;mailto:<a href=3D"mailto:lf-lists@mattcorallo.c=
om" target=3D"_blank">lf-lists@mattcorallo.com</a>&gt;&gt; writes:<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt;&gt;&gt; Thus, even if you imagine a steady-sta=
te mempool growth, unless the<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt;&gt;&gt; &quot;near the top of the mempool&quot=
; criteria is &quot;near the top of the next<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt;&gt;&gt; block&quot; (which is obviously *not* =
incentive-compatible)<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt;&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt;&gt; I was defining &quot;top of mempool&quot; =
as &quot;in the first 4 MSipa&quot;, ie. next<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt;&gt; block, and assumed you&#39;d only allow RB=
F if the old package wasn&#39;t<br>
&gt;=C2=A0 =C2=A0 =C2=A0in the<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt;&gt; top and the replacement would be.=C2=A0 Th=
at seems incentive<br>
&gt;=C2=A0 =C2=A0 =C2=A0compatible; more<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt;&gt; than the current scheme?<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt; My point was, because of block time variance, =
even that criteria<br>
&gt;=C2=A0 =C2=A0 =C2=A0doesn&#39;t hold up. If you assume a steady flow of=
 new transactions and<br>
&gt;=C2=A0 =C2=A0 =C2=A0one or two blocks come in &quot;late&quot;, suddenl=
y &quot;top 4MWeight&quot; isn&#39;t<br>
&gt;=C2=A0 =C2=A0 =C2=A0likely to get confirmed until a few blocks come in =
&quot;early&quot;. Given<br>
&gt;=C2=A0 =C2=A0 =C2=A0block variance within a 12 block window, this is a =
relatively likely<br>
&gt;=C2=A0 =C2=A0 =C2=A0scenario.<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0[ Digging through old mail. ]<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0Doesn&#39;t really matter.=C2=A0 Lightning close al=
gorithm would be:<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A01.=C2=A0 Give bitcoind unileratal close.<br>
&gt;=C2=A0 =C2=A0 =C2=A02.=C2=A0 Ask bitcoind what current expidited fee is=
 (or survey your mempool).<br>
&gt;=C2=A0 =C2=A0 =C2=A03.=C2=A0 Give bitcoind child &quot;push&quot; tx at=
 that total feerate.<br>
&gt;=C2=A0 =C2=A0 =C2=A04.=C2=A0 If next block doesn&#39;t contain unilater=
al close tx, goto 2.<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0In this case, if you allow a simpified RBF where &#=
39;you can replace if<br>
&gt;=C2=A0 =C2=A0 =C2=A01. feerate is higher, 2. new tx is in first 4Msipa =
of mempool, 3.<br>
&gt;=C2=A0 =C2=A0 =C2=A0old tx isnt&#39;,<br>
&gt;=C2=A0 =C2=A0 =C2=A0it works.<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0It allows someone 100k of free tx spam, sure.=C2=A0=
 But it&#39;s simple.<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0We could further restrict it by marking the unilate=
ral close somehow to<br>
&gt;=C2=A0 =C2=A0 =C2=A0say &quot;gonna be pushed&quot; and further limitin=
g the child tx weight (say,<br>
&gt;=C2=A0 =C2=A0 =C2=A05kSipa?) in that case.<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0Cheers,<br>
&gt;=C2=A0 =C2=A0 =C2=A0Rusty.<br>
&gt;=C2=A0 =C2=A0 =C2=A0_______________________________________________<br>
&gt;=C2=A0 =C2=A0 =C2=A0Lightning-dev mailing list<br>
&gt;=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>
&gt;=C2=A0 =C2=A0 =C2=A0&lt;mailto:<a href=3D"mailto:Lightning-dev@lists.li=
nuxfoundation.org" target=3D"_blank">Lightning-dev@lists.linuxfoundation.or=
g</a>&gt;<br>
&gt;=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>
&gt; <br>
</blockquote></div>

--0000000000004d89f10595b6c676--