Bitcoin Forum

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



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!

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^

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 (https://www.reddit.com/r/Bitcoin/comments/875avi/comment/dwam07f)

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

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. (https://t.co/yeGoisrkYJ?amp=1) (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.

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.

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

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  (https://www.coindesk.com/laolu-building-watchtower-fight-bitcoin-lightning-fraud/) that detect this fraudulent behaviour and notify the other participant.

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?

It's actually straight forward.
The be00.... is the LN channel ID
The first line shows that 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.


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.

It  already confirmed (https://btc.com/a1e96ee5dd93bcf1e6b3359e5a82fa17f52901110be090db24f9812414fccb2f) Lightning Network transactions are still bitcoin transactions.

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.

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.

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?


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.

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.

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> 

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?

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.


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.


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.

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?

Please enlighten me, Sir.
Are you going to say the entire PoS PoW concept (in order to solve BGP) is useless?
Who or what guarantees the revocation key is really revocation key?

Edit: typo

I attempted to, but it looks like you need a lot more information than I have time to write in this thread right now.

I suggest you start by reading through the following paper:
https://lightning.network/lightning-network-paper.pdf


???

What are you talking about?  I'm not aware of any Proof of Stake in Lightning Network, and I'm certain that bitcoin uses Proof of Work (not Proof of Stake).


The scripts and the process that are used for building the current state. Take a look at the Lightning Network link I provided.  Let me know if there is anything specific in there that you don't understand.

In reality, though, there are security trade-offs. The security model of LN is very different than Bitcoin.

Speaking of value, high-value transactions probably necessitate on-chain transactions which leverage offline storage. Updating channel states means keeping your keys online. That's a big no-no for any meaningful amount of money.

I suggest you start by reading through the following paper:
https://lightning.network/lightning-network-paper.pdf


This is extremely exciting. An absolute must read. What is the common consensus on when Lightning Network can be implemented? Time wise? I know it's a guess but this is easily the most important BTC development since it's inception. Any " educated guesses "?

But the user was totally stupid? Or was it a simple mistake that could probably occur thousands of times? I think it's pretty clear that the backup system needs to improve. And improve greatly to the extent that it can be used massively by ordinary users.

Is it possible to prevent the user, perhaps even prohibit, from closing a channel when it is out of sync?

So now it is clear that your self-pumped-importance does not make you understanding any better thet those you claim to do not understand since you always have a time to make this narcissistic statement but cannot ELI5.
PoS was certainly a typo.


Are we still talking about cheater or honest user? What prevents cheater from modifying his script/process/whatever? Otherwise what the purpose is to penalize the honestly mistaking user?

You didn't read the paper did you?

Clearly he did not.

You can lead a horse to water, but . . .

Either way....best of luck with this. This is seriously the most important thing to happen to this protocol since it's inception. I have no programming or coding experience. Just a medium scale miner. I would love to hear any suggestions on how I could help, support and or further LND from my side of the desk....

Run a Lightning Node..  :)

That actually sounds very intriguing. Nothing too exciting going on in mining these days. If you have any suggestions on where and how to start I'd appreciate that. Either here or PM? Thank you in advance.

Nevermind.....got it.

https://bitcointalk.org/index.php?topic=2726073.0

If this is true, which is appears to be, then this is a pretty serious problem with LN. To me, this would indicate that hardware failing, or a DB getting corrupted would essentially mean that all money within all open LN channels will be lost, as you cannot backup a LN wallet until after the fact, unlike with most wallet implementations in which you can backup private keys prior to receiving funds. 

Sure, you might argue LN worked exactly as designed, however I would say the design is flawed.


I think this incident is a good example of why this is not a good idea.

While it's true that channel states are obviously not deterministic and thus can't be backed up once via a mnemonic seed phrase like bitcoin private keys, the funds in the channel aren't irrevocably lost; the user can always close the channel unilaterally  (https://github.com/lightningnetwork/lightning-rfc/blob/master/05-onchain.md#unilateral-close-handling-local-commitment-transaction) once the CSV timeout  on the transaction has elapsed.
The design of the protocol isn't flawed; broadcasting stale channel states should be punishable or else nothing stops a peer from trying to cheat by broadcasting old channel states.
What ever caused the peer to broadcast an old channel state, be it dishonesty or error, is not the problem of the protocol.
If a user sends bitcoins to an address and the transaction is confirmed it is irreversible. It doesn't matter if the transaction was sent to the wrong address, or the wrong amount.

There should be a better way of storing/preserving old channel states that survives a hard disk crash or similar.
That design could be improved, but then again, Rome wasn't built in a day.
Back in the day, you had to backup Bitcoin-Qt after every transaction.

I hope and believe LN will get there.

You have to remember that Bit-Coin has never, ever had any bugs in it despite dozens of updates
if you blame any loss of money on hackers or someone else and it's so good that when things go
wrong you don't even need anyone else to call to report the problem.

Penalty system controlled by miners and the development team is not going to work out too well
IMHO for joe public and will be like the old pledge about "Virtually free transactions fees" we saw as fees
hit $55.00 just to store 250 bytes of data.

This is what killed BTC, not waffle coming out about what China or Korea might or might not do
and I certainly won't be trusting any off-block single point of failure network that Lightning has
brought to the Bitcoin network even if the Exodus wallets adds the facility in a years time.  

Actually Bitcoin has had lots of bugs (https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures)in the past, but they have always been patched before they caused any significant problem.

The penalty system is not "controlled by miners and the development team"
You do not even know how it works or want to  learn how it works.
Either you're a persistent troll or an idiot with double-digit IQ.
Either way, you should really stop shitposting.

Strange since it is me that keeps giving out the url here for the lightning network white paper
so maybe you missed it https://lightning.network/lightning-network-paper.pdf and I also keep
giving out the url for the current LN map https://lnmainnet.gaben.win/

You sound a little confused to me, trolls today are ten a penny and your in the wrong forum
if you are looking for one of them signature troll campaigns to sign up with Mr "yahoo62278 CAMPAIGN MANAGER"

That's a great link.  Have you actually read the material there?  Posing a link isn't going to help you understand if you don't read the contents.

Please point out where in the linked information it says anything about the penalty system being "controlled by miners and development team"? I can't seem to find it.

That's a nice assumption to make Danny, shame it's wrong and if you do a word search for the word "Fee" in the document then like me you
will know by now that the term is used 45 times.


I believe you are correct, lots not covered in the document and much has been made up as they are going along but if you care to take a look
at the network map here https://lnmainnet.gaben.win/ then it becomes obvious that Alice and Bob are not running the banker hubs because they
don't have the BTC or the hardware to run these nodes so it's a fair assumption to assume that miners are running the lightning banking nodes
which i am sure can be checked by your good self if you care to trace the ip-addresses.
 
You don't become a highly paid software contractor without learning to read and understand technical specification if that answers your other
cheap dig my friend  :D

There's a crucial distinction between "having a cursory glance and jumping to your own conclusions" versus "thoroughly reading, absorbing and comprehending the material".  A search for the word "Fee" in your post history yields a usage far greater than 45 times.  What completely flawed inference should we be drawing from that?  Because that's precisely what you're doing.

This is the Technical Discussion board, not the "I can just about count to 45" board.  Either make an actual, valid point, or post in the Beginners & Help sections until you're ready to handle Lightning.

Anyone that just about qualifies as sentient can use the search bar, type in a word and see how many times it appears in the document.  What would be quite refreshing is if you perhaps tried to advance your understanding beyond that rudimentary stage.  See, there's this wonderful thing called "context", which always seems to be severely lacking in every single post you've ever made about Lightning.  We'd love to take you seriously, but that's simply not going to happen until your comprehension and reasoning improves significantly.



Talks about the dangers of making assumptions in one breath and then makes an even bigger one in the next.   ::)

What would make more sense is that many users may have a channel open to the same merchant or retailer.  Such is the nature of capitalism and consumerism.  We tend to shop at businesses more than we do privately.  Hence lots of people connected to the same nodes.  Also how about you trace the ip addresses if you're the one making the blind accusations?  There's nothing other than your innate paranoia to suggest that all the larger "hubs" are run by miners.  I've personally never bought or sold something from a miner (that I know of, anyway), so I can't envision a situation where I would have a channel open with one.  Under what scenarios do you envision people have opened a channel directly with miners?  Not that I'm expecting an actual coherent and reasonable answer from you or anything.  Hey, how about another reply whining about me insulting you?  Never get tired of hearing that one.



The funniest part is that I don't doubt you do genuinely believe you've understood it.  The problem is, we've yet to witness a single thing you've said yet that indicates you actually do understand it.  We're literally sat here waiting to be proven wrong.  Show us you understand it.  Demonstrate the knowledge you claim to have.  Say something that actually makes an ounce of sense.  Just once.  Please.

Unless I am missing something, I don't think that is right. Consider this scenario:

"A" and "B" open a channel and engage in several transactions. If immidiately after the most recent transaction, "transaction n", "B" losses all data associated with his LN wallet, and was unable to backup his data after "transaction n", then he will have insufficient information available to close the channel without risking all of his funds (with near certainty of loss). Remember that "B" does not have the current state of the channel.

If "B" tries to close the channel, he must do so using an old state, and attempting to use this would result in "A" being able to claim all funds in the channel.

I agree it is necessary to give incentives not to "cheat" within the protocol, however as it stands now, there will be too many false positives, and displaying these false positives is unavoidable every so often.

Sure, if you do things like leave cash on the ground on the street, or send bitcoin to an incorrect address, that money is gone forever, however there are things users can do in order to protect against this, including things like the checksum in Bitcoin addresses.

Agreed.

I don't think this is right. My understanding is that Bitcoin Core/QT would pre-generate 100 addresses in advance, so you could backup your wallet and the backup would contain the next 100 addresses you would receive bitcoin to.

Surly "A" could only claim on the balance that he holds the key for on the transaction state of the ledger and not just take the lot.

General users just won't understand the system but their voices will be herd if more than a few start to cry fowl so again Bitcoin
has solved one problem by introducing two more not that i am saying your understand is wrong or anything.

Miners running these banking hubs can and will be taken down by white-hats if they try any of that bushiness 

 

No, "A" would be able to obtain the entire balance held in the channel as part of the penalty for trying to "cheat".

In theory, the LN protocol could be changed so that "A" could only claim what he is due, plus a penalty percentage, but this would still not be ideal because "B" would be loosing money because of something outside of his control, and due to something he cannot prevent.

I think this is one of the reasons why the spamming of the legacy/SegWit Blockchain was put on hold, too.  >:(

it's a hard one I guess and what if man-in-the-middle hackers fool a wallet into sending an out of date
transaction given that no one can pick up the phone to plea their case when coins do go missing.

It seems I misunderstood your previous post.
The Lightning Network nodes are local and not on the blockchain so you can't restore backups deterministically. So without a backup you're SOL.
However in the future you could outsource the watching of commitment transactions to a  Watchtower  (https://github.com/mit-dci/lit/blob/master/watchtower/README.md) so if your peer tries to cheat you even if you're offline or lose your backup, then the Watchtower could post the penalty transaction on your behalf and take a cut of it as fees.
It's still very nascent at this stage though.


Actually in the past, before version 0.3.13.3, there was no keeypool feature and users had to backup after EVERY transaction.
The Keypool feature was introduced in version 0.3.13.3 by Satoshi (https://bitcointalk.org/index.php?topic=1414.0) after a user lost a large amount of bitcoins (https://bitcointalk.org/index.php?topic=782.5) because he didn't backup after his last transaction so he didn't have access to the private key of his change address.

---

In hindsight, using Keypool, HD,  and mnemonics seem obvious to us. It wasn't obvious then.
On the future when LN has drastically improved, the improvements would seem obvious I'm hindsight too.