The Lightning Network's penalty system in action

[DannyHamilton]

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

Please enlighten me, Sir.

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

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 concept is useless?

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).

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?

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.

[squatter]

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.

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.

[BenRickert]

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 "?

[vit05]

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.

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?

[DevilOper]

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

Please enlighten me, Sir.

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

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 concept is useless?

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).

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.

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.

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?

[BenRickert]

You didn't read the paper did you?

[DannyHamilton]

You didn't read the paper did you?

Clearly he did not.

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

[BenRickert]

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

[spartacusrex]

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

[BenRickert]

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.

[BenRickert]

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

Nevermind.....got it.

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

[Quickseller]

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

[...]
Edit: Confirmed that it was a user that restored corrupted channel database
https://lightningcommunity.slack.com/archives/C6AFCN3KL/p1521915378000006

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.

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

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

[Xynerise]

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. 

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 once the CSV timeout  on the transaction has elapsed.

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

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.

[Anti-Cen]

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.  

[Xynerise]

You have to remember that Bit-Coin has never, ever had any bugs in it despite dozens of updates

Actually Bitcoin has had lots of bugsin the past, but they have always been patched before they caused any significant 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.

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.

[Anti-Cen]

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"

[DannyHamilton]

Penalty system controlled by miners and the development team is not going to work out too well

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.

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

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.

[Anti-Cen]

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.

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.

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.

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 

[DooMAD]

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.

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.

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.

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.

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  

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.

[Quickseller]

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. 

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 once the CSV timeout  on the transaction has elapsed.

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.

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

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.

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.

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.

Agreed.

Back in the day, you had to backup Bitcoin-Qt after every transaction.

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.