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

Tue Mar 13 14:55:10 UTC 2018

Hi René,

very good question. I think the simple answer is that this is exactly
the reason why not having a participant in the network that can 51%
attack over a prolonged period is one of the base assumptions in
Lightning. These attacks are deadly to all blockchains, and we are
certainly no different in that regard.

More interesting is the assertion that this may indeed be more dangerous
than a classical 51% attack, in which an attacker can only doublespend
funds that she had control over at some point during the attack
(duration being defined as the period she can build a hidden fork of). I
think the case for Lightning is not more dangerous since what they could
do is enforce an old state in which they had a higher balance than in
the final state, without incurring in a penalty. The key observation is
that in this old state they actually had to have the balance they are
stealing on the channel. So this maps directly to the classical
scenario in which an attacker simply doublespends funds they had control
over during the attack, making the attack pretty much the same.

Another interesting observation is that with Lightning the state that
the attacker is enforcing may predate the attack, e.g., an attacker
could use a state that existed and was replaced before it started
generating its fork. This is in contrast to the classical doublespend
attack in which invalidated spends have to happen after the fork
started, and the attacker just filters them from its fork.

But as I said before, if we can't count on there not being a 51%
attacker, then things are pretty much broken anyway :-)

Cheers,
Christian

René Pickhardt via Lightning-dev
<lightning-dev at lists.linuxfoundation.org> writes:
> 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
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev