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

[ZmnSCPxj via Lightning-dev]

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 

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

[Christian Decker]

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 

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

[Anthony Towns]

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?

[René Pickhardt via Lightning-dev]

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,
> 

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

[Christian Decker]

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 

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

[René Pickhardt via Lightning-dev]

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@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev