[Lightning-dev] New form of 51% attack via lightning's revocation system possible?

[ZmnSCPxj]

Good morning Rene,

The attack is possible but requires the combination of the below:

1.  A large 51% miner.
2.  Many channels share-owned by the miner.
3.  Large capacities in each channel share-owned by the miner.

Individual nodes can protect against these as below:

1.  Contributing hashpower to a decentralized mining aggregator (e.g. P2Pool).
2.1.  Disallow more than n channels with a single node, with small n (ideally 1 as c-lightning does).
2.2.  Insist on a blocksize limit.
3.  Limit capacities per channel (e.g. 167.77215mBTC max capacity).

Against protection #2.1 the attacker can run many nodes, but each node at least consumes some resource that could have been used for e.g. hashing.

Against protection #3 the attacker can do nothing; if one side refuses to make larger than 167.77215 mBTC, the channel cannot be established.

The blocksize limit is important since the number of channels that can be stolen in a single block is bounded by the blocksize.  In combination with channel capacity limit, this increases the number of blocks needed to secretly mine to complete the attack.

* If we impose a limit of 167.77216mBTC per channel, we need 6 channels to steal 1BTC.
* To steal 1M BTC we need 6 million channels, which cannot fit in a block.
* About 2000 transactions can fit in a block so that is 2000 channels closed per block.
* To close 6 million channels you need to secretly mine 3000 blocks, which is about 20 days.

Note that this only *closes* the channels: you also need to claim the commitment transactions, which is another 3000 blocks (an additional 20 or so days).

Thus the block size limit and the channel capacity limit are vital protections against this attack.

Regards,
ZmnSCPxj

Sent with [ProtonMail](https://protonmail.com) Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On March 13, 2018 9:30 PM, René Pickhardt via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:

> Hey everyone,
>
> disclaimer: as mentioned in my other mail ( https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-March/001065.html ) I am currently studying the revocation system of duplex micropayment channels in detail but I am also pretty new to the topic. So I hope the attack I am about to describe is not possible and it is just me overseeing some detail or rather my lack of understanding.
> That being said even after waiting one week upon discovery and double checking the assumptions I made I am still positive that the revocation system in its current form allows for a new form of a 51% attack. This attack seems to be way more harmful than a successful 51% attack on the bitcoin network. Afaik within the bitcoin network I could 'only double spend' my own funds with a successful 51% attack. In the lightning case it seems that an attacker could steal an arbitrary amount of funds as long as the attacker has enough payment channels with enough balance open.
>
> The attack itself follows exactly the philosophy of lightning: "If a tree falls in the forest and no one is around to hear it. Does it make a sound?"
> In the context of the attack this would translate to: "If a 51% attacker secretly mines enough blocks after fraudulently spending old commitment transactions and no one sees it during the the to_self_delay  period, have the commitment transactions been spent? (How) Can they be revoked?"
>
> As for the technical details I quote from the spec of BOLT 3:
> "To allow an opportunity for penalty transactions, in case of a revoked commitment transaction, all outputs that return funds to the owner of the commitment transaction (a.k.a. the "local node") must be delayed for to_self_delay blocks. This delay is done in a second-stage HTLC transaction (HTLC-success for HTLCs accepted by the local node, HTLC-timeout for HTLCs offered by the local node)"
>
> Assume an attacker has 51% of the hash power she could open several lightning channels and in particular accept any incoming payment channel (the more balance is in her channels the more lucrative the 51% attack). Since the attacker already has a lot of hash power it is reasonable (but not necessary) to assume that the attacker already has a lot of bitcoins and is well known to honest nodes in the network which makes it even more likely to have many open channels.
>
> The attacker keeps track of her (revocable) commitment transactions in which the balance is mostly on the attackers side. Once the attacker knows enough of these (old) commitment transactions the attack is being executed in the following way:
> 0.) The max value of to_self_delay is evaluated. Let us assume it is 72 blocks (or half a day).
> 1.) The attacker secretly starts mining on her own but does not broadcasts any successfully mined block. Since the attacker has 51% of the hash power she will most likely be faster than the network to mine the 72 blocks of the safety period in which fraudulent commitment transactions could be revoked.
> 2.) The attacker spends all the fraudulent (old) commitment transactions in the first block of her secrete mining endeavor.
> 3.) Meanwhile the attacker starts spending her own funds of her payment channels e.g on decentralized exchanges for any other (crypto)currency.
> 4.) As soon as the attacker has mined enough blocks that the commitment transactions cannot be revoked she broadcasts her secretly minded blockchain which will be accepted by the network as it is the longest chain. (In Particular she includes all the other bitcoin transactions that are also in the original public blockchain so that other people don't even realize something suspicious has happened.)
>
> Since according to the spec channels should never be balanced worse than 99% to 1% the attacker could steal up to 99% of all the bitcoins allocated in the sum of all payment channels the attacker was connected to. This amount could obviously be way higher than just double spending her own funds. This attack would be interesting in particular for the power nodes created by the Barabasi-Albert model of lnd's autopilot (c.f.: https://github.com/lightningnetwork/lnd/issues/677 ).
>
> I understand that with the growth of the bitcoin (mining) network a 51% attack becomes less and less likely. Also I am very happy to be proven false about the attack that I am describing.
>
> Another sad thing about this attack is that I currently do not see any (reasonable) way of preventing this form of a 51% attack (other than creating payment channels that don't offer the possibility of revocation) as it is abusing exactly the core idea of lightning to do something in secret without broadcasting it.
>
> Best regards Rene
>
> ---
>
> http://www.rene-pickhardt.de
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180313/be085197/attachment-0001.html>