<div dir="ltr"><div dir="auto">Hey everyone,<div dir="auto"><br></div><div dir="auto">disclaimer: as mentioned in my other mail ( <a href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-March/001065.html">https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-March/001065.html</a> ) 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.</div><div dir="auto">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.<br></div><div dir="auto"><br></div><div>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?"</div><div>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 <code style="font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial;font-family:consolas,"liberation mono",courier,monospace;padding:0.2em 0.4em;margin:0px;font-size:12.75px;background-color:rgba(27,31,35,0.05);border-radius:3px;color:rgb(36,41,46)"><i>to_self_delay</i></code><span style="font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial;color:rgb(36,41,46);font-family:-apple-system,blinkmacsystemfont,"segoe ui",helvetica,arial,sans-serif,"apple color emoji","segoe ui emoji","segoe ui symbol";font-size:15px;background-color:rgb(250,251,252)"><i> </i></span> period, have the commitment transactions been spent? (How) Can they be revoked?"</div><div dir="auto"><br></div><div dir="auto"><br></div><div>As for the technical details I quote from the spec of BOLT 3:</div><div dir="auto"><span style="color:rgb(36,41,46);font-family:-apple-system,blinkmacsystemfont,"segoe ui",helvetica,arial,sans-serif,"apple color emoji","segoe ui emoji","segoe ui symbol";font-size:15px;background-color:rgb(250,251,252)">"<i>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 </i></span><code style="font-family:consolas,"liberation mono",courier,monospace;padding:0.2em 0.4em;margin:0px;font-size:12.75px;background-color:rgba(27,31,35,0.05);border-radius:3px;color:rgb(36,41,46)"><i>to_self_delay</i></code><span style="color:rgb(36,41,46);font-family:-apple-system,blinkmacsystemfont,"segoe ui",helvetica,arial,sans-serif,"apple color emoji","segoe ui emoji","segoe ui symbol";font-size:15px;background-color:rgb(250,251,252)"><i> 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)</i>"</span><br></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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:</div><div dir="auto">0.) The max value of <span style="background-color:rgba(27,31,35,0.05);color:rgb(36,41,46);font-family:consolas,"liberation mono",courier,monospace;font-size:12.75px">to_self_delay</span> is evaluated. Let us assume it is 72 blocks (or half a day).</div><div dir="auto">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.</div><div dir="auto">2.) The attacker spends all the fraudulent (old) commitment transactions in the first block of her secrete mining endeavor.</div><div dir="auto">3.) Meanwhile the attacker starts spending her own funds of her payment channels e.g on decentralized exchanges for any other (crypto)currency.</div><div dir="auto">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.)</div><div dir="auto"><br></div><div dir="auto">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.: <a href="https://github.com/lightningnetwork/lnd/issues/677">https://github.com/lightningnetwork/lnd/issues/677</a> ).</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div>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. </div><div dir="auto"><br></div><div dir="auto">Best regards Rene</div><div dir="auto"><br></div><div dir="auto">---</div><div dir="auto"><br></div><div><a href="http://www.rene-pickhardt.de">http://www.rene-pickhardt.de</a></div></div>
</div>