1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
|
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 00C16B2F;
Wed, 30 Oct 2019 07:23:08 +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 287BA8A;
Wed, 30 Oct 2019 07:23:06 +0000 (UTC)
Received: by mail-lj1-f178.google.com with SMTP id m7so1462167lji.2;
Wed, 30 Oct 2019 00:23:05 -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=cbJ0gJacAV3wrKjYZQX+uGPiH+AnIrGK/8EcfIXBgjM=;
b=CMgvQr0zKFP7PpaMK8XEPFbh8x8JUR0FjdRNMlcZSh7y/bT2cWtIGQTzurGo4fBE7P
+duu7ubRNjYcWfEoYnZgrNJ885QvsmSiLJFv1QOJJFn6qd9TVMd5/Yb3GHY0vgUJnM56
HqsYHYiBiAyB/CGAnErFEqkiwdsJ4BGzmn5xpN1LSGbusA3PzKFXwcPRCfMx0zbbmPDq
itEgyRZR+OpaPUhE7gB7HKrHONg87Ri8vT0/DEI3KL6wPKz2p5RYD3BsyTSvb//ilN3C
6suVByOTgWpWF5vZIzoiG1vwVDTijWHbPGloMSKSbn180iUCC6zUqucMyjN40YYQAZlS
JeFg==
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=cbJ0gJacAV3wrKjYZQX+uGPiH+AnIrGK/8EcfIXBgjM=;
b=FXfSg7kLDx1wZWa/FtBpq4o2LfgmatwDPvcGad8ofvXv2oYZlll9jrXr4bilvg9QyJ
4v3sTZP9BOdMUPCOltvJkQvIk/y5/WyyZUtTjk/wfU53XrO/KBKgkFg7o5VqhNFOhDhD
Ea+TyD5DKmmZlIsa+/Bb28ujIcWWhyOPa+GJtX7krfat+iKm/qoqeTXzPIkWTtBYLCq8
DGpRoFFRl3vIvEYxW3BXZ8QauYbIfpt+cRhor9QpuVaNkeMSLLRW5DkJAN02fKOhUCK4
qrCpIvzng5aZm2y77EMSPoiyWA60StlT6zFE4ztS64idMSgNQqhhLI4GNTCOwaEqvPbx
Yo0Q==
X-Gm-Message-State: APjAAAXHA+Oo/QBSzHk4cI3KNrrfYmAjNWNqIdtabiWVK7FRdKHf5kw5
c58xncxEk+VtUjlF+8Ty84laW2jyQaq2qMcGAP0=
X-Google-Smtp-Source: APXvYqxmDBSCuOmbr7RKPPHNKtNmX97FmXGh9/3j0FBjDTUY4R5/CiANxePdieMhRWLIBP87j72JvlHjxSG/LSGTV/c=
X-Received: by 2002:a2e:3612:: with SMTP id d18mr5702976lja.222.1572420184308;
Wed, 30 Oct 2019 00:23:04 -0700 (PDT)
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"
X-Spam-Status: No, score=0.7 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=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Sat, 02 Nov 2019 15:20:10 +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: Wed, 30 Oct 2019 07:23:09 -0000
--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 <<a href=3D"mailto:dave@dtrt.org" target=3D=
"_blank">dave@dtrt.org</a>> 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'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 "LN commitment-like=
" 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't that bad. See Joost's post i=
n "[PATCH] First draft of option_simplfied_commitment"</div><div>=
<br></div><div>- Johan</div></div></div></div>
--0000000000008602be05961b9a29--
|
