{"type":"rich","version":"1.0","title":"René Pickhardt [ARCHIVE] wrote","author_name":"René Pickhardt [ARCHIVE] (npub1zl…d2k4w)","author_url":"https://yabu.me/npub1zlxd3xlzjhq2ue03e5m5p2w6mp8v3dkhq5r39flsftjjsje04wvsdd2k4w","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2018-03-13\n📝 Original message:\nHey everyone,\n\ndisclaimer: as mentioned in my other mail (\nhttps://lists.linuxfoundation.org/pipermail/lightning-dev/2018-March/001065.html\n) I am currently studying the revocation system of duplex micropayment\nchannels in detail but I am also pretty new to the topic. So I hope the\nattack I am about to describe is not possible and it is just me overseeing\nsome detail or rather my lack of understanding.\nThat being said even after waiting one week upon discovery and double\nchecking the assumptions I made I am still positive that the revocation\nsystem in its current form allows for a new form of a 51% attack. This\nattack seems to be way more harmful than a successful 51% attack on the\nbitcoin network. Afaik within the bitcoin network I could 'only double\nspend' my own funds with a successful 51% attack. In the lightning case it\nseems that an attacker could steal an arbitrary amount of funds as long as\nthe attacker has enough payment channels with enough balance open.\n\nThe attack itself follows exactly the philosophy of lightning: \"If a tree\nfalls in the forest and no one is around to hear it. Does it make a sound?\"\nIn the context of the attack this would translate to: \"If a 51% attacker\nsecretly mines enough blocks after fraudulently spending old commitment\ntransactions and no one sees it during the the *to_self_delay*  period,\nhave the commitment transactions been spent? (How) Can they be revoked?\"\n\n\nAs for the technical details I quote from the spec of BOLT 3:\n\"*To allow an opportunity for penalty transactions, in case of a revoked\ncommitment transaction, all outputs that return funds to the owner of the\ncommitment transaction (a.k.a. the \"local node\") must be delayed for *\n*to_self_delay** blocks. This delay is done in a second-stage HTLC\ntransaction (HTLC-success for HTLCs accepted by the local node,\nHTLC-timeout for HTLCs offered by the local node)*\"\n\nAssume an attacker has 51% of the hash power she could open several\nlightning channels and in particular accept any incoming payment channel\n(the more balance is in her channels the more lucrative the 51% attack).\nSince the attacker already has a lot of hash power it is reasonable (but\nnot necessary) to assume that the attacker already has a lot of bitcoins\nand is well known to honest nodes in the network which makes it even more\nlikely to have many open channels.\n\nThe attacker keeps track of her (revocable) commitment transactions in\nwhich the balance is mostly on the attackers side. Once the attacker knows\nenough of these (old) commitment transactions the attack is being executed\nin the following way:\n0.) The max value of to_self_delay is evaluated. Let us assume it is 72\nblocks (or half a day).\n1.) The attacker secretly starts mining on her own but does not broadcasts\nany successfully mined block. Since the attacker has 51% of the hash power\nshe will most likely be faster than the network to mine the 72 blocks of\nthe safety period in which fraudulent commitment transactions could be\nrevoked.\n2.) The attacker spends all the fraudulent (old) commitment transactions in\nthe first block of her secrete mining endeavor.\n3.) Meanwhile the attacker starts spending her own funds of her payment\nchannels e.g on decentralized exchanges for any other (crypto)currency.\n4.) As soon as the attacker has mined enough blocks that the commitment\ntransactions cannot be revoked she broadcasts her secretly minded\nblockchain which will be accepted by the network as it is the longest\nchain. (In Particular she includes all the other bitcoin transactions that\nare also in the original public blockchain so that other people don't even\nrealize something suspicious has happened.)\n\nSince according to the spec channels should never be balanced worse than\n99% to 1% the attacker could steal up to 99% of all the bitcoins allocated\nin the sum of all payment channels the attacker was connected to. This\namount could obviously be way higher than just double spending her own\nfunds. This attack would be interesting in particular for the power nodes\ncreated by the Barabasi-Albert model of lnd's autopilot (c.f.:\nhttps://github.com/lightningnetwork/lnd/issues/677 ).\n\nI understand that with the growth of the bitcoin (mining) network a 51%\nattack becomes less and less likely. Also I am very happy to be proven\nfalse about the attack that I am describing.\n\nAnother sad thing about this attack is that I currently do not see any\n(reasonable) way of preventing this form of a 51% attack (other than\ncreating payment channels that don't offer the possibility of revocation)\nas it is abusing exactly the core idea of lightning to do something in\nsecret without broadcasting it.\n\nBest regards Rene\n\n---\n\nhttp://www.rene-pickhardt.de\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180313/bb92bcf7/attachment-0001.html\u003e"}