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
|
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 963FBB88;
Thu, 29 Nov 2018 19:37:57 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
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 D0AF0840;
Thu, 29 Nov 2018 19:37:56 +0000 (UTC)
Received: from [10.233.42.100] (gw.vpn.bluematt.me [144.217.106.88])
by mail.bluematt.me (Postfix) with ESMTPSA id 7CDA5120243;
Thu, 29 Nov 2018 19:37:55 +0000 (UTC)
To: bitcoin-dev@lists.linuxfoundation.org
From: Matt Corallo <lf-lists@mattcorallo.com>
Message-ID: <c3f68b73-84c6-7428-4bf6-b47802141392@mattcorallo.com>
Date: Thu, 29 Nov 2018 19:37:54 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
Thunderbird/60.3.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
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 14:47:14 +0000
Cc: lightning-dev@lists.linuxfoundation.org
Subject: [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: Thu, 29 Nov 2018 19:37:57 -0000
(cross-posted to both lists to make lightning-dev folks aware, please
take lightning-dev off CC when responding).
As I'm sure everyone is aware, Lightning (and other similar systems)
work by exchanging pre-signed transactions for future broadcast. Of
course in many cases this requires either (a) predicting what the
feerate required for timely confirmation will be at some (or, really,
any) point in the future, or (b) utilizing CPFP and dependent
transaction relay to allow parties to broadcast low-feerate transactions
with children created at broadcast-time to increase the effective
feerate. Ideally transactions could be constructed to allow for
after-the-fact addition of inputs to increase fee without CPFP but it is
not always possible to do so.
Option (a) is rather obviously intractible, and implementation
complexity has led to channel failures in lightning in practice (as both
sides must agree on a reasonable-in-the-future feerate). Option (b) is a
much more natural choice (assuming some form of as-yet-unimplemented
package relay on the P2P network) but is made difficult due to
complexity around RBF/CPFP anti-DoS rules.
For example, if we take a simplified lightning design with pre-signed
commitment transaction A with one 0-value anyone-can-spend output
available for use as a CPFP output, a counterparty can prevent
confirmation of/significantly increase the fee cost of confirming A by
chaining a large-but-only-moderate-feerate transaction off of this
anyone-can-spend output. This transaction, B, will have a large absolute
fee while making the package (A, B) have a low-ish feerate, placing it
solidly at the bottom of the mempool but without significant risk of it
getting evicted during memory limiting. This large absolute fee forces a
counterparty which wishes to have the commitment transaction confirm to
increase on this absolute fee in order to meet RBF rules.
For this reason (and many other similar attacks utilizing the package
size limits), in discussing the security model around CPFP, we've
generally considered it too-difficulty-to-prevent third parties which
are able to spend an output of a transaction from delaying its
confirmation, at least until/unless the prevailing feerates decline and
some of the mempool backlog gets confirmed.
You'll note, however, that this attack doesn't have to be permanent to
work - Lightning's (and other contracting/payment channel systems')
security model assumes the ability to get such commitment transactions
confirmed in a timely manner, as otherwise HTLCs may time out and
counterparties can claim the timeout-refund before we can claim the HTLC
using the hash-preimage.
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:
The last transaction which is added to a package of dependent
transactions in the mempool must:
* Have no more than one unconfirmed parent,
* Be of size no greater than 1K in virtual size.
(for implementation sanity, this would effectively reduce all mempool
package size limits by 1 1K-virtual-size transaction, and the last would
be "allowed to violate the limits" as long as it meets the above criteria).
For contracting applications like lightning, this means that as long as
the transaction we wish to confirm (in this case the commitment transaction)
* Has only two immediately-spendable (ie non-CSV) outputs,
* where each immediately-spendable output is only spendable by one
counterparty,
* and is no larger than MAX_PACKAGE_VIRTUAL_SIZE - 1001 Vsize,
each counterparty will always be able to independantly CPFP the
transaction in question. ie because if the "malicious" (ie
transaction-delaying) party bradcasts A with a child, it can never meet
the "last transaction" carve-out as its transaction cannot both meet the
package limit and have only one unconfirmed ancestor. Thus, the
non-delaying counterparty can always independently add its own CPFP
transaction, increasing the (A, Tx2) package feerate and confirming A
without having to concern themselves with the (A, Tx1) package.
As an alternative proposal, at various points there have been
discussions around solving the "RBF-pinning" problem by allowing
transactors to mark their transactions as "likely-to-be-RBF'ed", which
could enable a relay policy where children of such transactions would be
rejected unless the resulting package would be "near the top of the
mempool". This would theoretically imply such attacks are not possible
to pull off consistently, as any "transaction-delaying" channel
participant will have to place the package containing A at an effective
feerate which makes confirmation to occur soon with some likelihood. It
is, however, possible to pull off this attack with low probability in
case of feerate spikes right after broadcast.
Note that this clearly relies on some form of package relay, which comes
with its own challenges, but I'll start a separate thread on that.
See-also: lightning-dev thread about the changes to lightning spec
required to incorporate this:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001643.html
Matt
|
