summaryrefslogtreecommitdiff
path: root/a9/46c045fe5d13984c859cdff3aeda39f6e2659b
blob: 6a700ad9e1ab82f6897aaca884e71068b832eb3b (plain)
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
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id A4A3749D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon,  3 Dec 2018 04:16:27 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40136.protonmail.ch (mail-40136.protonmail.ch
	[185.70.40.136])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7344614D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon,  3 Dec 2018 04:16:26 +0000 (UTC)
Date: Mon, 03 Dec 2018 04:16:10 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
	s=default; t=1543810577;
	bh=/+ryZ0Zz9hcZL+ZuzSc8z0CoQf3Tx6vfpCuWzb2KmG0=;
	h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
	Feedback-ID:From;
	b=XQzCh/hgZ2KcC8l21bcUaRpNnISi7eu6L+KXDlf16sBSqPJYebgCFZPayfR7vBXzI
	2bRcRCJvIRD6Kjj8Npkp3Ot66AjUXp5wyzRSa9QQRR3Uuku1ewTLfG3YqQEWRpPIA6
	7ujesqi2iBSNeTE4EVHb1RYM58J7C8bb4iPCQucc=
To: Bob McElrath <bob@mcelrath.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <8-tJwX51A0xFHoEsKchKREO5i8YxqM48JWspLRiAV3TBHWrRUkUmcZqbAJH6Z6KBQAppPHwuClmzzoaLxtOQqWoHyQG8nzVJAuzAFFGl-s8=@protonmail.com>
In-Reply-To: <20181202150839.GE22873@mcelrath.org>
References: <c3f68b73-84c6-7428-4bf6-b47802141392@mattcorallo.com>
	<20181202150839.GE22873@mcelrath.org>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL,
	RCVD_IN_DNSWL_LOW 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: Mon, 03 Dec 2018 04:23:01 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-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: Mon, 03 Dec 2018 04:16:27 -0000

Good morning Bob,

Would `SIGHASH_SINGLE` work?
Commitment transactions have a single input but multiple outputs.

Regards,
ZmnSCPxj


Sent with ProtonMail Secure Email.

=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me=
ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
On Sunday, December 2, 2018 11:08 PM, Bob McElrath <bob@mcelrath.org> wrote=
:

> I've long thought about using SIGHASH_SINGLE, then either party can add i=
nputs
> to cover whatever fee they want on channel close and it doesn't have to b=
e
> pre-planned at setup.
>
> For Lightning I think you'd want to cross-sign, e.g. Alice signs her inpu=
t
> and Bob's output, while Bob signs his input and Alice's output. This woul=
d
> demotivate the two parties from picking apart the transaction and broadca=
sting
> one of the two SIGHASH_SINGLE's in a Lightning transaction.
>
> Matt Corallo via bitcoin-dev [bitcoin-dev@lists.linuxfoundation.org] wrot=
e:
>
> > (cross-posted to both lists to make lightning-dev folks aware, please t=
ake
> > lightning-dev off CC when responding).
> > As I'm sure everyone is aware, Lightning (and other similar systems) wo=
rk by
> > exchanging pre-signed transactions for future broadcast. Of course in m=
any
> > cases this requires either (a) predicting what the feerate required for
> > timely confirmation will be at some (or, really, any) point in the futu=
re,
> > or (b) utilizing CPFP and dependent transaction relay to allow parties =
to
> > broadcast low-feerate transactions with children created at broadcast-t=
ime
> > to increase the effective feerate. Ideally transactions could be constr=
ucted
> > 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 complexi=
ty
> > has led to channel failures in lightning in practice (as both sides mus=
t
> > agree on a reasonable-in-the-future feerate). Option (b) is a much more
> > natural choice (assuming some form of as-yet-unimplemented package rela=
y on
> > the P2P network) but is made difficult due to complexity around RBF/CPF=
P
> > 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 avail=
able
> > 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-spen=
d
> > output. This transaction, B, will have a large absolute fee while makin=
g 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 m=
emory
> > 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 s=
ize
> > 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 lea=
st
> > until/unless the prevailing feerates decline and some of the mempool ba=
cklog
> > 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') securi=
ty
> >     model assumes the ability to get such commitment transactions confi=
rmed in a
> >     timely manner, as otherwise HTLCs may time out and counterparties c=
an claim
> >     the timeout-refund before we can claim the HTLC using the hash-prei=
mage.
> >
> >
> > To partially-address the CPFP security model considerations, a next ste=
p
> > might involve tweaking Lightning's commitment transaction to have two
> > small-value outputs which are immediately spendable, one by each channe=
l
> > participant, allowing them to chain children off without allowng unrela=
ted
> > 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 transacti=
ons
> > 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 mempo=
ol
> >     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 crite=
ria).
> >
> >
> > 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 tra=
nsaction
> >     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 alway=
s
> >     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 discussio=
ns
> > around solving the "RBF-pinning" problem by allowing transactors to mar=
k
> > 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 consisten=
tly,
> > as any "transaction-delaying" channel participant will have to place th=
e
> > package containing A at an effective feerate which makes confirmation t=
o
> > occur soon with some likelihood. It is, however, possible to pull off t=
his
> > attack with low probability in case of feerate spikes right after broad=
cast.
> > Note that this clearly relies on some form of package relay, which come=
s
> > with its own challenges, but I'll start a separate thread on that.
> > See-also: lightning-dev thread about the changes to lightning spec requ=
ired
> > to incorporate this: https://lists.linuxfoundation.org/pipermail/lightn=
ing-dev/2018-November/001643.html
> > Matt
> >
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > !DSPAM:5c014daf168271726154759!
>
> --
> Cheers, Bob McElrath
>
> "For every complex problem, there is a solution that is simple, neat, and=
 wrong."
> -- H. L. Mencken
>
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev