Pages:
Author

Topic: The Lightning Network's penalty system in action (Read 775 times)

sr. member
Activity: 322
Merit: 363
39twH4PSYgDSzU7sLnRoDfthR6gWYrrPoD
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.
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 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.


Quote
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.
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 after a user lost a large amount of bitcoins 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.
member
Activity: 210
Merit: 26
High fees = low BTC price
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.

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.
jr. member
Activity: 35
Merit: 1
I think this is one of the reasons why the spamming of the legacy/SegWit Blockchain was put on hold, too.  Angry
copper member
Activity: 2996
Merit: 2374
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.

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.
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.
member
Activity: 210
Merit: 26
High fees = low BTC price
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.

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 

 
copper member
Activity: 2996
Merit: 2374
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.

Quote from: QS
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.
legendary
Activity: 3948
Merit: 3191
Leave no FUD unchallenged
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.   Roll Eyes

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  Cheesy

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.
member
Activity: 210
Merit: 26
High fees = low BTC price
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.

Quote
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  Cheesy
legendary
Activity: 3472
Merit: 4801
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.
member
Activity: 210
Merit: 26
High fees = low BTC price
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"
sr. member
Activity: 322
Merit: 363
39twH4PSYgDSzU7sLnRoDfthR6gWYrrPoD
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.

Quote
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.
member
Activity: 210
Merit: 26
High fees = low BTC price
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.  
sr. member
Activity: 322
Merit: 363
39twH4PSYgDSzU7sLnRoDfthR6gWYrrPoD
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.
Quote
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.
copper member
Activity: 2996
Merit: 2374
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..  Smiley
I think this incident is a good example of why this is not a good idea.
full member
Activity: 420
Merit: 110
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..  Smiley
Nevermind.....got it.

https://bitcointalksearch.org/topic/how-to-run-a-lightning-node-2726073
full member
Activity: 420
Merit: 110
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..  Smiley
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.
hero member
Activity: 718
Merit: 545
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..  Smiley
full member
Activity: 420
Merit: 110
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....
legendary
Activity: 3472
Merit: 4801
You didn't read the paper did you?

Clearly he did not.

You can lead a horse to water, but . . .
full member
Activity: 420
Merit: 110
You didn't read the paper did you?
Pages:
Jump to: