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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 3779FC004C
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 4 Aug 2020 15:00:04 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by fraxinus.osuosl.org (Postfix) with ESMTP id 25C2B86356
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 4 Aug 2020 15:00:04 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id jLUkZ3QIl71W
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 4 Aug 2020 15:00:02 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch
[185.70.40.130])
by fraxinus.osuosl.org (Postfix) with ESMTPS id D493084F24
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 4 Aug 2020 15:00:01 +0000 (UTC)
Date: Tue, 04 Aug 2020 14:59:52 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail; t=1596553199;
bh=onJpplAw7odxI8LAvRzfXAapQ/sDnv6MytHCyezgAeo=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
b=udeAEP09gPVE7ppCyVIFmS1jX1vIeL2ssHU5/2u1TtGHB5x//hK/GVOBJyEgckGcq
WZ4jzFxSzRK1dZuOVo05MSfuPFj3gUKZduyj7TYaKlRDH8qgCwa4ThRYBjtFDRscsD
39pF+8vQBmHbVL883RMRWjodTGHjpg4Yntdp7x3Y=
To: Matt Corallo <lf-lists@mattcorallo.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <KSfad5I1vkw0QoInOkoVtxk9Sw6ypolsQu6TwMd_Y9CzaQsLTElk14434R3Rc2gwC88oAfiH3cITp4do0gtSKknUUBfrmbRKGeYW0ldeevU=@protonmail.com>
In-Reply-To: <735E5B6A-785E-408B-8658-FA36200923C7@mattcorallo.com>
References: <i9rsIn-lslFVgi9AZzyuLvD8sPJqibqSF0loi80tg0cQcGKW9Ccfvo-KSIQjhI7NvWCz8Bm5vTdiC1-TbWAf7s4QCabh6Kca4I6iBftpLQ0=@protonmail.com>
<735E5B6A-785E-408B-8658-FA36200923C7@mattcorallo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP 118 and SIGHASH_ANYPREVOUT
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: Tue, 04 Aug 2020 15:00:04 -0000
Good morning Matt,
> Hmm, apologies that little context was provided - this was meant in the c=
ontext of the current crop of relay-based attacks that have been discovered=
. As we learned in those contexts, =E2=80=9Cjust handle it when it confirms=
=E2=80=9D doesn=E2=80=99t provide the types of guarantees we were hoping fo=
r as placing commitment transactions in mempools can be used to prevent hon=
est nodes from broadcasting the latest state. This implies that HTLC securi=
ty may be at risk.
>
Ah, okay.
So the attack is this:
* Attacker connects twice to the LN: one to any node near the victim, one t=
o the victim.
* Attacker arranges for the attacker-victim channel to have most funds in t=
he side of the victim.
* The attacker routes a circular payment terminating in the victim-attacker=
channel.
* The victim accepts some incoming HTLC, and provides an outgoing HTLC to=
the attacker via the victim-attacker channel.
* The attacker broadcasts a very low-fee old-state transaction of the victi=
m-attacker channel, one that is too low-fee to practically get confirmed, j=
ust before the HTLC timeout.
* The victim-outgoing HTLC times out, making the victim broadcast a unilate=
ral close attempt for the victim-attacker channel in order to enforce the H=
TLC onchain.
* Unfortunately for the victim, relay shenanigans prevent the latest comm=
itment from being broadcast.
* The attacker waits for the victim-incoming HTLC to timeout, which forces =
the victim to `update_htlc_failed` the incoming HTLC or risk having that ch=
annel closed (and losing future routing fees).
* The attacker now gets back its outgoing funds.
* The attacker lets the old-state transaction get relayed, and then re-seat=
s the latest update transaction to that.
* Once the latest transaction allows the HTLCs to be published, the attacke=
r claims the victim-outgoing HTLC with the hashlock branch.
* The attacker now gets its incoming funds, doubling its money, because t=
hat is how the "send me 1 BTC I send you 2 BTC back" Twitter thing works ri=
ght?
Hmmm.
The only thing I can imagine helping here is for the forwarding node to dro=
p channels onchain "early", i.e. if the HTLC will time out in say 14 blocks=
we drop the channel onchain, so we have a little leeway in bumping up fees=
for the commitment transaction.
Maybe.
I am sure Matt can find yet another relay attack that prevents that, at thi=
s point, haha.
"Are we *still* talking about onchain fees....?" - Adelaide 2018
Regards,
ZmnSCPxj
> > On Aug 4, 2020, at 00:23, ZmnSCPxj ZmnSCPxj@protonmail.com wrote:
> > Good morning Matt,
> >
> > > While I admit I haven=E2=80=99t analyzed the feasibility, I want to t=
hrow one additional design consideration into the ring.
> > > Namely, it would ideally be trivial, at the p2p protocol layer, to re=
lay a transaction to a full node without knowing exactly which input transa=
ction that full node has in its mempool/active chain. This is at least pote=
ntially important for systems like lighting where you do not know which cou=
nterparty commitment transaction(s) are in a random node=E2=80=99s mempool =
and you should be able to describe to that node that you are spending then =
nonetheless.
> > > This is (obviously) an incredibly nontrivial problem both in p2p prot=
ocol complexity and mempool optimization, but it may leave SIGHASH_NOINPUT =
rather useless for lighting without it.
> > > The least we could do is think about the consensus design in that con=
text, even if we have to provide an external overlay relay network in order=
to make lighting transactions relay properly (presumably with miners runni=
ng such software).
> >
> > Ah, right.
> > A feasible attack, without the above, would be to connect to the fullno=
de of the victim, and connect to miners separately.
> > Then you broadcast to the victim one of the old txes, call it tx A, but=
you broadcast to the miners a different old tx, call it B.
> > The victim reacts only to tA, but does not react to B since it does not=
see B in the mempool.
> > On the other hand --- what the victim needs to react to is onchain conf=
irmed transactions.
> > So I think all the victim needs to do, in a Lightning universe utilizin=
g primarily `SIGHASH_NOINPUT`-based mechanisms, is to monitor onchain event=
s and ignore mempool events.
> > So if we give fairly long timeouts for our mechanisms, it should be eno=
ugh, I think, since once a transaction is confirmed its txid does not malle=
ate without a reorg and a `SIGHASH_NOINPUT` signature can then be "locked" =
to that txid, unless a reorg unconfirms the transaction.
> > We only need to be aware of deep reorgs and re-broadcast with a malleat=
ed prevout until the tx being spent is deeply confirmed.
> > In addition, we want to implement scorch-the-earth, keep-bumping-the-fe=
e strategies anyway, so we would keep rebroadcasting new versions of the sp=
ending transaction, and spending from a transaction that is confirmed.
> > Or are there other attack vectors you can see that I do not?
> > I think this is fixed by looking at the blockchain.
> > Regards,
> > ZmnSCPxj
|
