The Lightning Network's penalty system in action

[Wind_FURY]

https://twitter.com/alexbosworth/status/978069194385252352

Lightning DOSers seem organized and motivated, developing specialized software to attack the Beta LND nodes. Node hardening is in progress! We're getting a good opportunity to develop robust p2p deployment strategies.  @juscamarena just saw a live test of the penalty scenario.

This is a good demonstration of the Lightning Network's penalty system in a live setting. I hope to see more attempts penalized, to put all the big blocker misanthropes back in their place.

[1714153226]

1714153226

[1714153226]

1714153226

[1714153226]

1714153226

[1714153226]

1714153226

[AdSkull89]

https://twitter.com/alexbosworth/status/978069194385252352

Lightning DOSers seem organized and motivated, developing specialized software to attack the Beta LND nodes. Node hardening is in progress! We're getting a good opportunity to develop robust p2p deployment strategies.  @juscamarena just saw a live test of the penalty scenario.

https://pbs.twimg.com/media/DZLRXZYX4AAe9Xv.jpg

This is a good demonstration of the Lightning Network's penalty system in a live setting. I hope to see more attempts penalized, to put all the big blocker misanthropes back in their place.

Chance you could post full log for education purposes? Thanks!

[Kakmakr]

I think this is one of the reasons why the spamming of the legacy/SegWit Blockchain was put on hold. Most of those resources are now focussed and channelled towards sabotaging the Lightning Network. These people know the Lightning Network is the real game breaker for them and they have to sabotage it.

I am glad to see pro-active measures to implement strategies to protect LND nodes. We are being attacked from all sides and we are still winning. ^lol^

[bitcoinfuck]

what you trying to say  ??

[Xynerise]

what you trying to say  ??

Someone supposedly tried to cheat in the Lightning Network and was penalised and lost his bitcoin

But in reality it most likely was a user restoring a corrupted channel database that unintentionally broadcast the old channel state

Whatever the reason, it means the Lightning Network works as intended: if any user broadcasts a stale channel state, that user will forfeit their bitcoins in the channel.
Edit: Confirmed that it was a user that restored corrupted channel database
https://lightningcommunity.slack.com/archives/C6AFCN3KL/p1521915378000006

[DevilOper]

Someone supposedly tried to cheat in the Lightning Network and was penalised and lost his bitcoin

But in reality it most likely was a user restoring a corrupted channel database that unintentionally broadcast the old channel state

Whatever the reason, it means the Lightning Network works as intended: if any user broadcasts a stale channel state, that user will forfeit their bitcoins in the channel.

Why some cheater could not store and then broadcast the old channel state, this way stealing all the counterparty's bitcoins?

[Xynerise]

Why some cheater could not store and then broadcast the old channel state, this way stealing all the counterparty's bitcoins?

That's actually what happened -- or tried to.
The Lightning Network structures commitment transactions so that anyone who submits an outdated one will pay a stiff penalty. (see chapter 3.1.4 in the linked document)
Basically if you open a channel with someone and make a Lightning "transaction" with the person, the commitment transaction that's sent to both parties contains a revocation key that could be used to take all the funds in the channel, and this is updated with every commitment transaction, so if a party decides to be dishonest and broadcast an old commitment transaction, the other participant in the channel has a revocation key in their copy of commitment transaction that can be used to drain the channel of funds to the benefit of the honest participant.

TL;DR:
 A and B open a payment channel on the Lightning Network via a 2-of-2 multisig, the input of the transaction is their balance in the channel.
A & B both sign transactions spending the bitcoins between themselves, but don't broadcast it to the network (a copy is saved on their machine)
Whenever they make a transaction with one another they must also sign a commitment transaction that revokes the whole channel so they both get their funds.
However this commitment transaction is different for each party:In  A's copy of the transaction, participant B can spend his bitcoins immediately while A has to wait for a period before the network will accept it, ditto for B's copy: it's immediate for A but there's a delay for B.
The commitment transactions have  revocation keys that could be used by each participant to take the funds of the other (i.e the whole money in the channel)
Whenever a commitment transaction is made, the revocation key of each participant is revealed to the other party (A's is revealed to B, and B's is revealed to A) so A's copy of the commitment transaction is useless because if A tries to cheat by broadcasting the old commitment transaction, B has the revocation key that can be used to claim A's bitcoin in the channel. Ditto for B's copy

In this case, let's say A tried to cheat, by broadcasting a stale channel state (for example where he has more bitcoin or has already received goods and is trying to take the money for the goods back), B then uses the revocation key of A to broadcast a transaction claiming A's money in the channel so now B has the Bitcoins of A because A tried to cheat the system.

[DevilOper]

In this case, let's say A tried to cheat, by broadcasting a stale channel state (for example where he has more bitcoin or has already received goods and is trying to take the money for the goods back), B then uses the revocation key of A to broadcast a transaction claiming A's money in the channel so now B has the Bitcoins of A because A tried to cheat the system.

The question was what prevents B from storing some old trsnsaction of A then broadcasting it as if form A and thus revoke A's coins?

[Xynerise]

The question was what prevents B from storing some old trsnsaction of A then broadcasting it as if form A and thus revoke A's coins?

Commitment transactions are timelocked so the network won't accept it until end a certain time has elapsed.

However this commitment transaction is different for each party:In  A's copy of the transaction, participant B can spend his bitcoins immediately while A has to wait for a period before the network will accept it, ditto for B's copy: it's immediate for A but there's a delay for B.

During that time the other party can broadcast a revocation transaction claiming the cheating participant's bitcoin.

In this case, let's say A tried to cheat, by broadcasting a stale channel state (for example where he has more bitcoin or has already received goods and is trying to take the money for the goods back), B then uses the revocation key of A to broadcast a transaction claiming A's money in the channel so now B has the Bitcoins of A because A tried to cheat the system.

However if the time elapses and the other party does not counteract this dishonest behaviour (perhaps the user was offline and  wasn't monitoring  the channel state), then the "hacker" can abscond with their funds.
That is why Laolu and other Lightning developers envisioned Watchtowers that detect this fraudulent behaviour and notify the other participant.

[buwaytress]

Captain Unobvious here. I think I understood the gist of the message here, but is anyone able to show a quick breakdown of which parts of that code demonstrated the detection of behaviour and resulting penalisation? I concede it just escapes me.

Also, will this or did this translate successfully on chain? Or does that not matter?

And if Xynerise is correct, that the attempt was inadvertent... is there a way to determine if such attempts (to broadcast stale state) will be deliberate or not?

[Xynerise]

Captain Unobvious here. I think I understood the gist of the message here, but is anyone able to show a quick breakdown of which parts of that code demonstrated the detection of behaviour and resulting penalisation? I concede it just escapes me.

It's actually straight forward.
The be00.... is the LN channel ID
The first line shows that

Code:

Revoked state #20 was broadcast!!!

meaning that the current (latest) channel state at that time was >20 and the counterparty attempted to broadcast state 20, which was stale, and as stated above, old commitment transactions are timelocked for a while so the transaction the party tried to broadcast (not shown) won't be accepted by the network because the outputs are timelocked.

Code:

A channel has been breached with txid: ale96ee5dd93bcf1e6b3359e5a82fa17f52901110be090db24f9812414fccb2f
Waiting for confirmation, then justice will be served!

What that means is that the counterparty that was almost cheated broadcast the penalty transaction with that transaction ID claiming the bitcoin of the "hacker" or unwitting user.

Also, will this or did this translate successfully on chain? Or does that not matter?

It already confirmed Lightning Network transactions are still bitcoin transactions.

And if Xynerise is correct, that the attempt was inadvertent... is there a way to determine if such attempts (to broadcast stale state) will be deliberate or not?

No.
The protocol doesn't care.
As long as you do not follow the rules and broadcast an old channel state, either by cheating, or a unilateral transaction when the timelock isn't over, then your counterparty will get your revocation key and can claim your bitcoins in the channel.
Same with with bitcoin and other cryptocurrencies; when a user gets phished and downloads a malware wallet, or is hijacked by a clipboard malware, it doesn't matter that the attempt wasn't deliberate, a mistake  or fraudulent, what other nodes see is a valid bitcoin transaction that can be mined.

So, if the problem is from a user's wallet, then it's not the fault of the Lightning Network since the protocol works as intended.

[gentlemand]

According to this now deleted thread this is a balls up, not an attack. 

https://archive.is/mfpkJ

Technical error by an honest user who got caught out by the network doing its thing. Perhaps lightning networks have a bit further to go than many expect before they're fully foolproof.

[buwaytress]

No.
The protocol doesn't care.
As long as you do not follow the rules and broadcast an old channel state, either by cheating, or a unilateral transaction when the timelock isn't over, then your counterparty will get your revocation key and can claim your bitcoins in the channel.
Same with with bitcoin and other cryptocurrencies; when a user gets phished and downloads a malware wallet, or is hijacked by a clipboard malware, it doesn't matter that the attempt wasn't deliberate, a mistake  or fraudulent, what other nodes see is a valid bitcoin transaction that can be mined.

So, if the problem is from a user's wallet, then it's not the fault of the Lightning Network since the protocol works as intended.

Thank you, that does clear it up a little bit more! Does anyone know if the counterparty did end up claiming the perpetrator's coins? If not, what happens to the unclaimed coins when the channel closes?

According to this now deleted thread this is a balls up, not an attack. 

https://archive.is/mfpkJ

Technical error by an honest user who got caught out by the network doing its thing. Perhaps lightning networks have a bit further to go than many expect before they're fully foolproof.

I'm not questioning how the network follows and enforces protocol rules at all, but yes, there'll be plenty of users like yours truly who'll desperately want to help test/use, but not if we'll probably end up breaking rules... that's the nature of new tech I guess.

[Spazzer]

Not going to lie I got really excited when this happened. It shows that integrated trusted security can be scaled. The only problem though is as mentioned above what if it was unintentionally broadcast the old channel state.

[Kakmakr]

According to this now deleted thread this is a balls up, not an attack. 

https://archive.is/mfpkJ

Technical error by an honest user who got caught out by the network doing its thing. Perhaps lightning networks have a bit further to go than many expect before they're fully foolproof.

Yes, I also read that before it was deleted. I think the upside of this is that the penalty system was "tested" and it worked. This is definitely not a negative result, but rather very positive. If you do something that would be perceived as a "cheat", the LN will kick in to punish you for that.

A lot of people like to push the boundaries and the Lightning Network just proved that it will not tolerate cheating. <intentional or unintentional> 

[DevilOper]

The question was what prevents B from storing some old trsnsaction of A then broadcasting it as if form A and thus revoke A's coins?

Commitment transactions are timelocked so the network won't accept it until end a certain time has elapsed.

However this commitment transaction is different for each party:In  A's copy of the transaction, participant B can spend his bitcoins immediately while A has to wait for a period before the network will accept it, ditto for B's copy: it's immediate for A but there's a delay for B.

During that time the other party can broadcast a revocation transaction claiming the cheating participant's bitcoin.

In this case, let's say A tried to cheat, by broadcasting a stale channel state (for example where he has more bitcoin or has already received goods and is trying to take the money for the goods back), B then uses the revocation key of A to broadcast a transaction claiming A's money in the channel so now B has the Bitcoins of A because A tried to cheat the system.

However if the time elapses and the other party does not counteract this dishonest behaviour (perhaps the user was offline and  wasn't monitoring  the channel state), then the "hacker" can abscond with their funds.
That is why Laolu and other Lightning developers envisioned Watchtowers that detect this fraudulent behaviour and notify the other participant.

Still unclear.

A sends to B certain amount within LN channel (transaction t').

B does not receive it (does not matter why, network was down or he just droped it).

Now the channel is to be closed: at which state?

1) Before t': B reveals he received t', claims A to be cheater and takes all coins.
2) After t':
  a) B claims A never transmitted t' to him - A cheater, B takes all coins.
      OR, if this scenario does not work -
  b) B reveals his transaction t'+1 - A cheater, B takes all coins.

So, who or what guaranriees LN channel transactions are free of Byzantine General's problems?

[DannyHamilton]

Technical error by an honest user who got caught out by the network doing its thing.

Correct.

Imagine a "technical error by an honest user" in Bitcoin such that the "honest user" accidentaly reveals his private key to the internet.  In that case, someone could simple use that private key to take all of the "honest user's" bitcoins.  The Bitcoin network would just be "doing its thing" by allowing the transaction to happen.

Much like the Bitcoin Network, the point of the Lightning Network is not to protect users from their own mistakes.  It is up to users to take personal responsibility for protecting themselves from themselves.  The Lightning Network just tries to protect users from malicious attacks.

Perhaps lightning networks have a bit further to go than many expect before they're fully foolproof.

There is no such thing as foolproof.  There is always a fool out there that can do something foolish regardless of what protections you put in place. That is true not only of Lightning Network, but of EVERY PIECE of technology that has ever existed going all the way back to the hammer or the wheel.

Still unclear.

A sends to B certain amount within LN (transaction t').

It is clear that you do not understand how Lightning Network works.

A cannot "send to B an amount within LN" without B's cooperation.  Either they BOTH agree on the transaction (and therefore BOTH sign the transaction) or it does not happen.  LN transactions are multi-sig tranactions that either require signatures from BOTH parties OR require that one of the parties has access to a revocation key. Revocation keys to old states are made available as part of the process of establishing the new state.

[ZaoXhou]

I think this is one of the reasons why the spamming of the legacy/SegWit Blockchain was put on hold. Most of those resources are now focussed and channelled towards sabotaging the Lightning Network. These people know the Lightning Network is the real game breaker for them and they have to sabotage it.

I am glad to see pro-active measures to implement strategies to protect LND nodes. We are being attacked from all sides and we are still winning. ^lol^

I still don't think off-chain transactions should be valued the same as on-chain transactions.

[DannyHamilton]

I still don't think off-chain transactions should be valued the same as on-chain transactions.

Given the fact that off-chain transactions are more fungible, perhpas they should be valued HIGHER than on-chain transactions.

Seriously though, what is it about off-chain that you dislike so much?

[DevilOper]

It is clear that you do not understand how Lightning Network works.

Please enlighten me, Sir.

A cannot "send to B an amount within LN" without B's cooperation.  Either they BOTH agree on the transaction (and therefore BOTH sign the transaction) or it does not happen.

Are you going to say the entire PoS PoW concept (in order to solve BGP) is useless?

LN transactions are multi-sig tranactions that either require signatures from BOTH parties OR require that one of the parties has access to a revocation key. Revocation keys to old states are made available as part of the process of establishing the new state.

Who or what guarantees the revocation key is really revocation key?

Edit: typo