MIME-Version: 1.0
References: <CAD3i26Cf+QpbFXh63NiMig9eceeKaezZwk89A_h_76S_XKkQ9g@mail.gmail.com>
	<6728FF51-E378-4AED-99BA-ECB83688AA9C@mattcorallo.com>
	<CAD5xwhhK4xexDe=aBv78BsK5BvE=4S0OcqeXYHVAfN3wTOr51Q@mail.gmail.com>
	<CAD3i26DTxnDwhQd+kfS609W==A8oFA8DVJfwMiPt6NSXqhqw4w@mail.gmail.com>
	<20191028171416.7owxqblz3ttsvw5r@ganymede>
In-Reply-To: <20191028171416.7owxqblz3ttsvw5r@ganymede>
From: =?UTF-8?Q?Johan_Tor=C3=A5s_Halseth?= <johanth@gmail.com>
Date: Wed, 30 Oct 2019 08:22:53 +0100
Message-ID: <CAD3i26BkuxMyazGsQ1+ij25f3xhXUBpUTcOfgYKnY4fur5rGBw@mail.gmail.com>
To: "David A. Harding" <dave@dtrt.org>
Content-Type: multipart/alternative; boundary="0000000000008602be05961b9a29"
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)
Precedence: list

--0000000000008602be05961b9a29
Content-Type: text/plain; charset="UTF-8"

On Mon, Oct 28, 2019 at 6:16 PM David A. Harding <dave@dtrt.org> wrote:

> A parent transaction near the limit of 100,000 vbytes could have almost
> 10,000 outputs paying OP_TRUE (10 vbytes per output).  If the children
> were limited to 10,000 vbytes each (the current max carve-out size),
> that allows relaying 100 mega-vbytes or nearly 400 MB data size (larger
> than the default maximum mempool size in Bitcoin Core).
>

Thanks, Dave, I wasn't aware the limits would allow this many outputs. And
as your calculation shows, this opens up the potential for free relay of
large amounts of data.

We could start special casing to only allow this for "LN commitment-like"
transactions, but this would be application specific changes, and your
calculation shows that even with the BOLT2 numbers there still exists cases
with a large number of children.

We are moving forward with adding a 1 block delay to all outputs to utilize
the current carve-out rule, and the changes aren't that bad. See Joost's
post in "[PATCH] First draft of option_simplfied_commitment"

- Johan

--0000000000008602be05961b9a29
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Oct 28, 2019=
 at 6:16 PM David A. Harding &lt;<a href=3D"mailto:dave@dtrt.org" target=3D=
"_blank">dave@dtrt.org</a>&gt; wrote:</div><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);=
padding-left:1ex">
A parent transaction near the limit of 100,000 vbytes could have almost<br>
10,000 outputs paying OP_TRUE (10 vbytes per output).=C2=A0 If the children=
<br>
were limited to 10,000 vbytes each (the current max carve-out size),<br>
that allows relaying 100 mega-vbytes or nearly 400 MB data size (larger<br>
than the default maximum mempool size in Bitcoin Core).<br></blockquote><di=
v><br></div><div>Thanks, Dave, I wasn&#39;t aware the limits would allow th=
is many outputs. And as your calculation shows, this opens up the potential=
 for free relay of large amounts of data.=C2=A0</div><div><br></div><div>We=
 could start special casing to only allow this for &quot;LN commitment-like=
&quot; transactions, but this would be application specific changes, and yo=
ur calculation shows that even with the BOLT2 numbers there still exists ca=
ses with a large number of children.</div><div><br></div><div>We are moving=
 forward with adding a 1 block delay to all outputs to utilize the current =
carve-out rule, and the changes aren&#39;t that bad. See Joost&#39;s post i=
n &quot;[PATCH] First draft of option_simplfied_commitment&quot;</div><div>=
<br></div><div>- Johan</div></div></div></div>

--0000000000008602be05961b9a29--