path: root/20/22db9b1946e27b1a465eb4cf142b0316a55cc5

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