Cheating the penalty system with lightening network by force publishing old com.

[legriffon]

I'm currently reading Mastering the Lightning Network by Antonopoulos, Osuntokun, and Pickhardt (2021). I wanted to know the risks of nefarious actors posing as merchants or other suitable channel partners who create seemingly legit channels, but also infect their partners through other means with malware, trojans, RATs, etc. that then causes the victim to unknowingly force publish an old commitment transaction thereby unknowingly punishing themselves and forfeiting their funds to the attacker. Is this a plausible threat to the lightning network, and if so, how best to mitigate such a threat? I've included a passage from the book as a refresher of the channel construction process below. By the way for anyone who hasn't read it, it's a great book thus far.


Let us go through the channel construction scenario again, adding a penalty mechanism to protect against cheating:
1. Alice creates a channel with Bob and puts 100k satoshi into it.
2. Alice sends 30k satoshi to Bob and puts 100k satoshi into it.
3. Alice tries to cheat Bob out of his earned 30k satoshi by publishing an old commitment transaction claiming the full 100k satoshi for herself.
4. Bob detects the fraud and punishes Alice by taking the full 100k satoshi for
himself.
5. Bob ends up with 100k satoshi, gaining 70k satoshi for catching Alice cheating.
6. Alice ends up with 0 satoshi.
7. Trying to cheat Bob out of 30k satoshi, she loses the 70k satoshi she owned. With a strong penalty mechanism, Alice is not tempted to cheat by publishing an old
commitment transaction because she risks losing her entire balance.

[DaveF]

I'm currently reading Mastering the Lightning Network by Antonopoulos, Osuntokun, and Pickhardt (2021). I wanted to know the risks of nefarious actors posing as merchants or other suitable channel partners who create seemingly legit channels, but also infect their partners through other means with malware, trojans, RATs, etc. that then causes the victim to unknowingly force publish an old commitment transaction thereby unknowingly punishing themselves and forfeiting their funds to the attacker. Is this a plausible threat to the lightning network, and if so, how best to mitigate such a threat? I've included a passage from the book as a refresher of the channel construction process below. By the way for anyone who hasn't read it, it's a great book thus far.


Let us go through the channel construction scenario again, adding a penalty mechanism to protect against cheating:
1. Alice creates a channel with Bob and puts 100k satoshi into it.
2. Alice sends 30k satoshi to Bob and puts 100k satoshi into it.
3. Alice tries to cheat Bob out of his earned 30k satoshi by publishing an old commitment transaction claiming the full 100k satoshi for herself.
4. Bob detects the fraud and punishes Alice by taking the full 100k satoshi for
himself.
5. Bob ends up with 100k satoshi, gaining 70k satoshi for catching Alice cheating.
6. Alice ends up with 0 satoshi.
7. Trying to cheat Bob out of 30k satoshi, she loses the 70k satoshi she owned. With a strong penalty mechanism, Alice is not tempted to cheat by publishing an old
commitment transaction because she risks losing her entire balance.

If there was a 'nefarious actor' that could get access to your LN server machine, it would be better for them to then close ALL your channels and send themselves all your BTC.
If they enough control of your machine to mess with your channels your are pretty much screwed anyway.

-Dave

[n0nce]

I'm currently reading Mastering the Lightning Network by Antonopoulos, Osuntokun, and Pickhardt (2021). I wanted to know the risks of nefarious actors posing as merchants or other suitable channel partners who create seemingly legit channels, but also infect their partners through other means with malware, trojans, RATs, etc. that then causes the victim to unknowingly force publish an old commitment transaction thereby unknowingly punishing themselves and forfeiting their funds to the attacker. Is this a plausible threat to the lightning network, and if so, how best to mitigate such a threat? I've included a passage from the book as a refresher of the channel construction process below. By the way for anyone who hasn't read it, it's a great book thus far.


Let us go through the channel construction scenario again, adding a penalty mechanism to protect against cheating:
1. Alice creates a channel with Bob and puts 100k satoshi into it.
2. Alice sends 30k satoshi to Bob and puts 100k satoshi into it.
3. Alice tries to cheat Bob out of his earned 30k satoshi by publishing an old commitment transaction claiming the full 100k satoshi for herself.
4. Bob detects the fraud and punishes Alice by taking the full 100k satoshi for
himself.
5. Bob ends up with 100k satoshi, gaining 70k satoshi for catching Alice cheating.
6. Alice ends up with 0 satoshi.
7. Trying to cheat Bob out of 30k satoshi, she loses the 70k satoshi she owned. With a strong penalty mechanism, Alice is not tempted to cheat by publishing an old
commitment transaction because she risks losing her entire balance.

So first of all, you made some mistakes when copying this quote; to prevent any confusions I'm copy-pasting directly from GitHub (or are these mistakes in the print version? I don't own the print version... yet).

Let us go through the channel construction scenario again, adding a penalty mechanism to protect against cheating:

• Alice creates a channel with Bob and puts 100k satoshi into it.
• Alice sends 30k satoshi to Bob.
• Alice tries to cheat Bob out of his earned 30k satoshi by publishing an old commitment transaction claiming the full 100k satoshi for herself.
• Bob detects the fraud and punishes Alice by taking the full 100k satoshi for himself.
• Bob ends up with 100k satoshi, gaining 70k satoshi for catching Alice cheating.
• Alice ends up with 0 satoshi.
• Trying to cheat Bob out of 30k satoshi, she loses the 70k satoshi she owned.

With a strong penalty mechanism, Alice is not tempted to cheat by publishing an old commitment transaction because she risks losing her entire balance.

As DaveF correctly said, if someone can infect you in a way that he can force you to send faulty / old channel state updates to the blockchain, he might just as well close all your channels and send himself all your BTC via an on-chain transaction. So no, this is not an attack vector on Lightning.

To protect against compromises of your computer / server, follow basic security practices (and beyond, depending on the amounts at risk).

[NotATether]

I would suggest that Lightning implementations encrypt all stale commitment transactions with a random AES salt (the key would be based on the data of the new commitment transaction, so that it can't be discovered until late at runtime) to prevent their broadcasting by malware.

A deterministic operation can be done with the new commitment tx as the input to possibly combine other variables (such as date/time) that may also be stored by the impl. as part of the commitment, to achieve a random salt to totally prevent this from being guessed as well. The exact manipulation agorithm for the salt is something I still need to work on though.

[ABCbits]

I wanted to know the risks of nefarious actors posing as merchants or other suitable channel partners who create seemingly legit channels, but also infect their partners through other means with malware, trojans, RATs, etc. that then causes the victim to unknowingly force publish an old commitment transaction thereby unknowingly punishing themselves and forfeiting their funds to the attacker.

First of all, how would they infect victim's device? If you're referring to social engineering attack where they persuade the victim to download or run something, the main problem is victim's security awareness. Other means such as finding vulnerability on LN client which run arbitrary script from LN message[1] is very unlikely to happen.

Is this a plausible threat to the lightning network, and if so, how best to mitigate such a threat?

No.

[1] https://docs.lightning.engineering/lightning-network-tools/lnd/send-messages-with-keysend

[legriffon]

I'm currently reading Mastering the Lightning Network by Antonopoulos, Osuntokun, and Pickhardt (2021). I wanted to know the risks of nefarious actors posing as merchants or other suitable channel partners who create seemingly legit channels, but also infect their partners through other means with malware, trojans, RATs, etc. that then causes the victim to unknowingly force publish an old commitment transaction thereby unknowingly punishing themselves and forfeiting their funds to the attacker. Is this a plausible threat to the lightning network, and if so, how best to mitigate such a threat? I've included a passage from the book as a refresher of the channel construction process below. By the way for anyone who hasn't read it, it's a great book thus far.


Let us go through the channel construction scenario again, adding a penalty mechanism to protect against cheating:
1. Alice creates a channel with Bob and puts 100k satoshi into it.
2. Alice sends 30k satoshi to Bob and puts 100k satoshi into it.
3. Alice tries to cheat Bob out of his earned 30k satoshi by publishing an old commitment transaction claiming the full 100k satoshi for herself.
4. Bob detects the fraud and punishes Alice by taking the full 100k satoshi for
himself.
5. Bob ends up with 100k satoshi, gaining 70k satoshi for catching Alice cheating.
6. Alice ends up with 0 satoshi.
7. Trying to cheat Bob out of 30k satoshi, she loses the 70k satoshi she owned. With a strong penalty mechanism, Alice is not tempted to cheat by publishing an old
commitment transaction because she risks losing her entire balance.

So first of all, you made some mistakes when copying this quote; to prevent any confusions I'm copy-pasting directly from GitHub (or are these mistakes in the print version? I don't own the print version... yet).

Let us go through the channel construction scenario again, adding a penalty mechanism to protect against cheating:

• Alice creates a channel with Bob and puts 100k satoshi into it.
• Alice sends 30k satoshi to Bob.
• Alice tries to cheat Bob out of his earned 30k satoshi by publishing an old commitment transaction claiming the full 100k satoshi for herself.
• Bob detects the fraud and punishes Alice by taking the full 100k satoshi for himself.
• ob ends up with 100k satoshi, gaining 70k satoshi for catching Alice cheating.
• Alice ends up with 0 satoshi.
• Trying to cheat Bob out of 30k satoshi, she loses the 70k satoshi she owned.

With a strong penalty mechanism, Alice is not tempted to cheat by publishing an old commitment transaction because she risks losing her entire balance.

As DaveF correctly said, if someone can infect you in a way that he can force you to send faulty / old channel state updates to the blockchain, he might just as well close all your channels and send himself all your BTC via an on-chain transaction. So no, this is not an attack vector on Lightning.

To protect against compromises of your computer / server, follow basic security practices (and beyond, depending on the amounts at risk).

Probably just a copy and paste error, as you will see you have also made a copy and paste error and missed out a capital B on "ob", thanks for pointing it out though.

[legriffon]

I'm currently reading Mastering the Lightning Network by Antonopoulos, Osuntokun, and Pickhardt (2021). I wanted to know the risks of nefarious actors posing as merchants or other suitable channel partners who create seemingly legit channels, but also infect their partners through other means with malware, trojans, RATs, etc. that then causes the victim to unknowingly force publish an old commitment transaction thereby unknowingly punishing themselves and forfeiting their funds to the attacker. Is this a plausible threat to the lightning network, and if so, how best to mitigate such a threat? I've included a passage from the book as a refresher of the channel construction process below. By the way for anyone who hasn't read it, it's a great book thus far.


Let us go through the channel construction scenario again, adding a penalty mechanism to protect against cheating:
1. Alice creates a channel with Bob and puts 100k satoshi into it.
2. Alice sends 30k satoshi to Bob and puts 100k satoshi into it.
3. Alice tries to cheat Bob out of his earned 30k satoshi by publishing an old commitment transaction claiming the full 100k satoshi for herself.
4. Bob detects the fraud and punishes Alice by taking the full 100k satoshi for
himself.
5. Bob ends up with 100k satoshi, gaining 70k satoshi for catching Alice cheating.
6. Alice ends up with 0 satoshi.
7. Trying to cheat Bob out of 30k satoshi, she loses the 70k satoshi she owned. With a strong penalty mechanism, Alice is not tempted to cheat by publishing an old
commitment transaction because she risks losing her entire balance.

If there was a 'nefarious actor' that could get access to your LN server machine, it would be better for them to then close ALL your channels and send themselves all your BTC.
If they enough control of your machine to mess with your channels your are pretty much screwed anyway.

-Dave

Yea obviously if there is remote access using their high level of access to empty accounts is going to be their best bang for buck.

I would suggest that Lightning implementations encrypt all stale commitment transactions with a random AES salt (the key would be based on the data of the new commitment transaction, so that it can't be discovered until late at runtime) to prevent their broadcasting by malware.

A deterministic operation can be done with the new commitment tx as the input to possibly combine other variables (such as date/time) that may also be stored by the impl. as part of the commitment, to achieve a random salt to totally prevent this from being guessed as well. The exact manipulation agorithm for the salt is something I still need to work on though.

I think something like this is good, it acts as a safeguard, should a bug or vulnerability in software ever be discovered that would make manipulation possible, it could provide another layer of defence.

[franky1]

social engineering to get people to download particular wallets is easy.

take a semi-nefarious scheme recently
a certain company wanted to offer 'turbo' channels where funds appeared in channels before actual funds locked (before any confirms) but to accept such channels people had to use their wallet/software.
so its easy to convince people to use a particular wallet if they simply say they offer a new feature, but only available via a certain wallet before you even get a chance to have a channel

also 99.9999% of people have no clue about viewing raw TX data or the LN payment data. heck even some pretending to be LN devs have no clue of the data structure of format that passes between channel partners.
or what they are actually signing or whats actually being passed in api calls to servers or IP packet data.
heck most dont even see the agreement of payments happening. because the GUI hides it behind glossy images and buttons and labels, they just get to set a limit of what to allow and then have the program 'autopilot it' without needing them to press any buttons at each event/per payment.

as for methods to steal funds through people you already have channels with. well this has been done so many times its no longer funny.
its why the LN devs are starting to make middlemen to be managers/watchtowers and also having idea's of 3-of-3 signatories and other things to try to avoid one person blackmailing/freezing/extorting/punishing the other.

and yes even the LN devs have lost value in many many attempts to bug fix many issues the network still has.
USE AT YOUR OWN RISK AND DONT BELIEVE THE UTOPIAN DREAM ADVERTS

LN is more at risk of loss than bitcoin is.
LN has more flaws/bugs and issues than bitcoin.
LN has more ways to extort, cheat and steal than bitcoin
LN is not bitcoin

[n0nce]

social engineering to get people to download particular wallets is easy.

If you can social engineer someone to download an infected version of Lightning, it's not Lightning's fault when they lose funds. They literally can't do anything against this - like any other software.
You could just as well get them to download an infected Bitcoin Core or simply a complete RAT virus that gives you full control of the system and the ability to steal all of their cryptocurrencies, right? What's this to do with flaws in Lightning?

By your definition, Bitcoin Core is also a bad software because I could convince someone to use my modified binary that generates wallets from a fixed randomness that I predefined myself.

[Welsh]

LN is more at risk of loss than bitcoin is.
LN has more flaws/bugs and issues than bitcoin.
LN has more ways to extort, cheat and steal than bitcoin

Might be worth going into the reasons why you believe this. Bugs,  and flaws would be hard to measure, since not all bugs are discovered in either of the software's. Unless, you have done the math, and Lightening has already exceeded the amount of bugs that bitcoin has had.

Not sure how it has more ways to extort, cheat or steal than Bitcoin, though?

If you can social engineer someone to download an infected version of Lightning, it's not Lightning's fault when they lose funds. They literally can't do anything against this - like any other software.
You could just as well get them to download an infected Bitcoin Core or simply a complete RAT virus that gives you full control of the system and the ability to steal all of their cryptocurrencies, right? What's this to do with flaws in Lightning?

By your definition, Bitcoin Core is also a bad software because I could convince someone to use my modified binary that generates wallets from a fixed randomness that I predefined myself.

Yeah, there's no additional security risk with downloading from a bad source, any more so than Bitcoin core, Electrum or whatever wallet software you're using. The security risk is a lot of people don't do their research, and don't verify software. Ideally, because you have to download the software first of all to be able to verify it, doing so in a isolated machine or isolated environment is best. e.g Qubes OS disposable qube, verify it, and then simply copy it to wherever you want it.

I disagree, many prefer to use whatever software they already familiar. Switching to different software means you need to learn again and handle any migration (in this case moving Bitcoin and make new backup). There's reason why people keep using Windows 7 and Office 2007.

Yeah, people don't like change, and that's why it's hard to get things done sometimes. Slightly astray, but it goes hand in hand with your later statement about poor security awareness. Those that are ignoring that their software or operating system is no longer being offered security updates, are those that don't have very good security awareness.

It's easy if your target have poor security awareness or easily swayed.

Which is unfortunately the majority of users. Also, it might not just be down to these, it might just be complacency. There's a ton of examples of people getting too comfortable, and therefore complacent in their practices, and ultimately paying the price for it.

[BlackHatCoiner]

Not sure how it has more ways to extort, cheat or steal than Bitcoin, though?

I don't know if that applies, but if we're talking about ways to generally lose money in Lightning we have:

• Loss of your partner's revocation keys.
• Loss of your commitment transactions.
• Loss of money by going offline for a long time.

The first two can happen if you lose backups.

Unless, you have done the math, and Lightening has already exceeded the amount of bugs that bitcoin has had.

The times he's whinnied about Lightning, definitely exceed both.

[DaveF]

I feel there are 2 different things being discussed here.

Running lightning isn't the easiest thing in the world unless you are going for one of the prepacked nodes. You DO need to have or at least should have a good working knowledge of linux and how BTC works in general.
If you don't then you really should learn a bunch before doing it with any real amounts of money*

Running BTC as a full node can be bone dead simple if you don't want to build from source. Download binary, verify signature, run it.
If your PC that you are running it on is compromised you may loose your money. If it's the same PC you do your online banking on, and it's compromised, you may loose your money.

HOWEVER, we are BTC enthusiasts here. I have said it before and will say it again, we are EDGE cases, that 1% of users, whatever you want to call us.
For most people using a wall known and well proven SPV wallet like Electrum is fine.

If you think you have to technical ability and knowledge to run a LN node that you built from source form scratch and get hit by something that the OP suggested then guess what. You did not have the ability and knowledge. Step one of running a LN node. Don't run anything else on that sever. Because, you know what, even if it was not malicious software but just something that caused other issues and a crash. You now have to go figure out why and what happened and get your node back up before the other people start force closing because you have been offline.

-Dave

* As always real amounts of money will vary from person to person. If I loose $100 it would suck but not matter in the long run. If Bill Gates looses $100 he would not even notice. If someone living in poverty looses $100 it could really wreck them

[n0nce]

It's easy if your target have poor security awareness or easily swayed.

Which is unfortunately the majority of users. Also, it might not just be down to these, it might just be complacency. There's a ton of examples of people getting too comfortable, and therefore complacent in their practices, and ultimately paying the price for it.

I agree with Welsh here; social engineering is a very common and viable attack and it's performed millions of times a day. However it makes 0 sense to attribute this to any software in particular, since faked / infected binaries can be made from any open (or closed - think pirated copies of expensive software) source software.

HOWEVER, we are BTC enthusiasts here. I have said it before and will say it again, we are EDGE cases, that 1% of users, whatever you want to call us.
For most people using a wall known and well proven SPV wallet like Electrum is fine.

That's exactly right; however the majority that uses (or should use.. some use exchanges or online wallets  ) SPV wallets, can also just use a Breez, Muun or Phoenix node.

I feel like the initial question has been sufficiently answered, though, hasn't it?