Bitcoin Forum
May 02, 2024, 04:10:44 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 [5]  All
  Print  
Author Topic: Criticisms of the Lightning Network  (Read 1395 times)
LoyceV
Legendary
*
Offline Offline

Activity: 3304
Merit: 16583


Thick-Skinned Gang Leader and Golden Feather 2021


View Profile WWW
August 25, 2019, 11:56:54 AM
Merited by Welsh (3)
 #81

This is unpopular opinion, but I believe centralized/federated side-chains/off-chain layers are needed for more efficient Bitcoin "coffee transactions".
I don't think that opinion is as unpopular as you think. As a user, I don't care much how it's done, as long as I can make small transactions at a reasonable (low) fee. The one thing it needs though is being accepted everywhere**. That could happen with companies as big as Visa/Mastercard (they're big enough to create their own side-chain), or many smaller ones (working together kinda like how banks operate). I have high hopes for LN in combination with custodial wallets: the custodian ensures I have enough sending/receiving capacity, and LN ensures it can handle transactions to other custodial wallets. Meanwhile, if you really want to, you can still run your own node or use an on-chain transaction if the amount is higher than what you're willing to trust someone with.

** And with that, I'm back on-topic: there's an increasing number of websites accepting LN, and there are already a few dozen different LN wallets, but most of them are new! I've barely seen any established crypto websites starting to accept Bitcoin Lightning transactions alongside on-chain Bitcoin. I hope the reason for this is the fact that LN is still highly experimental, and existing casinos/exchanges don't want to deal with possible problems.

"Bitcoin: the cutting edge of begging technology." -- Giraffe.BTC
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1714666244
Hero Member
*
Offline Offline

Posts: 1714666244

View Profile Personal Message (Offline)

Ignore
1714666244
Reply with quote  #2

1714666244
Report to moderator
1714666244
Hero Member
*
Offline Offline

Posts: 1714666244

View Profile Personal Message (Offline)

Ignore
1714666244
Reply with quote  #2

1714666244
Report to moderator
1714666244
Hero Member
*
Offline Offline

Posts: 1714666244

View Profile Personal Message (Offline)

Ignore
1714666244
Reply with quote  #2

1714666244
Report to moderator
PrimeNumber7
Copper Member
Legendary
*
Offline Offline

Activity: 1624
Merit: 1899

Amazon Prime Member #7


View Profile
August 25, 2019, 08:34:27 PM
Merited by LoyceV (2), ABCbits (1)
 #82

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.

You are highlighting a flaw in the concept of LN. If one side is due to receive only a small amount of coin upon closing the channel, they may not stand to lose anything by broadcasting an old channel state, and if the old channel state is going to result in the other node loosing a small enough amount of money, they may not broadcast the "penalty" transaction that allows him to receive all of the coin in the channel.

No wallet software is going to make it easy for the user (nor should they) access to old channel states because of how easy it is for the other node to take all the money in the channel, resulting in you loosing money. You would need to look in backups to find old transactions to close the channel in an outdated channel state.

I think you are also misunderstanding how the closing of LN channels occur. When you unilaterally close a LN channel, two transactions must confirm, an intermediary transaction and a final transaction. Say for example if you and I had an open LN channel, I was offline, and you wanted to close the channel. You would broadcast an intermediary transaction that is specific to the channel state. If the intermediary transaction is for an old channel state, it would expose information that would allow me broadcast a "penalty" transaction that allows me to receive all the coin in the channel, and if it is for the current channel state, it would expose useless information. After the intermediary transaction has x number of confirmations, you can broadcast the final transaction that results in coin going to each of us according to the channel state. If I didn't want to wait, I would have the option to broadcast the final transaction before the intermediary transaction has x confirmations -- the two final transactions both result in each of us receiving the same amount of coin, however they are two distinct transactions. If you are broadcasting an intermediary transaction associated with an old channel state, I would have x blocks to get the "penalty" transaction confirmed, including via the use of a CPFP transaction with a very high fee if necessary.

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.
Renting inbound capacity is a cost, and those services typically charge a flat fee attributable to a tx fee, and a percentage of the inbound capacity. This cost reduces the benefit to using LN.

Timelord2067
Legendary
*
Offline Offline

Activity: 3668
Merit: 2217


💲🏎️💨🚓


View Profile
September 05, 2019, 09:45:16 AM
 #83

I'm late to this discussion, but I've been testing the Lightning Network on the recommendation of LoyceV who is trying to garner interest via his Little Lightning Loans thread elsewhere in BCT.

I have Eclair on two mobile devices, and Zap on my PC all have three BTC 0.0011 channels open the first two are random while the third is via nodes in and around Amsterdam in the hope that these would enable transactions to and from Loyce's devices. (yes, before anyone asks, that's nine channels) the only TX I've been able to send or receive on either mobile device is if both are open and I get really, really lucky that channels are found between the two devices.  Zap was able to send a "repayment" to Loyce but hasn't been able to send to either mobile device.  Zap doesn't recognise payment requests from one mobile, but will accept payment requests from the other mobile... even though both devices installed the exact same copy of the apk file for Android Devices.

I have also got running the testnet lightning node for Eclair on both mobile devices and it is also a struggle to find a path even though I've had some 20 channels established on each device. (Unlike the main net, my test net each have ~10 BTC each with channels at the maximum BTC 0.1677721 that the program will allow.  I haven't been able to find a PC test-net lightning node program but could go up to BTC 100+ on a single lightning node if I there were a PC version. (Linux comments can be found here...)

Neither mobile device seems to be able to maintain any connections once the screen saver comes on, so my testnet channels are a never ending series of closed by the other side distractions.

Somewhere along the way I picked up an inbound channel on one mobile device, but TX's across that channel are also rather hit and miss.

LoyceV
Legendary
*
Offline Offline

Activity: 3304
Merit: 16583


Thick-Skinned Gang Leader and Golden Feather 2021


View Profile WWW
September 05, 2019, 10:14:05 AM
 #84

(Linux comments can be found here...)
Lol, wrong link? Tongue

Timelord2067
Legendary
*
Offline Offline

Activity: 3668
Merit: 2217


💲🏎️💨🚓


View Profile
September 05, 2019, 10:42:03 AM
 #85


"NOPE!"

*boom* tish! (trying to discuss Linux with anyone who uses it is like trying to talk to the water cooler expert knowledgable in every subject but in the end knows very little)

RTFM! They say by way of answer...

Carlton Banks
Legendary
*
Offline Offline

Activity: 3430
Merit: 3071



View Profile
September 05, 2019, 11:21:36 AM
 #86

I have Eclair on two mobile devices, and Zap on my PC all have three BTC 0.0011 channels open the first two are random while the third is via nodes in and around Amsterdam in the hope that these would enable transactions to and from Loyce's devices. (yes, before anyone asks, that's nine channels) the only TX I've been able to send or receive on either mobile device is if both are open and I get really, really lucky that channels are found between the two devices.  Zap was able to send a "repayment" to Loyce but hasn't been able to send to either mobile device.  Zap doesn't recognise payment requests from one mobile, but will accept payment requests from the other mobile... even though both devices installed the exact same copy of the apk file for Android Devices.

sounds like the path finding with Eclair and/or Zap isn't working. Either that or you're making some mistake or other. If you look at the Lightning network graph, it's well connected, so there shouldn't be more than maximum 8-12 hops to find the longest route (and the average route length will be lower than that)

Vires in numeris
Timelord2067
Legendary
*
Offline Offline

Activity: 3668
Merit: 2217


💲🏎️💨🚓


View Profile
September 05, 2019, 07:16:39 PM
 #87

sounds like the path finding with Eclair and/or Zap isn't working. Either that or you're making some mistake or other. If you look at the Lightning network graph, it's well connected, so there shouldn't be more than maximum 8-12 hops to find the longest route (and the average route length will be lower than that)

All three aren't working?  What would be the odds of that?

Given that I have made and received payments I'm not sure what mistake you might be thinking I've made.

Failed attempts try ten times and come back with "unable to find path..."

The payments are ~ $1 and are funded for the TX fees.

Carlton Banks
Legendary
*
Offline Offline

Activity: 3430
Merit: 3071



View Profile
September 05, 2019, 09:20:28 PM
 #88

All three aren't working?  What would be the odds of that?

that's why I'm suggesting ACINQ's route finding might be at fault, both Zap and Eclair no doubt share some codebase as both are developed by ACINQ

not sure what you could be doing wrong, I haven't used Zap or Eclair. Maybe you've just opened channels (unluckily?) in a poorly connected part of the network graph?

Vires in numeris
Rath_
aka BitCryptex
Legendary
*
Offline Offline

Activity: 1876
Merit: 3131



View Profile
September 05, 2019, 09:26:45 PM
 #89

that's why I'm suggesting ACINQ's route finding might be at fault, both Zap and Eclair no doubt share some codebase as both are developed by ACINQ

Are you sure about that? I am quite sure that Zap is strictly related to LND (its GitHub seems to prove that too).
Pages: « 1 2 3 4 [5]  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!