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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 70867C0011;
Thu, 24 Feb 2022 12:49:12 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 4B6A561035;
Thu, 24 Feb 2022 12:49:12 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.599
X-Spam-Level:
X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_MSPIKE_H5=0.001,
RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=protonmail.com
Received: from smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id SXrvXqUwU9ag; Thu, 24 Feb 2022 12:49:11 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-4325.protonmail.ch (mail-4325.protonmail.ch [185.70.43.25])
by smtp3.osuosl.org (Postfix) with ESMTPS id AA4E760FF1;
Thu, 24 Feb 2022 12:49:10 +0000 (UTC)
Date: Thu, 24 Feb 2022 12:49:00 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1645706947;
bh=ZJAjMqrlk8KAuen5qhS0khA1AN06cll1Ej8NS+qk+IU=;
h=Date:To:From:Reply-To:Subject:Message-ID:From:To:Cc:Date:Subject:
Reply-To:Feedback-ID:Message-ID;
b=h8uQpR1GoRuWr/sODaFkOzmqPs3JtaxCBHroxgZ8iXG4D9ExY9Q1S46NKoBgc82cr
lVdk5q1IkLNbx7inhZUp8eFNyumuvaKEtEUQKrakcWEMnpeVfQpodC7lptUgODNnsM
8E3zC4868PWeX/n4BtZGu6kUBlm0ddRcks8wqOZ4e2Vwe4EKwP10iOfeDK7vYkDzl+
alYNLIQAtcg21pyr9cEYGP0CUMC7i8xIGO9Uxwnb12EXu607n77dinZezpjAlK5wOX
EcDOD0PrdlUELmvVuv927vIaMITdzg5ozk0hd5P4BA18YLBmeoo5aUGh4dBf5n5jHM
r7TN7xSniEIRw==
To: "lightning-dev\\@lists.linuxfoundation.org"
<lightning-dev@lists.linuxfoundation.org>,
bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <qfzN-NoT0oDddySCNEPQLaJaEqS56rBGxhD9HKvK6Z6qmdfRBUeeE3GGGpzlZSvwmEZbsL-FEitNm6J_LXKaKfIqlqPPCJ9I_CU2SsY1J8c=@protonmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: [bitcoin-dev] A Comparison Of LN and Drivechain Security In The
Presence Of 51% Attackers
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: Thu, 24 Feb 2022 12:49:12 -0000
Good morning lightning-dev and bitcoin-dev,
Recently, some dumb idiot, desperate to prove that recursive covenants are =
somehow a Bad Thing (TM), [necromanced Drivechains][0], which actually caus=
ed Paul Sztorc to [revive][1] and make the following statement:
> As is well known, it is easy for 51% hashrate to double-spend in the LN, =
by censoring 'justice transactions'. Moreover, miners seem likely to evade =
retribution if they do this, as they can restrain the scale, timing, victim=
s, circumstances etc of the attack.
Let me state that, as a supposed expert developer of the Lightning Network =
(despite the fact that I probably spend more time ranting on the lists than=
actually doing something useful like improve C-Lightning or CLBOSS), the a=
bove statement is unequivocally ***true***.
However, I believe that the following important points must be raised:
* A 51% miner can only attack LN channels it is a participant in.
* A 51% miner can simultaneously attack all Drivechain-based sidechains and=
steal all of their funds.
In order for "justice transactions" to come into play, an attacker has to h=
ave an old state of a channel.
And only the channel participants have access to old state (modulo bugs and=
operator error on not being careful of toxic waste, but those are arguably=
as out of scope as operator error not keeping your privkey safe, or bugs t=
hat reveal your privkey).
If the 51% miner is not a participant on a channel, then it simply has no a=
ccess to old state of the channel and cannot even *start* the above theft a=
ttack.
If the first step fails, then the fact that the 51% miner can perform the s=
econd step is immaterial.
Now, this is not a perfect protection!
We should note that miners are anonymous and it is possible that there is a=
lready a 51% miner, and that that 51% miner secretly owns almost all nodes =
on the LN.
However, even this also means there is some probability that, if you picked=
a node at random to make a channel with, then there is some probability th=
at it is *not* a 51% miner and you are *still* safe from the 51% miner.
Thus, LN usage is safer than Drivechain usage.
On LN, if you make a channel to some LN node, there is a probability that y=
ou make a channel with a non-51%-miner, and if you luck into that, your fun=
ds are still safe from the above theft attack, because the 51% miner cannot=
*start* the attack by getting old state and publishing it onchain.
On Drivechain, if you put your funds in *any* sidechain, a 51% miner has st=
rong incentive to attack all sidechains and steal all the funds simultaneou=
sly.
--
Now, suppose we have:
* a 51% miner
* Alice
* Bob
And that 51% miner !=3D Alice, Alice !=3D Bob, and Bob !=3D 51% miner.
We could ask: Suppose Alice wants to attack Bob, could Alice somehow convin=
ce 51% miner to help it steal from Bob?
First, we should observe that *all* economically-rational actors have a *ti=
me preference*.
That is, N sats now is better than N sats tomorrow.
In particular, both the 51% miner *and* Alice the attacker have this time p=
reference, as does victim Bob.
We can observe that in order for Alice to benefit from the theft, it has to=
*wait out* the `OP_CSV` before it can finalize the theft.
Alice can offer fees to the miner only after the `OP_CSV` delay.
However, Bob can offer fees *right now* on the justice transaction.
And the 51% miner, being economically rational, would prefer the *right now=
* funds to the *maybe later* promise by Alice.
Indeed, if Bob offered a justice transaction paying the channel amount minu=
s 1 satoshi (i.e. Bob keeps 1 satoshi), then Alice has to beat that by offe=
ring the entire channel amount to the 51% miner.
But the 51% miner would then have to wait out the `OP_CSV` delay before it =
gets the funds.
Its time preference may be large enough (if the `OP_CSV` delay is big enoug=
h) that it would rather side with Bob, who can pay channel amount - 1 right=
now, than Alice who promises to pay channel amount later.
"But Zeeman, Alice could offer to pay now from some onchain funds Alice has=
, and Alice can recoup the losses later!"
But remember, Alice *also* has a time preference!
Let us consider the case where Alice promises to bribe 51% miner *now*, on =
the promise that 51% miner will block the Bob justice transaction and *then=
* Alice gets to enjoy the entire channel amount later.
Bob can counter by offering channel amount - 1 right now on the justice tra=
nsaction.
The only way for Alice to beat that is to offer channel amount right now, i=
n which case 51% miner will now side with Alice.
But what happens to Alice in that case?
It loses out on channel amount right now, and then has to wait `OP_CSV` del=
ay, to get the exact same amount later!
It gets no benefit, so this is not even an investment.
It is just enforced HODLing, but Alice can do that using `OP_CLTV` already.
Worse, Alice has to trust that 51% miner will indeed block the justice tran=
saction.
But if 51% miner is unscrupulous, it could do:
* Get the bribe from Alice right now.
* After the bribe from Alice confirms, confirm the justice transaction (whi=
ch has a bribe from Bob).
* Thus:
* Alice loses the channel amount.
* Bob keeps 1 satoshi.
* 51% miner gets channel amount + channel amount - 1.
Now of course, we can eliminate the need for trust by using some kind of sm=
art contract.
Unfortunately for Alice, there is no contract that Alice and 51% miner can =
engage in, to ensure that 51% miner will block the justice transaction, whi=
ch itself does *not* require that 51% miner wait out the `OP_CSV` delay.
Either the payment from Alice to 51% miner is delayed (and the 51% miner su=
ffers the time preference discount) or the 51% miner has to offer a bond th=
at only gets released after the Alice theft succeeds (and again the 51% min=
er suffers the time preference discount on that bond).
Thus, due to the `OP_CSV` delay, the honest participant always has the uppe=
r hand, even in a 51% miner scenario.
If your channel is *not* with the 51% miner, your funds are still safe.
--
Now, we might consider, what if the 51% miner always blocks *all* Lightning=
-related transactions?
In that case, it loses out on any bribes that any LN participants would off=
er.
Further, with Taproot, a mutual LN channel close is indistinguishable from =
a singlesig spend.
Thus, not all LN-related transactions can be censored by the 51% miner.
Extensive use of Taproot Tapleaves can also make it difficult for a 51% min=
er to differentiate between LN and other protocols (though that *does* mean=
we should probably e.g. coordiante with other protocols like CoinSwap, Coi=
nPool etc. so that the "shape" of Taproot Tapleaves is consistent across pr=
otocols).
--
A final note: in the presence of channel factories, the *entire* factory is=
at risk if at least one participant is the 51% miner or a sockpuppet there=
of.
Thus, channel factories trade off even further scaling, at the cost of redu=
ced protection against 51% miners.
Regards,
ZmnSCPxj
[0]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/=
019976.html
[1]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/=
019978.html
|