From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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" , bitcoin-dev From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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