Topic: Flaws in LN (Lightning Network). - page 5. (Read 2054 times)

Serious question though... in what regard does the Byzantine General's problem apply to LN? There's no collective consensus to be achieved, it's just single parties keeping each other in check? Obviously the Byzantine General's problem needs to be solved at the settlement / on-chain level but I don't see what this has to do with two parties maintaining a legitimate channel state?

About "people can tweak their node to not do key handshaking in a certain order" -- that really interests me, got any further reading material on that? To my understanding things like handshake order are usually protocol inherent, with any deviation from the specified order leading to a failed handshake and thus an aborted connection. It may be different with LN of course, so I'm curious about that.

Pretending that anything you say or do is going to derail future development to minimise risks in LN is also a fruitless task.



You think multisig is the same thing as custodial.  Why are you telling others to learn the basic principles of multisig if you haven't managed to do that yet?    

LN does not solve the byzantine generals problem so pretending that things cannot happen in LN is a fruitless task.

to those on the edge ready to hit the reply button with a off-topic insult. take a breath. then use your time more wisely to learn the basic principles of:
byzantine generals problem
LN factories
consensus
multisig


P.S i emboldened the important content.
if your reply directs towards me personally but doesnt address the important content or doesnt talk about LN flaws or mention the above 4 listed concepts,  but does just address the grey stuff or mentions an insult. you have only just wasted your own precious time typing a reply.

I yawn at the typical insult reply when they cant rebut how LN works.
but ill bite...

il let them insult all they want. all it proves is they cant rebut the flaw so resort to insults.
after all no one on this planet has a birth certified name of "franky1" so the insults are aimed at no one.

anyway.

have a nice day

You disagree with just about every improvement anybody have ever suggested for bitcoin, no matter what, no matter who. Your main argument always have been "this won't get enough support, so forget about it" and your secret mission is fighting against any technical debate by accusing people of spreading FUD, ... you are kinda anti-FUD bot in this forum.

Cool down, I said frank not rude.

In your opinion.  And considering that I disagree with just about every "improvement" you've ever suggested for Bitcoin because they're all so poorly conceived, if we're being frank, your opinion isn't worth anything to me.

Except that bitcoin Core has no official roadmap to help with performance and almost every single dev refers you to LN whenever you ask about scaling bitcoin. Let's be "frank" , this community weighs too much on LN and this is not ok.
LN, matured or not, shouldn't be categorized as the ultimate scaling solution for bitcoin.

It doesn't need more "investment".  It just needs time to mature.  And no matter how much you try (in vain) to derail it, it's going to get that time.  When people say that Lightning is a solution, they don't mean right this second and that everyone should use it now.  As usual, you're twisting the narrative to suit your agenda.  



The community DO want this code.  If you recall, we had a whole civil war about this.  It's decided now.  I think what you mean to say is you want the devs to develop the code YOU want them to develop.  That's clearly not happening.  You learn consensus.

---

Except that's not even remotely true.  Merklized Abstract Syntax Trees, Schnorr Signatures and other things are being actively developed right now.  No one has "given up" on anything.

Good news you follow my posts. I write here for the same purpose.

As of LN I'm not decrying it as a "flawed" project. It is very unlikely for LN to be a worthless naive project with obvious flaws, I guess. Anybody could check the list of devs and the amount of time they've spent on it to think otherwise. My problem with LN started from the point when I realized these guys have given up on bitcoin potentials to improve and overcome its scaling issues and they are asking us to put all the eggs we got in LN basket.

And the fact that you frequently decry Lightning has nothing whatsoever to do with your support for franky1?   

But you're not wrong about the "special attention" part.  You both deserve plenty of that.  I'll be watching your posts very closely...

You should be nicer with franky1, he got vision and his post above (that I merited by the way) has an excellent analogy and his general idea about the necessity of consensus and blockchain worth special attention. I admit that he has gone too far in the last paragraph but who cares? Many people do this, kinda dramatic style in finishing a post, not a big deal.

Honestly, I have not checked his post history but as of his recent activities on this forum, I could hardly find such a label, troll, to be just adequate.

Ugh... that's not even a word.  Why does anyone take you seriously?  



Sounds remarkably like Bitcoin itself back in the day.  In fact, even people today are still losing funds because they're sending forked coins to BTC addresses and vice-versa.  You shouldn't move funds into any crypto if you aren't willing to risk a small chance of losing them.  The idea of development is that it gets incrementally better.  And it will.  No one is claiming LN is "perfect" right now, so stop pretending otherwise.

The above is not true, is posted by a known troll, and should be generally ignored. Especially not the part regarding why the developers do not currently recommend the use of LN with a lot of funds (which has to do with software maturity, not any made-up flaws).

sorry to butt in. and i expect usual insults for pointing out flaws
"only happens once both parties have revoked the previous commitment " - incorrect

above poster doesnt realise that the beauty of a blockchain is that rules are set by a communtiy audit that destroy something if it doesnt forfil the community consensus.

LN has no community consensus. users can change their nodes code. and not do something or do something different to others. meaning B can change the rules. and so can A

EG
you think in a network where a man has to put out his hand first and wait for a lady to hold it. thats it, thats the rule and no one can abuse that. you would be wrong
in a public network. that can be true as the community can see if a lady acts firsts, the community can shun her and throw her out the community.

but in a non community audited world the lady can decide to do things differently such as put her hand out first or refuse to put her hand out entirely.
so she can decide and say she will or wont do something unless...
 and thus the man has to decide to obey or close off communication with the lady ...
EG the revocation key. the guy hands his key first. but the lady does not offer her key

nothing on the planet will make the lady forced to hand her key over simply because the guy did

LN does not solve the byzantine generals rule. people can tweak their node to not do key handshaking in a certain order. thus gain an upper hand.

if the guy doesnt like it. all they have is an old state they can transmit but now the lady has the revoke key to that

LN has flaws.
devs know it
they actually warn people to not deposit funds people are willing to lose.
sorry but LN is not perfect and people have lost funds.

it why blockchains exist and every transaction needs community validation. to solve the byzantine generals rule. LN does not solve it

I'm honestly not sure how else I can explain it.  Neither A nor B are cheating in this scenario.  No one needs to "decide" or "judge" anything.  Your premise is flawed because you've made an incorrect assumption about how it works.  

Read this explanation to understand the process involved.  "Agreement" only happens once both parties have revoked the previous commitment state.  One party can't "send an agreement" and then accuse the other party of cheating if they "claim" they haven't got it.  It doesn't work like that.  No one can make "claims" about anything.  It's a binary outcome.  Either both parties have agreed, or they haven't.  If they haven't, that doesn't necessarily mean someone is cheating.  It only means the commitment state doesn't change.

Again, in your example, N is still the current state and neither party can take the other party's coins.  There are no penalties involved, as no one is attempting to spend from a revoked commitment state.  If B hasn't sent A the key to revoke payment from N, there is no N+1.  If Party B has not agreed to N+1, they won't send Party A their key for N.  Party A is therefore unable to agree to N+1 if they don't possess party B's key for N.  N+1 cannot exist unless both parties have revoked N.

What can we expect from a technology that are only a couple of years old and still highly experimental.  I do not know of any "out of the box" solutions with zero flaws. Most technologies has to go through Alpha/Beta testing before it can go live and even after going live, flaws are still found. 

The concept is solid, but the implementation is still a bit messy and complex, but we will eventually get there. Most of the debate is currently between 2cnd layer solutions and Block size scaling and these people will never agree on one solution. 

Come again and again: who or what certifies this both-parts agreement?
A claims he sent his 'agreement' to B. B claims he has not recrived any agreement from A. Who or what will decide who is cheating, A or B?
Nope.
Every transaction (by definition) has to be either commited or rolled back.
But yes, in one-sided transaction this singe side takes full control over transaction integrity.
Which is not the case for two-sided transaction (otherwise you are about to say the Byzantine generals problem is a myth and all the mining stuff is useless and a monkey business).

The OP_SIGHASH_NOINPUT soft fork (i.e. that will make eltoo possible) can be introduced the flag day way, apparently. Satoshi's vision, lol (soft forks in Satoshi's era were done that way, although there were only 1 or 2 of them IIRC). It's not feasible to obstruct if the soft fork is activated that way.

The version 1 Lightning Network does indeed force honest behaviour, as otherwise your funds can be taken by the other party.

It also requires both parties keep track of quite a bit of data, different and private data for each party, so you are ready to penalise your counter-party if they do misbehave.

I am going to be a little cheeky, and say that this may be considered a small 'Flaw'.

I only say this as it is so nicely FIXED in Eltoo. A drop in replacement for the Bi-directional channels in L¹.

You can't really misbehave, as the other party can always claim what is theirs and send you what is yours. Even if you do misbehave that's the worst that can happen. And you don't have to store any specific data each, you both keep a copy of the same final state transaction. Much easier.

I do hope the next soft-fork to enable L² will go smoother than the last..   { crosses fingers.. and toes.. }

There isn't an N+1 unless both parties agree that there is an N+1.  Otherwise N is the current state, regardless of what anyone "claims".  In this example, B can withdraw their funds from N without a penalty.  There's no cheating involved, because no one is trying to spend from an old state.  N is the current state.  

However, it's worth pointing out that B does have a financial incentive to agree to N+1, because it sounds like A wants to send them more BTC.  It's a strange example you're using.  I assume in your example you are positioning A as a malicious actor attempting to trick B to steal their coins?  If so, A won't have much luck with that.

N+1 can only become the current state if A and B both lock N+1 with a new key and have also sent each other the old keys for N to revoke payments from that state.  Once payments have been revoked from N, if either party then attempts to spend from N, that's where a penalty would come into play.

I think the problem you might be having is that you associate the word "transaction" with a one-sided push payment like it works with regular on-chain transactions.  Once you've sent it, it belongs to someone else.  In Lightning, however, a transaction involves the other party effectively approving the transaction.  If you send a payment, it only belongs to the other person once they've accepted the latest state and revoked payments from the old state.



But it's not "trust" keeping people honest, it's "consequence".  Play by the rules or risk losing funds.

Cryptography is the judge and you are the executioner.

Once your counterparty tries to cheat you by trying to enforce a stale state the protocol provides you with everything you need to withdraw both your and your counterparty's coins from your shared multisig address.