Re: [Lightning-dev] New form of 51% attack via lightning's revocation system possible?
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 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 transactio
Re: [Lightning-dev] New form of 51% attack via lightning's revocation system possible?
Good example, even if rather hard to setup :-) What I meant with the attack being identical is that we can replay the entire attack on-chain, without needing Lightning in the first place, i.e., the attacker needed to own the funds he is going to steal at some time, whether that is as part of a channel settlement that is repalced or an output that has been spent. You are however right that Lightning with its multi-hop payments increases the potential exposure of a node, increasing the attackers payoff in case of a successful attack. Cheers, Christian René Pickhardt writes: > Hey Christian, > > I agree with you on almost anything you said. however I disagree that in > the lightning case it produces just another double spending. I wish to to > emphasize on my statement that the in the case with lightning such a 51% > attack can steal way more BTC than double spending my own funds. The > following example is a little extrem and constructed but it should help to > make the point. Also for pure convenience reasons I neglected the fact that > channels should never be worse distributed than 99% to 1%: > > Let us assume I am the attacker currently owning 1000 BTC. Now 1000 nodes > called n_0,...n_{999} open a payment channel with me (all funded by the > other side with 999 BTC in each channel (and 1 BTC from me)) resulting in > the following channel balance sheet: > c_0: me = 1 BTC and n_0 = 999 BTC > c_1: me = 1 BTC and n_1 = 999 BTC > c_2: me = 1 BTC and n_2 = 999 BTC > ... > c_{999}: me = 1 BTC and n_{999} = 999 BTC > > Now node n_0 sends 1 BTC to each node n_1,...,n_{999} (using me for routing > the payment) so the channel balances read: > c_0: me = 1000 BTC and n_0 = 0 BTC (save the corresponding > commitment transaction!) > c_1: me = 0 BTC and n_1 = 1000 BTC > c_2: me = 0 BTC and n_2 = 1000 BTC > ... > c_{999}: me= 0 BTC and n_{999} = 1000 BTC > > next n_1 sends 1000 BTC to n_0: > c_0: me = 0 BTC and n_0 = 1000 BTC > c_1: me = 1000 BTC and n_1 =0 BTC (save the corresponding > commitment transaction!) > c_2: me = 0 BTC and n_2 = 1000 BTC > ... > c_{999}: me= 0 BTC and n_{999} = 1000 BTC > > similarly n_2 sends 1000 BTC to n_1: > c_0: me = 0 BTC and n_0 = 1000 BTC > c_1: me = 0 BTC and n_1 = 1000 BTC > c_2: me = 1000 BTC and n_2 =0 BTC (save the corresponding > commitment transaction!) > ... > c_{999}: me = 0 BTC nad n_{999} = 1000 BTC > > following this scheme n_3 --[1000 BTC]--> n_2, n_4 --[1000 BTC]--> n_3,... > > due to this (as mentioned highly constructed and artificial behavior) I > will have old commitment transactions in *each* and every channel (which > spends 1000 BTC to me) > > When starting my secret mining endeavor I spend those commitment > transactions which gives in this particular case 1000 * 1000 BTC = 1M BTC > to me. > > So while I agree that a 51% is a problem for any blockchain technology I > think the consequences in the lightning scenario are way more problematic > and makes such an attack also way more interesting for a dishonest > fraudulent person / group. In particular I could run for a decade on stable > payment channels storing old state and at some point realizing it would be > a really big opportunity secretly cashing in all those old transactions > which can't be revoked. > > I guess one way of resolving this kind of limitless but rare possibility > for stealing could be to make sure no one can have more than 2 or three > times the amount of BTC she owns in all the payment channels the person has > open. As funding transactions are publicly visible on the blockchain one > could at least use that measure to warn people before opening and funding > another payment channel with a node that is heavily underfunded. Also in > the sense of network topology such a measure would probably make sure that > channels are somewhat equally funded. > > best Rene > > > > > > On Tue, Mar 13, 2018 at 3:55 PM, Christian Decker < > decker.christ...@gmail.com> wrote: > >> 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 ch
Re: [Lightning-dev] New form of 51% attack via lightning's revocation system possible?
On Tue, Mar 13, 2018 at 06:07:48PM +0100, René Pickhardt via Lightning-dev wrote: > Hey Christian, > I agree with you on almost anything you said. however I disagree that in the > lightning case it produces just another double spending. I wish to to > emphasize > on my statement that the in the case with lightning such a 51% attack can > steal > way more BTC than double spending my own funds. I think you can get a simpler example: * I setup a channel, funding it with 10 BTC (ie, balance is 100% on my side) * Someone else sets up a channel with me, funding it with 5 BTC (balance is 100% on their side) * I route 5 BTC to myself from the first channel through the second: aj -> X -> ... -> victim -> aj * I save the state that says I own all 5BTC in the victim <-> aj channel * I route 5 BTC to myself from the second channel throught the first: aj -> victim -> ... -> X -> aj * At this point I'm back to having 10 BTC (minus some small amont of lightning fees) in the first channel * I use 51% hashing power to mine a secret chain that uses the saved state to close the victim<->aj channel. Once that chain is long enough that I can claim the funds I do so. Once I have claimed the funds on my secret chain and the secret chain has more work than the public chain, I publish it, causing a reorg. * At this point I still have 10 BTC in the original channel, and I have the victim's 5 BTC. I can parallelise this attack as well: before doing any private mining or closing the victim's channel, I can do the same thing with another victim, allowing me to collect old states worth many multiples of up to 10 BTC, and mine them at once, leaving with my original 10BTC minus fees, plus n*10BTC stolen from victims. This becomes more threatening if you add in conspiracy theories about there already being a miner with >51% hashpower, who has financial interests in seeing lightning fail... The main limitation is that it still only allows a 51% miner to steal funds from channels they participate in, so creating channels with identifiable entities with whom you have an existing relationship (as opposed to picking random anonymous nodes) is a defense against this attack. Also, if 51% of hashpower is mining in secret for an extended period, that may be detectable, which may allow countermeasures to be taken? You could also look at this the other way around: at the point when lightning is widely deployed, this attack vector seems like it gives an immediate, personal, financial justification for large economic actors to ensure that hash rate is very decentralised. > In particular I could run for a decade on stable payment channels > storing old state and at some point realizing it would be a really big > opportunity secretly cashing in all those old transactions which can't be > revoked. (I'd find it surprising if many channels stayed open for a decade; if nothing else, I'd expect deflation over that time to cause people to want to close channels) Cheers, aj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] New form of 51% attack via lightning's revocation system possible?
Hey Christian, I agree with you on almost anything you said. however I disagree that in the lightning case it produces just another double spending. I wish to to emphasize on my statement that the in the case with lightning such a 51% attack can steal way more BTC than double spending my own funds. The following example is a little extrem and constructed but it should help to make the point. Also for pure convenience reasons I neglected the fact that channels should never be worse distributed than 99% to 1%: Let us assume I am the attacker currently owning 1000 BTC. Now 1000 nodes called n_0,...n_{999} open a payment channel with me (all funded by the other side with 999 BTC in each channel (and 1 BTC from me)) resulting in the following channel balance sheet: c_0: me = 1 BTC and n_0 = 999 BTC c_1: me = 1 BTC and n_1 = 999 BTC c_2: me = 1 BTC and n_2 = 999 BTC ... c_{999}: me = 1 BTC and n_{999} = 999 BTC Now node n_0 sends 1 BTC to each node n_1,...,n_{999} (using me for routing the payment) so the channel balances read: c_0: me = 1000 BTC and n_0 = 0 BTC (save the corresponding commitment transaction!) c_1: me = 0 BTC and n_1 = 1000 BTC c_2: me = 0 BTC and n_2 = 1000 BTC ... c_{999}: me= 0 BTC and n_{999} = 1000 BTC next n_1 sends 1000 BTC to n_0: c_0: me = 0 BTC and n_0 = 1000 BTC c_1: me = 1000 BTC and n_1 =0 BTC (save the corresponding commitment transaction!) c_2: me = 0 BTC and n_2 = 1000 BTC ... c_{999}: me= 0 BTC and n_{999} = 1000 BTC similarly n_2 sends 1000 BTC to n_1: c_0: me = 0 BTC and n_0 = 1000 BTC c_1: me = 0 BTC and n_1 = 1000 BTC c_2: me = 1000 BTC and n_2 =0 BTC (save the corresponding commitment transaction!) ... c_{999}: me = 0 BTC nad n_{999} = 1000 BTC following this scheme n_3 --[1000 BTC]--> n_2, n_4 --[1000 BTC]--> n_3,... due to this (as mentioned highly constructed and artificial behavior) I will have old commitment transactions in *each* and every channel (which spends 1000 BTC to me) When starting my secret mining endeavor I spend those commitment transactions which gives in this particular case 1000 * 1000 BTC = 1M BTC to me. So while I agree that a 51% is a problem for any blockchain technology I think the consequences in the lightning scenario are way more problematic and makes such an attack also way more interesting for a dishonest fraudulent person / group. In particular I could run for a decade on stable payment channels storing old state and at some point realizing it would be a really big opportunity secretly cashing in all those old transactions which can't be revoked. I guess one way of resolving this kind of limitless but rare possibility for stealing could be to make sure no one can have more than 2 or three times the amount of BTC she owns in all the payment channels the person has open. As funding transactions are publicly visible on the blockchain one could at least use that measure to warn people before opening and funding another payment channel with a node that is heavily underfunded. Also in the sense of network topology such a measure would probably make sure that channels are somewhat equally funded. best Rene On Tue, Mar 13, 2018 at 3:55 PM, Christian Decker < decker.christ...@gmail.com> wrote: > 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, > Christ
Re: [Lightning-dev] New form of 51% attack via lightning's revocation system possible?
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 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