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

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?

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?

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

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

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

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?

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

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.

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?

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.  

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.

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.

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.

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

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?

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 that detect this fraudulent behaviour and notify the other participant.

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?

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.

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