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