Criticisms of the Lightning Network

[Rath_]

Sorry for interrupting your IOU discussion, but the Lightning Network criticism has just been taken to a whole new level. Even franky1 can't beat that.



Source: https://twitter.com/rogerkver/status/1160286347002695680

[Wind_FURY]

Sorry for interrupting your IOU discussion, but the Lightning Network criticism has just been taken to a whole new level. Even franky1 can't beat that.



Source: https://twitter.com/rogerkver/status/1160286347002695680

There's no other reason why Jack Dorsey would endorse Lightning in Roger Ver's alternate-reality.

But I can imagine the franky1 fist pump. Hahaha.

The "IOU comparison" is something difficult for me to agree with, because an IOU is something that acknowledges debt. There are no debts in Lightning.

Can't you say it's an IOU from the channel to both parties involved? Neither of the parties has a debt, but the Lightning channel owes them money.

You are moving further away from the point. There's no debt/IOU in Lightning. Those "values" in the channels are signed transactions by both parties of the channel. They are Bitcoins in a "serialized mempool", waiting to be broadcasted on-chain anytime the user decides.

[PrimeNumber7]

I guess it's biggest drawbacks are:

• The learning curve (pretty steep)

<>

In my experience, actually using LN has been no more difficult/complex than using a light bitcoin client. What happens in the background is much more complex, however as a user, I have no need to understand the backend if I have already made the decision to use LN.

I believe every wallet, lightning or not, should let you decide which fee to use.i would use 1 sat byte to close the channel, and waiting 5 days would be ok to me.

When you close a LN channel, some of the coin belongs to you, and some belongs to the other party to the channel. If the other node does not want to potentially wait days to access their coin, it will not sign a cooperating closing tx with a low fee. If the other node is not cooperating and you want to unilaterally close the channel, you must use a previously signed tx, including whatever fee rate was set.

Regarding criticisms, the need to keep private keys online and regularly monitor channels limits the appeal.

It is possible to keep your keys in a 'warm' wallet not contained on the same computer as your LN node. You can also keep it in cold storage, however you will need to be signing multiple transactions every time you want to spend coin, so this is not ideal.

<>
Blockchain Vs Lightening Network

Privacy:

Without a doubt the lightening network is far superior to the Blockchain when it comes to privacy although despite some of the criticisms with using one address it has no major trade offs for the improved privacy. Basically when you send a transaction via the lightening network there is little worry to it being recorded permanently on the Blockchain and if it were to get recorded it does not display sources or locations of the funds. One of my favorite things about the Blockchain is it uses a sort of onion like encryption method to nodes so that nodes cant monitor addresses and transactions which is a much improved version over any other implementation of nodes interacting with the blockchain that I have seen.
<>

An adversary who is closely monitoring the state of various LN channels can potentially conclude that channel x paid (belonging to node x) 0.xx btc to channel y (belonging to node y),  could conclude that channel y belongs to bitrefill for example, and could use blockchain analysis to conclude that channel x belongs to you. The adversary could conclude this because exactly one channel belonging to your node had its outbound capacity decline by 0.xx btc at approximately the same time several other nodes had exactly one channel both decrease and increase outbound capacity by 0.xx btc, and node y had exactly one channel decrease its outbound capacity by 0.xx btc. The adversary would need to be watching the LN network in real time, and must take very frequent snapshots of the various states of channels; without these snapshots, the adversary will not be able to make these conclusions.

I'm still waiting for the people who keep insisting that "Bitcoins in Lightning are IOUs". They're not posting so far, I believe maybe they have given up on that propaganda.

Merriam Webster defines an IOU as something that 'is given as an acknowledgement of debt'

If you open a LN channel with inbound capacity, and receive a transaction, when the channel closes, you will receive an on-chain tx for the amount of the transaction plus the amount you funded the channel with (less any payments you sent). For this reason, I understand why some people may believe that LN channels are IOUs, however if you were to stipulate they are IOUs, you must also state that it operates very differently than traditional debt.

With a LN channel, you always have a signed transaction enabling you to receive the full amount you are "owed" at any time, and there are safeguards in place to prevent the other party from taking any of the amount you are "owed".

The term "debt" implies there is a chance you may not receive what you are due, but with LN, this is simply not the case.


My biggest concern about LN is the inability to find a node to open a channel with who will provide capacity for you to receive a payment. In order to receive a payment via LN, you must have an open channel with capacity to receive the amount of the payment; this means you must have either already spend a similar amount on other LN payments, or someone else has opened a channel with you and funded the channel with their own money in amount at least that of the payment. Today, there are several services that charge a few percent of the inbound capacity they provide, but this is not ideal unless you will be both receiving and spending many transactions on that channel.

[bitmover]

I believe every wallet, lightning or not, should let you decide which fee to use.i would use 1 sat byte to close the channel, and waiting 5 days would be ok to me.

When you close a LN channel, some of the coin belongs to you, and some belongs to the other party to the channel. If the other node does not want to potentially wait days to access their coin, it will not sign a cooperating closing tx with a low fee. If the other node is not cooperating and you want to unilaterally close the channel, you must use a previously signed tx, including whatever fee rate was set.

I understand what you said, but that wasn't the case. The other party of the channel wasn't in hurry, it was loycev.
It really was a lack of transparency and fee control. Eclair wallet is a good wallet for testing, but it has many problems, and fee customization is one of them.

There was no way to customize the fees and choose how many sat/byte I would like to pay.

[LoyceV]

When you close a LN channel, some of the coin belongs to you, and some belongs to the other party to the channel. If the other node does not want to potentially wait days to access their coin, it will not sign a cooperating closing tx with a low fee. If the other node is not cooperating and you want to unilaterally close the channel, you must use a previously signed tx, including whatever fee rate was set.

I'd like to see older channel states but Eclair doesn't show them. I guess I'll have to dig into the backups made on Google Drive for those?
As a proof of concept, it would be interesting to see if I could actually use an older transaction to steal funds (and if I succeed give them back to the node, but that's not the point here). I currently have a channel (opened by me) with only just over 3000 satoshi on my side. If I'm the only one paying for fees, I don't expect any of this money back in my wallet. But even all of it is used as fee, it won't be a high fee. So: what if I wait until fees go up, then close the channel, which won't confirm, and after the right amount of time, I broadcast an older state (which at the time might have been signed with a higher fee)?

It's still a mystery to me how the older signed transactions would work, given the fact they can't be broadcasted instantly but only a certain amount of time after trying to close the channel.

I understand what you said, but that wasn't the case. The other party of the channel wasn't in hurry, it was loycev.
It really was a lack of transparency and fee control. Eclair wallet is a good wallet for testing, but it has many problems, and fee customization is one of them.

You're mistaken though You made a LN transaction with me, but you didn't have a direct LN channel to me. I don't even run a node! I was using a light wallet, just like you, and you opened/closed the channel with another node.

[There was no way to customize the fees and choose how many sat/byte I would like to pay.

It might help to wait until fees are low for a while, then close the channel. I would expect a lower fee that way (but haven't tested it yet).

[Carlton Banks]

It's still a mystery to me how the older signed transactions would work, given the fact they can't be broadcasted instantly but only a certain amount of time after trying to close the channel.

every state is a channel close transaction, that was negotiated, but not broadcast. the blockchain doesn't know that other more recent states exist, so it's as valid as any other.

that's the point of going off-chain when you think about it; the blockchain only needs to know aggregations of every little transaction together as 1 larger transaction, not every detail of every little transaction.

[Wind_FURY]

The "IOU comparison" is something difficult for me to agree with, because an IOU is something that acknowledges debt. There are no debts in Lightning.

Can't you say it's an IOU from the channel to both parties involved? Neither of the parties has a debt, but the Lightning channel owes them money.

you could, but unlike an IOU, the debtor cannot stiff the creditor. As I say, that is where the comparisons end

and I reiterate, saying "Lightning is an IOU" is a psychological tactic, designed to make people think they're trusting money put into Lighting channels can be returned to the on-chain. That's not what's happening. You can control whether your money is returned, providing that you understand how to do so.

Am I wrong in this?

no

channels are like IOUs, but they are not IOUs. Manipulating subtle differences in the meaning of words, or exaggerating something are typical tactics of someone trying to twist reality.

Class Dismissed.  
                  

That's still an F, in spite of the effort. Try harder newbie.

I'm still waiting for the people who keep insisting that "Bitcoins in Lightning are IOUs". They're not posting so far, I believe maybe they have given up on that propaganda.

Merriam Webster defines an IOU as something that 'is given as an acknowledgement of debt'

If you open a LN channel with inbound capacity, and receive a transaction, when the channel closes, you will receive an on-chain tx for the amount of the transaction plus the amount you funded the channel with (less any payments you sent). For this reason, I understand why some people may believe that LN channels are IOUs, however if you were to stipulate they are IOUs, you must also state that it operates very differently than traditional debt.

With a LN channel, you always have a signed transaction enabling you to receive the full amount you are "owed" at any time, and there are safeguards in place to prevent the other party from taking any of the amount you are "owed".

The term "debt" implies there is a chance you may not receive what you are due, but with LN, this is simply not the case.

Yes! LN is, in some sense, more like a "serialized mempool" - credit to Bitrefill's CCO.

My biggest concern about LN is the inability to find a node to open a channel with who will provide capacity for you to receive a payment. In order to receive a payment via LN, you must have an open channel with capacity to receive the amount of the payment; this means you must have either already spend a similar amount on other LN payments, or someone else has opened a channel with you and funded the channel with their own money in amount at least that of the payment. Today, there are several services that charge a few percent of the inbound capacity they provide, but this is not ideal unless you will be both receiving and spending many transactions on that channel.

I already said this before, I believe Lightning might be better adopting a hub and spoke model for efficiency. My opinion, I might be wrong.

[konfuzius5278]

For me several problems came up:

1) Its really complicated to use at the moment. Installation very hard, first fund then open channel, do the tx itself.
Need to be integraded in a standart bitcoin full node to use

2) Creating inbound channel even harder

3) Because of the upper parts very less people use so it will take years to establish

4) I dont see any advantage agains Masternode of DASH working for years

[Rath_]

2) Creating inbound channel even harder

It's not as difficult as you think. Some nodes automatically open a channel back if one opens a big enough channel to them. There are also services from which you cant rent the inbound capacity.

1) Its really complicated to use at the moment. Installation very hard, first fund then open channel, do the tx itself.

Mobile wallets are fairly easy to use, but there is still a lot of room for improvement. Eclair Mobile and BlueWallet (a custodial wallet) seem to be the best choices for now. The latter might be a bit more intuitive.

[Wind_FURY]

Khoas17 stop eating your crayons. You want real criticism of the Lightning Network? Use this, not your "Lightning is an IOU" narrative. Tell franky1 about it too.

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

It sounds counterintuitive but quite a lot of the development work in LN is designed to make the Network capacity go down. More efficient use of channels, more private channels, these are improvements that drive down the apparent size, actually delivering more and better capacity

Higher capacity is not a gauge for LN's development? Please, no Bait-and-Switch.

[franky1]

hres a game for people.
imagine a LN channel is a necklace of loose beads. the beads on the necklace are like an abacus that show who deserves what

EG if A had 3 and B had 1 it would look like: A ooo----o B
EG if A had 4 and B had 2 it would look like: A oooo--oo B
EG if A had 1 and B had 3 it would look like: A o-----ooo B

if you understand that. now look at this image and work out, if alice has 7 coins total, how much can frank receive from alice

[LoyceV]

if you understand that. now look at this image and work out, if alice has 7 coins total, how much can frank receive from alice

Frank can receive 2 coins from Alice: 1 via Carol and Ella, and 1 via Bob and David. However, I don't think LN supports splitting a transaction over multiple channels, so Alice can send 2 transactions (with 1 coin each).

This nicely illustrates the imporance of channel balancing, and well-connected nodes.

[Rath_]

Frank can receive 2 coins from Alice: 1 via Carol and Ella, and 1 via Bob and David. However, I don't think LN supports splitting a transaction over multiple channels [...]

These are not the only possibilities. If there is a cheaper but longer route then it might be chosen. Let's assume that Bob updated his channel fee policy with Alice and want to rip her off and let's do the same in the second case with Carol. Alice could send her coins via Carol, Bob and David, and via Bob, Carol and Ella. Alice would have to send to separate payments as you said.

[franky1]

Frank can receive 2 coins from Alice: 1 via Carol and Ella, and 1 via Bob and David. However, I don't think LN supports splitting a transaction over multiple channels [...]

These are not the only possibilities. If there is a cheaper but longer route then it might be chosen.

sorry but the illustration is the illustration.. there are no other routes
trying to fake out a 3rd imaginary channel from alice to pretend there is another way wont work. there are only 2 channels from alice

whats also concerning is when alice moves funds around. those in the middle of the route get affected where they can no longer pay a certain peer.

but imagine it this way.
imagine paypal said you can spend your dollars. but expect to split it up into 3-5 accounts and then not be able to spend all the funds. oh and its locked for a month. so you cant move it out to create new account, but have to us more fresh money to make new accounts.. would you consider that a good system

[LoyceV]

whats also concerning is when alice moves funds around. those in the middle of the route get affected where they can no longer pay a certain peer.

Maybe. Or maybe it changes so that they can pay the one user they want to pay. This can go both ways, but ultimately it's up to the nodes to set a fee that makes it worth balancing their channels. I'm not sure if it's possible already, but I can imagine nodes adjust fees based on their current channel balance.
I agree though: this is a problem. Several of my transactions couldn't be sent because of this. But for an experimental network, I don't mind, and I have high hopes this will become better once LN matures.

but imagine it this way.
imagine paypal said you can spend your dollars. but expect to split it up into 3-5 accounts and then not be able to spend all the funds. oh and its locked for a month. so you cant move it out to create new account, but have to us more fresh money to make new accounts.. would you consider that a good system

Your example is irrelevant: if someone wants to use Paypal (and pay a large part of the total amount in fees), they're free to do so. Besides, I've read many stories about funds being locked in Paypal. I'd rather not be at their mercy.

[franky1]

whats also concerning is when alice moves funds around. those in the middle of the route get affected where they can no longer pay a certain peer.

Maybe. Or maybe it changes so that they can pay the one user they want to pay. This can go both ways, but ultimately it's up to the nodes to set a fee that makes it worth balancing their channels. I'm not sure if it's possible already, but I can imagine nodes adjust fees based on their current channel balance.
I agree though: this is a problem. Several of my transactions couldn't be sent because of this. But for an experimental network, I don't mind, and I have high hopes this will become better once LN matures.

but imagine it this way.
imagine paypal said you can spend your dollars. but expect to split it up into 3-5 accounts and then not be able to spend all the funds. oh and its locked for a month. so you cant move it out to create new account, but have to us more fresh money to make new accounts.. would you consider that a good system

Your example is irrelevant: if someone wants to use Paypal (and pay a large part of the total amount in fees), they're free to do so. Besides, I've read many stories about funds being locked in Paypal. I'd rather not be at their mercy.

to do with paypal example.. WTF you talking about 'fees'.. my example had nothing to do with fee's it was just about physical ability to send a payment.

imagine you were alice and had $70(7 beads in total).. get told you need to split it up to get a chance to spend it. then get told your not going to be able to spend it all (only send frank $20). and then told that others can route through you messing up your channel balance

but if you want to talk about fee's. here goes
if people start raising fee's to scare people from routing via them, guess what.. there will be less routes. less chance of a successful payment

the liquidity issue is a major thing.
nothing to do with fee's alone. but separately the fee scare makes routing even harder

[LoyceV]

to do with paypal example.. WTF you talking about 'fees'.. my example had nothing to do with fee's it was just about physical ability to send a payment.

I think you've missed my point: Paypal is a centralized (private) organisation that offers a product. LN is built by many individual entities who all run their own system. If you want to compare Paypal with anything, it should be a centralized exchange/casino/website that allows user Alice to send/tip funds to user Frank.

Alice can of couse just open a direct LN channel with Frank, that solves all her problems.

[franky1]

Alice can of couse just open a direct LN channel with Frank, that solves all her problems.

alice only has $70,, and those are locked to carol and bob,,,, thus nothing spare to open with frank in LN
imagine it. trying to make a payment and you get a message "sorry cant mak payment please deposit more"
would you call that a good payment system

the example illustration is just a network of 6 nodes. imagine a million nodes, but where users only have 3-5 channels each.
if you run the scenario you will see each extra node routr you have to hop through makes the chances of success worse

by the way if alice did find more funds to deposit. theres still no guarantee alice can pay the full amount to frank as another node might route through alice to pay frank.

imagine it alice makes a alice-frank channel.. but then carol does a carol-alice-frank for upto 3 coins spending all of alices coins

also do you really want to stay awake 24/7 to ensure bob or carol or their counterparts dont route through you. do you then want to hand control to a watchtower(paypal2.0) which can authorise/decline payments while you sleep

its stuff like this that makes me call LN a independant network service for multiple cryptocurrncies including btc
and not
bitcoin layer 2
LN tarnishes the security and trust that btc had for years so i avoid trying to pretend LN is a bitcoin thing

[Rath_]

also do you really want to stay awake 24/7 to ensure bob or carol or their counterparts dont route through you. do you then want to hand control to a watchtower(paypal2.0) which can authorise/decline payments while you sleep

If you don't want to route any payments at all then you can either fund a private channel or discourage others by changing your fee policy. The fee policy can be modified for each channel separately.

[Wind_FURY]

Frank can receive 2 coins from Alice: 1 via Carol and Ella, and 1 via Bob and David. However, I don't think LN supports splitting a transaction over multiple channels [...]

These are not the only possibilities. If there is a cheaper but longer route then it might be chosen.

sorry but the illustration is the illustration.. there are no other routes
trying to fake out a 3rd imaginary channel from alice to pretend there is another way wont work. there are only 2 channels from alice

whats also concerning is when alice moves funds around. those in the middle of the route get affected where they can no longer pay a certain peer.

The illustration is the illustration yes, but couldn't Alice open a channel directly to Frank and send the payment?

but imagine it this way.
imagine paypal said you can spend your dollars. but expect to split it up into 3-5 accounts and then not be able to spend all the funds. oh and its locked for a month. so you cant move it out to create new account, but have to us more fresh money to make new accounts.. would you consider that a good system

This is unpopular opinion, but I believe centralized/federated side-chains/off-chain layers are needed for more efficient Bitcoin "coffee transactions".

But I would not discourage the "LN experiment" either.