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
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
|
Return-Path: <roconnor@blockstream.io>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 43398B1E
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 30 Nov 2018 17:38:18 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-it1-f177.google.com (mail-it1-f177.google.com
[209.85.166.177])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B259D83A
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 30 Nov 2018 17:38:17 +0000 (UTC)
Received: by mail-it1-f177.google.com with SMTP id p197so10473925itp.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 30 Nov 2018 09:38:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=blockstream.io; s=google;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
bh=QiePyLjmRr72SgKHtJK/0u8ggLh5XfdGx6yJaPSBl+o=;
b=hMTjXfBMDn5c3in0d8NMnuoJSvYWOL9oQ4ap/W4tZrffrXI6xZC80CYUqiLuuQI7h/
pd01DJzch4xxj8rSzh1JuAA0TUilYarXYDw6j0ncZ6U37hxnJXQu6DAa/0u08x+BWgYW
HhSA5dCjcPepslAoqvVSEsfo8V35pIT7FkYoA=
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;
bh=QiePyLjmRr72SgKHtJK/0u8ggLh5XfdGx6yJaPSBl+o=;
b=GUqe4yzVgnh6YJMsZB016xVVOG/+KINr3YxVCjfgRh/qkxDWCRKMIifCCHeL6V3tEW
Z4yJjKTt+8zouAk8gPUckUy3QrURussPS8Qt/g4uFJ2zG8Os9Z+bAjxKB7gOML4EGGIb
PvHJm9Tz1iIbb2rWppLTKrz6IYj/4QtaMN/xRjTCBZeP//MX0UC3rhgwQ0GflLzjVW0T
SjEnv/oZxAnBb+aOTPIKIaiPhCdjMlwkv5BN7eCMDSMmO6JVn4OkTyMJ8rDr1o1o1j0k
Gb15/aGjcSa3TEZGOU1soyzABVMYhwoIgMV3gZEi+5irMHvk/PaPf5p5xnF2EOgdxMfT
Co/w==
X-Gm-Message-State: AA+aEWazcfqRsRN8H9LWYb4zgQ96ZFIH6XgKeAlwavFwCUA9vFMt4BVV
dZK86D/xhoWfnfZOdj2OMCQzkPIDTjAZwcHm7DZ6aEY06qo=
X-Google-Smtp-Source: AFSGD/W8seSae14Am9kaxkIND2yOUR6CtpAURB0AKHmzNwDT9TYV5Wb0Ns/M6osV9yWEaMroOij/idE6zas0mpqNXnw=
X-Received: by 2002:a24:1490:: with SMTP id 138mr7034622itg.101.1543599496929;
Fri, 30 Nov 2018 09:38:16 -0800 (PST)
MIME-Version: 1.0
References: <c3f68b73-84c6-7428-4bf6-b47802141392@mattcorallo.com>
In-Reply-To: <c3f68b73-84c6-7428-4bf6-b47802141392@mattcorallo.com>
From: "Russell O'Connor" <roconnor@blockstream.io>
Date: Fri, 30 Nov 2018 12:38:04 -0500
Message-ID: <CAMZUoKnF65_4V6Lngg2eO2R+maqahEOzpgt=Z3EN5xTmMY=LKA@mail.gmail.com>
To: Matt Corallo <lf-lists@mattcorallo.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000b0c182057be54372"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, 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: Fri, 30 Nov 2018 22:37:38 +0000
Subject: Re: [bitcoin-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, 30 Nov 2018 17:38:18 -0000
--000000000000b0c182057be54372
Content-Type: text/plain; charset="UTF-8"
On Fri, Nov 30, 2018 at 9:50 AM Matt Corallo via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> To partially-address the CPFP security model considerations, a next step
> might involve tweaking Lightning's commitment transaction to have two
> small-value outputs which are immediately spendable, one by each channel
> participant, allowing them to chain children off without allowng
> unrelated third-parties to chain children. Obviously this does not
> address the specific attack so we need a small tweak to the anti-DoS
> CPFP rules in Bitcoin Core/BIP 125:
>
It seems to me that this two-output scheme does address the specific attack
without tweaking the RBF rules of BIP 125, since you are not doing an RBF
at all.
Suppose we have a 1k-vbyte unconfirmed transaction, TX0, with outputs Z, A,
and B, where A and B are small outputs controlled by the participants Alice
and Bob respectively, with a 1ksat fee, yielding a fee rate of 1sat/vbyte.
Someone, maybe Alice, attempts to pin the transaction, maliciously or not,
by attaching a 10k-vbyte transaction, TX1, to either output Z or output A,
with a fee of 21ksats. This brings the fee rate for the TX0-TX1 package to
2sat/vbyte, being 11k-vbyte total size with 22ksats in total fees.
Now Bob wants to CPFP to increase the effective fee rate of TX0 to
3sats/vbyte using output B. He attaches a 1k-vbyte transaction, TX2, to
output B with a fee of 5ksats. This ought to create a new TX0-TX2 package
with a 3sat/vbyte fee rate, being 2k-vbyte total size with 6ksats in total
fees. TX1 has now been excluded from the package containing TX0. But TX1
hasn't been replaced, so the RBF rules from BIP125 don't apply. TX1 is
still a valid unconfirmed transaction operating at a fee rate of
2.1sats/vbyte.
That said, I'm not an expert on how packages and package fee rates are
calculated in Bitcoin Core, so I am speculating a bit. And, because I'm
talking with Matt, it's more likely that I'm mistaken. AFAIK, any rules
about CPFP's behaviour in Bitcoin Core is undocumented.
--000000000000b0c182057be54372
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Fri, Nov 30=
, 2018 at 9:50 AM Matt Corallo via bitcoin-dev <<a href=3D"mailto:bitcoi=
n-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&=
gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex">To partially-address the=
CPFP security model considerations, a next step <br>
might involve tweaking Lightning's commitment transaction to have two <=
br>
small-value outputs which are immediately spendable, one by each channel <b=
r>
participant, allowing them to chain children off without allowng <br>
unrelated third-parties to chain children. Obviously this does not <br>
address the specific attack so we need a small tweak to the anti-DoS <br>
CPFP rules in Bitcoin Core/BIP 125:<br></blockquote><div><br></div><div>It =
seems to me that this two-output scheme does address the specific attack wi=
thout tweaking the RBF rules of BIP 125, since you are not doing an RBF at =
all.</div><div><br></div><div>Suppose we have a 1k-vbyte unconfirmed transa=
ction, TX0, with outputs Z, A, and B, where A and B are small outputs contr=
olled by the participants Alice and Bob respectively, with a 1ksat fee, yie=
lding a fee rate of 1sat/vbyte.</div><div>Someone, maybe Alice, attempts to=
pin the transaction, maliciously or not, by attaching a 10k-vbyte transact=
ion, TX1, to either output Z or output A, with a fee of 21ksats.=C2=A0 This=
brings the fee rate for the TX0-TX1 package to 2sat/vbyte, being 11k-vbyte=
total size with 22ksats in total fees.</div><div><br></div><div>Now Bob wa=
nts to CPFP to increase the effective fee rate of TX0 to 3sats/vbyte using =
output B.=C2=A0 He attaches a 1k-vbyte transaction, TX2, to output B with a=
fee of 5ksats.=C2=A0 This ought to create a new TX0-TX2 package with a 3sa=
t/vbyte fee rate, being 2k-vbyte total size with 6ksats in total fees.=C2=
=A0 TX1 has now been excluded from the package containing TX0. But TX1 hasn=
't been replaced, so the RBF rules from BIP125 don't apply.=C2=A0 T=
X1 is still a valid unconfirmed transaction operating at a fee rate of 2.1s=
ats/vbyte.<br></div><div><br></div><div>That said, I'm not an expert on=
how packages and package fee rates are calculated in Bitcoin Core, so I am=
speculating a bit.=C2=A0 And, because I'm talking with Matt, it's =
more likely that I'm mistaken.=C2=A0 AFAIK, any rules about CPFP's =
behaviour in Bitcoin Core is undocumented.<br></div><div><br></div><div>=C2=
=A0</div></div></div>
--000000000000b0c182057be54372--
|
