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
|
Return-Path: <antoine.riard@gmail.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 789D6C0175
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 22 Apr 2020 19:03:45 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id 67F0D811E7
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 22 Apr 2020 19:03:45 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id te-wyyBC3YEQ
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 22 Apr 2020 19:03:43 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-pf1-f177.google.com (mail-pf1-f177.google.com
[209.85.210.177])
by whitealder.osuosl.org (Postfix) with ESMTPS id 5E960846EE
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 22 Apr 2020 19:03:43 +0000 (UTC)
Received: by mail-pf1-f177.google.com with SMTP id f7so1580565pfa.9
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 22 Apr 2020 12:03:43 -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;
bh=6rEBHkJvfXXpHQHDggubciLpv8SajflP4ApVVCO34m4=;
b=bPbi8XFfpsHoKnKCkKk/BwvYCAmOEcqoPr9mtQnPAxDtV4zx2CE+fuNxPKE0MeVnCE
RK4UFDLl6P+ZFaxr9JQD82GyYW0FV8pdKq5cMuPlbS83XIFSJsdYXIiRRJ3zdGztMwdp
HPUXGl05G8vLJEKVL+B23biEiWibFLRWm1fmyNt3LsuO4URQ6r7jz2VAJbks3DOYNFxm
OwDpsDM54Rut1Rxdr+KohqI37wrm2F9JtGpoVEgA2CroJH295Sk42WHMNRENQIAzcicO
BCxnsvxuURCrwC/tEFkmHiJ/MOcmGaJqNfULFp95/Gh+flaJhCKU9PFregNlxjDOyuzE
q7xg==
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=6rEBHkJvfXXpHQHDggubciLpv8SajflP4ApVVCO34m4=;
b=jJQlhjcklczhX4aOmi8/tlaomWnJl4H1zXPdhDCS/Jd4BuWWVLYN7Tg30aQb4LGOhf
Hm6QtHxRsyZnMINelgB2b1I0fz5mOha/VC3A0VrSBoIwzE0/3PYxkBlQCy8wtllpKUYE
t7c27tPJwr9KsdFPMiiAeDH5qMtB+hidl+BQx72QY2lqPJ2J8hNYiB9lHt6KlEw0rm9h
YlLhVKjA3xNax2q0xICAGpGfZ9ttT1FzlSfgnnznOtLyi7BHlY1tG7y4Ioqc5RunKKkG
YKgeXCX43iwXUU28zwOCENEDXQPIKsPce+7LbgqDln6jQ12ZFEU6rR8QGbXcUNn58Ryn
tUzg==
X-Gm-Message-State: AGi0PuaPcMKGTgEiGgdTKeLZFKIkTfOQdfPnba/0F4Z/ONKzOdrFlZmS
VgYxXwwDrNOLJ50u+/PQMTh6vBkY+LjSIkQpCLXDOZdB
X-Google-Smtp-Source: APiQypKYDm83VPYO578gmCIaPvzct8O05EBTVkjuTimX7M/gSI00TwfC4EfXRbUW1A/u6xy4/RNiUfeJPz1DROLG/v4=
X-Received: by 2002:a63:de41:: with SMTP id y1mr508199pgi.176.1587582222823;
Wed, 22 Apr 2020 12:03:42 -0700 (PDT)
MIME-Version: 1.0
References: <a09f5291-e7c0-0aca-6971-03ace0c38dff@mattcorallo.com>
<20200422182454.3y3foxxhiovokovp@ganymede>
In-Reply-To: <20200422182454.3y3foxxhiovokovp@ganymede>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Wed, 22 Apr 2020 15:03:29 -0400
Message-ID: <CALZpt+HHJ6rKJK8FBdJ1gznWDsfkUo26rOy=mNLbvMwicv9muQ@mail.gmail.com>
To: "David A. Harding" <dave@dtrt.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000071757205a3e5caba"
X-Mailman-Approved-At: Wed, 22 Apr 2020 19:53:18 +0000
Subject: Re: [bitcoin-dev] RBF Pinning with Counterparties and Competing
Interest
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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, 22 Apr 2020 19:03:45 -0000
--00000000000071757205a3e5caba
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
> In that case, would it be worth re-implementing something like a BIP61
reject message but with an extension that returns the txids of any
conflicts?
That's an interesting idea, but an attacker can create a local conflict in
your mempool
and then send the preimage tx to make hit recentRejects until next tip so
when the rejection code with conflict is received transaction isn't going
to be fetched.
Of course you can make an exception for this, but seems a DoS vector...
And also if you have a private full-node and connect only to 8 outbounds,
an attacker
can do a bit of tx-relay topology discovery and blind your tx-relay peers
too...
I think p2p/mempool hardening measures will only make attack harder but not
erase it, we
should avoid tie too much the security model of Lightning on a given p2p
topology. If you don't
do manual peering (whitelist,addnode), this one may change without
visibility (like stale tip).
Le mer. 22 avr. 2020 =C3=A0 14:25, David A. Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit :
> On Mon, Apr 20, 2020 at 10:43:14PM -0400, Matt Corallo via Lightning-dev
> wrote:
> > A lightning counterparty (C, who received the HTLC from B, who
> > received it from A) today could, if B broadcasts the commitment
> > transaction, spend an HTLC using the preimage with a low-fee,
> > RBF-disabled transaction. After a few blocks, A could claim the HTLC
> > from B via the timeout mechanism, and then after a few days, C could
> > get the HTLC-claiming transaction mined via some out-of-band agreement
> > with a small miner. This leaves B short the HTLC value.
>
> IIUC, the main problem is honest Bob will broadcast a transaction
> without realizing it conflicts with a pinned transaction that's already
> in most node's mempools. If Bob knew about the pinned transaction and
> could get a copy of it, he'd be fine.
>
> In that case, would it be worth re-implementing something like a BIP61
> reject message but with an extension that returns the txids of any
> conflicts? For example, when Bob connects to a bunch of Bitcoin nodes
> and sends his conflicting transaction, the nodes would reply with
> something like "rejected: code 123: conflicts with txid 0123...cdef".
> Bob could then reply with a a getdata('tx', '0123...cdef') to get the
> pinned transaction, parse out its preimage, and resolve the HTLC.
>
> This approach isn't perfect (if it even makes sense at all---I could be
> misunderstanding the problem) because one of the problems that caused
> BIP61 to be disabled in Bitcoin Core was its unreliability, but I think
> if Bob had at least one honest peer that had the pinned transaction in
> its mempool and which implemented reject-with-conflicting-txid, Bob
> might be ok.
>
> -Dave
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--00000000000071757205a3e5caba
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div>> In that case, would it be worth re-imp=
lementing something like a BIP61<br>
reject message but with an extension that returns the txids of any<br>
conflicts?<br><br></div>That's an interesting idea, but an attacker can=
create a local conflict in your mempool<br></div>and then send the preimag=
e tx to make hit recentRejects until next tip so</div><div>when the rejecti=
on code with conflict is received transaction isn't going to be fetched=
.<br></div><div>Of course you can make an exception for this, but seems a D=
oS vector...<br><br></div><div>And also if you have a private full-node and=
connect only to 8 outbounds, an attacker</div><div>can do a bit of tx-rela=
y topology discovery and blind your tx-relay peers too...<br><br></div><div=
>I think p2p/mempool hardening measures will only make attack harder but no=
t erase it, we<br></div><div>should avoid tie too much the security model o=
f Lightning on a given p2p topology. If you don't</div><div>do manual p=
eering (whitelist,addnode), this one may change without visibility (like st=
ale tip).<br></div><br><div><br></div></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0mer. 22 avr. 2020 =C3=A0=C2=
=A014:25, David A. Harding via bitcoin-dev <<a href=3D"mailto:bitcoin-de=
v@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> =
a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex">On Mon, Apr 20, 2020 at 10:43:14PM -0400, Matt Corallo via Lightning-de=
v wrote:<br>
> A lightning counterparty (C, who received the HTLC from B, who<br>
> received it from A) today could, if B broadcasts the commitment<br>
> transaction, spend an HTLC using the preimage with a low-fee,<br>
> RBF-disabled transaction.=C2=A0 After a few blocks, A could claim the =
HTLC<br>
> from B via the timeout mechanism, and then after a few days, C could<b=
r>
> get the HTLC-claiming transaction mined via some out-of-band agreement=
<br>
> with a small miner. This leaves B short the HTLC value.<br>
<br>
IIUC, the main problem is honest Bob will broadcast a transaction<br>
without realizing it conflicts with a pinned transaction that's already=
<br>
in most node's mempools.=C2=A0 If Bob knew about the pinned transaction=
and<br>
could get a copy of it, he'd be fine.<br>
<br>
In that case, would it be worth re-implementing something like a BIP61<br>
reject message but with an extension that returns the txids of any<br>
conflicts?=C2=A0 For example, when Bob connects to a bunch of Bitcoin nodes=
<br>
and sends his conflicting transaction, the nodes would reply with<br>
something like "rejected: code 123: conflicts with txid 0123...cdef&qu=
ot;.<br>
Bob could then reply with a a getdata('tx', '0123...cdef') =
to get the<br>
pinned transaction, parse out its preimage, and resolve the HTLC.<br>
<br>
This approach isn't perfect (if it even makes sense at all---I could be=
<br>
misunderstanding the problem) because one of the problems that caused<br>
BIP61 to be disabled in Bitcoin Core was its unreliability, but I think<br>
if Bob had at least one honest peer that had the pinned transaction in<br>
its mempool and which implemented reject-with-conflicting-txid, Bob<br>
might be ok.<br>
<br>
-Dave<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
--00000000000071757205a3e5caba--
|