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
|
Return-Path: <lf-lists@mattcorallo.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 0C4E7892
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 30 Nov 2018 19:34:00 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.bluematt.me (mail.bluematt.me [192.241.179.72])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 68EF6756
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 30 Nov 2018 19:33:59 +0000 (UTC)
Received: from [10.233.42.100] (gw.vpn.bluematt.me [144.217.106.88])
by mail.bluematt.me (Postfix) with ESMTPSA id 1DC2D120243;
Fri, 30 Nov 2018 19:33:57 +0000 (UTC)
To: Russell O'Connor <roconnor@blockstream.io>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <c3f68b73-84c6-7428-4bf6-b47802141392@mattcorallo.com>
<CAMZUoKnF65_4V6Lngg2eO2R+maqahEOzpgt=Z3EN5xTmMY=LKA@mail.gmail.com>
From: Matt Corallo <lf-lists@mattcorallo.com>
Message-ID: <f0234c95-031b-3bc2-e055-37585ed247ec@mattcorallo.com>
Date: Fri, 30 Nov 2018 19:33:56 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
Thunderbird/60.3.0
MIME-Version: 1.0
In-Reply-To: <CAMZUoKnF65_4V6Lngg2eO2R+maqahEOzpgt=Z3EN5xTmMY=LKA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 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 19:34:00 -0000
Hmm, you may be correct that this doesn't (striclty speaking) imply a
change to the BIP 125 itself, though the high-level protocol here is
likely of interest to the list, as well as likely to generate feedback.
Note that in your example, output Z must be CSV-delayed (ie you cannot
construct a packeg using that output as it must be spent in a different
block than TX0 is confirmed in) in order for the proposal to be secure
as otherwise Alice could use output A to pin the transaction, and then
"use up" the proposed "last-transaction" rule by spending output Z,
leaving Bob unable to spend output B without meeting the (expensive) RBF
criteria.
It was further pointed out to me that while the original mail states
that this relies on package relay, this isn't really entirely true. The
status quo today may leave a commitment transaction unable to be
broadcast if feerates spike much higher than the feerate negotiated at
the time of construction. Under this proposal this is not changed, it is
only the implementation proposal which implies the commitment
transaction feerate negotiation will simply be replaced with a
1sat/vbyte constant which relies on some form of package relay.
Matt
On 11/30/18 5:38 PM, Russell O'Connor wrote:
> On Fri, Nov 30, 2018 at 9:50 AM Matt Corallo via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org
> <mailto: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.
>
|
