Bitcoin Forum

Mostly here and especially on r/Bitcoin, I've been seeing mostly, around 95%, positivity when it comes to the lightning network.

I'm just curious. For a change, let us look at the negatives. What are your criticisms concerning the Lightning Network? Do you think it's likely to succeed?

Personally, I think it's likely to succeed, though I think it will take a lot longer than people are expecting. I think it's going to be difficult for the developers to make LN easy enough to use for the end users, to the point that they couldn't even differentiate if they're using LN or just normal transactions.

I guess it's biggest drawbacks are:

• The learning curve (pretty steep)
• The software: most of it is still in alpha or beta phase... This doesn't show a lot of trust from the dev side (at the moment)
• Not enough open channels to relay all payments effectively

I've been running a site that accepts LN for a rather long time now, and so far everything works fine... But then last week i tried to get payed by a person i personally see as technically competent, and so far i haven't been able to get him to the point where he can succesfully make a LN payment.

I believe what might be a "weakness" in Lightning is that users will need to stake their Bitcoin to provide liquidity in LN, therefore removing liquidity outside LN.

Plus I also believe that fees in Lightning will not be "unfairly cheap" at some point. It will be higher than altcoins.

Precisely. Bitcoin in itself is quite complicated enough for the typical non computer literate person. LN is going to be a lot harder to use for them. Hence my point of the challenge here is mostly on the user experience category.

I used lightning network once, and I have some critics about it.

The fees to topen/close channels were higher than I expected, and they were also not transparent.
I set a low fee (like 3 sat byte) but later on when closing the channel I was charged high fees, and I don't know where they came from. I couldn't set them also.
I was using Éclair wallet and had no problems with the software (ui seed etc, all fine)

It's Eclair's fault. I am not sure about c-lightning, but LND allows users to set the closing transaction fee through --sat_per_byte parameter (https://api.lightning.community/#closechannel). Even if the implementation supports a certain feature, clients also have to implement it. What was the recommended transaction fee at the time? @LoyceV pointed out that Eclair Mobile overcharges for the closing transaction depending on the mempool state.

This is something that needs to be improved before they roll out of the Beta phase. User interface, and general usability should be streamlined so even the average computer user can use the software, otherwise its just going to get a bad reputation for being only useful for those that are technically competent. The concept of the lightning network is an interesting one, and its by no means a perfect system, however its probably the most interesting development at the time being.

The lack of open channels will hopefully become more redundant as time passes, and more users are using the lightening network. This I wouldn't be too concerned about considering the early developments of the lightning network.

the "chicken & egg" problem


New users to Bitcoin cannot directly receive Lightning payments to get involved, they must first buy BTC, then open a channel. Only then can they receive (or send) over Lightning.

Solutions

• the "Statechains" concept can apparently solve this problem, but comes with it's own compromises
• negotiate a channel opening, buy BTC from a seller that sends to you to settle the deal, send the BTC to the channel opening address to establish the channel

so really the solutions are not ideal, and Statechains depend on eltoo. Needs a better solution.

I think its lacking ease of use is LN's largest detriment. Even on-chain payments still seem like rocket science to many people, despite having come a long way from just a few years back.

I'm fairly positive though that we'll get there eventually, just like wallet software improved over the years. With more and more users getting familiar with cryptocurrencies and LN ease of use improving we'll end up somewhere viable sooner or later. We still have a long way to go though.

Once we're there though -- which is probably still years from now, so the developer community will need a long breath -- liquidity, routing, etc likely won't be a problem anymore.

I have a c-lightning node, and i quickly looked up the man...

It does look that, without editing c-lightning sourcecode, you cannot set the fee for the onchain closing transaction... I never even tought about this problem, i very seldomly close a channel, and when i do, i have never tought about changing the fee...

The fees were high at the time (like 40 sat).
But I opened the channel with very low fee. I didn't thought that eclair would just use a "recommended fee" (I hate this idea) to close it. It costed me about 0.0004 BTC to close it.

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.

While I am personally yet to use LN myself, for any purpose, but the fact that it almost went viral on twitter and was wildly talked about was pretty rad. People were having fun with just like they were having fun with btc transactions back in 2016-17, people were transacting just for fun and that caught on.

The learning curve will get easier once this grows beyond the immediate geek-squad niche and move into more of a commercial side of things.


This can be a problem. I know for a fact about one gal that custom set the fees on her greenaddress wallet and waited like a week to see her transaction get the first confirmation. Something like that can happen on the LN too.

I think there should be a noob friend, fire and forget kinda solution for LN.

I reckon 99% of that 95% have never used a lightning network. They're positive about it because it's something to deflect present criticisms without having to put any thought into it.  

I sampled a testnet wallet before it went live. I couldn't get it to work. It's an extra layer of noodling that I quickly abandoned. It may be way better now but I'm in no hurry to return to it.

If people believe Bitcoin itself needs UX work, that's nothing compared what LNs need. BTC feels rather more fire and forget.

As long as you use a custodial service like bluwallet (ios), using LN is pretty easy but custodial services has always been easy to use anyway.

It is a bit pain if you want full control of your funds and for that you need to own your own node and this is where the fun (some might call it pain) starts.

Which is why I said


People will gravitate mostly towards the easy solutions no matter how hard we beat our drums about privacy and controlling your own funds as opposed to someone else controlling them.
And I think this would be beneficial for the adoption of the tech. The easier the tech, the faster the adoption.

Bluewallet is the only thing that made me use LN for the first and probably the last time. It's so hard to fire it up on your own knowing the technicalities involved to just make it work. Perhaps I'm not that technically competent when it comes to these things but seeing you guys having the same problem as I do somehow makes me feel better (lol). It's a great solution to reduce the load on the main network, don't get me wrong, but with the technicalities involved in getting it right the first time just to send pennies/a few dollars is definitely not worth the effort and the time--unless of course you use a custodial wallet/service that does the messy stuff for you.

Perhaps you should give Wallet of Satoshi (https://www.walletofsatoshi.com/) a shot. Their tagline says it's so easy that even your mom could use it. And most importantly it is fully custodial.

This is developed by the same people behind RoomofSatoshi.

Look em up.

It's not a matter of being noob friendly or not. There was no option to set fees for closing channels. There was only one option to close friendly or unfriendly (something like that, dispute or not dispute, don't remember). I choose the one with lower fees , but even so fees were not customizable.

O believe every wallet should let users customize their fees, on sat/byte.
Because this would really lead to lower fees in general, everyone would look for lower fees unless absolutely necessary.
Free market would really work better.

For now most users just use "priority" or "standard" or whatever navme the wallet choose, but that really doesn't let you control the fees.

There's a limit to how much the UX can be streamlined or simplified. Part of that is because both Bitcoin and Lightning are still under massively active development, and with Bitcoin that's 10+ years of work (and that's not even counting all the ruminating on possible designs that Satoshi possibly did, then the prototypes attempts, all before Bitcoin itself was worked on).


And what that's demonstrating is that we've (Bitcoin users) all adapted to Bitcoin's most simplified concepts, despite how technical and sophisticated those remain. All in the name of independent money. I'm sure that automobiles or telephones or firearms were criticized as overly complicated at their advent, but the potential advantage to be gained was too tempting, and so instead people wanted to learn. And now we're all driving around, busting salvos of M16 fire into the air out of rolled down windows, with cryptographic gold kept in electronic wallets on our keyrings :D


So I expect Lightning's perceived UX issues to ameliorate a little, but mostly through familiarity-driven self interest.

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

For me, the choice of whether to use Lightning is question of how pressured I am by on-chain fees. For now, the answer is "not enough." I'm hoping by the time that changes, the UX issues will have improved somewhat.

As for success, the jury is out, but it seems inevitable at least as one of several approaches to the scalability question.

Mobile wallets are a small exception here. Once you enable payment receiving in Eclar Mobile, the timelock for new channels changes and you have to appear online once every two weeks. It's not bad when you compare it to 144 blocks (~1 day) default value.

They've made the mistake of looking to streamline, and simplify the service, but without giving the optional option for those that understand fees a little more. I don't think they should scrap the "priority", and "standard" options. I think instead they should keep these as the default values, but allow any user which wishes to customize their fee the ability to do that within the same window.

I'm no expert on LN, but isn't there a risk of broadcasting an older channel state (by the other party) if the closing transaction doesn't confirm on time? From what I understand, you can't just wait for a very long time if Bitcoin on-chain fees go up.

The lightning network is a great concept in general and has better privacy. However I'm a big fan of transparency and I think the way the current Blockchain displays all transactions that have occurred is a good way of doing it. In the lightning network you cannot see what transactions are going on because they are not stored within the Blockchain. One of the trades off of this is people who know your address will know how much you are spending which could be a privacy concern to those that are trading often and dealing with strangers a lot. Also we should look at the way fees work in the lightning network. They are generally much lower than on chain Blockchain but if you are routing through others payment channels then they will probably request a cut of the transaction which some might not like. It works in the same way the current Blockchain works but instead miners are receiving the cut.

I'm going to try and go through most of the pros and cons of the lightning network and see who agrees with me. I'm not an expert at the lightening chain but am definitely watching the space as I consider it to be one of the most interesting off chain developments being worked on and because we only have the Blockchain to compare to I'll compare each point to that.

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.

Confirmation Speed:

This is a big one and one of the biggest criticisms that Bitcoin has is that transactions take too long to confirm. However this is intentional to allow miners to use their hashing power to get cuts of the transaction and keep the network alive and circulating. The only problem with this is depending on the current average network fees you could be waiting days for your transaction to confirm. In comes the lightening network which offers instant transactions almost like your credit card in how quick transactions are sent. I say "almost" because we have to allow for latency on the network but this is generally zero and your transaction should be sent right away. The blockchain manages transactions differently and actually purposely makes transactions confirm before being sent. This is to check whether all nodes on the network are up to date and a double spend hasn't happened.

However there is a drawback to this. You could continuously keep on sending your transactions on the same payment channel and have they sent instantly and received instantly too. However if you actually want to deposit this amount onto the Blockchain remember that the lightening network is off chain and the Bitcoin won't be deposited or recorded to be on the Blockchain until you decide to deposit it by closing a channel. depending on network usage and a few other factors this usually takes around 10 minutes. This is where things get a little complicated too. If the user that you are sending too requires 6 confirmations because of their business practice or whatever you will still have to wait despite you streamlining the process by using a off chain solution.

There is also another problem when dealing with the lightening networks confirmation. Basically it requires two people to open and close a channel. Opening and closing a channel usually takes around about 10 minutes like previously stated however if one side of the transaction doesn't agree to close the channel then the channel will remain open and this could take up to two weeks to be resolved. Therefore anyone you deal with on the lightening network requires a little bit of trust when dealing with them that they won't just disappear and not close the channel because that could be a pain in the arse for both parties. I can't see why anyone would do this on purpose as it just slows the process down for both but I would think that this does happen.

Fees:
Bitcoin fees can become expensive especially when the network has been congested like in the past. This does not really happen on the lightening network as you are not paying miners to use their hashing rate exactly and instead you are paying for the use of payment channels which every payment channel that you go through will want a cut of the transaction. This is usually pretty low when compared to Bitcoin fees though.

Centralization:
Because of the nature of the Lightening Network it is at danger of becoming centralized. What I mean by centralized is there will be great benefit to those that send transactions on a daily basis to use the same node every time which in time people will see the need of creating what has become known as "super nodes".

The best example I have seen of this is if you were to go to a fast food restaurant and they have created a node for their store in the city. They would keep this node open so that customers could pay instantly without having to create a new channel every time. This could eventually evolve into a nation wide and potentially worldwide payment channel rather than smaller ones being made all the time. America might decide that all american citizens can pay their taxes through the "United States Payment Channel" which would mean greater centralization in nodes.  

The last time I checked the Lightening network did not check for existing channels and it is possible to broadcast to a older payment channel. However the best practice would be to make sure after every transaction the payment channel has been closed unless you are sending transaction fairly regular to justify keeping that payment channel open. My recommendation is to always close payment channels regardless though to increase privacy and decrease the potential of centralization.

But you need 2 on-chain transaction to open and close channel, which means you details with fees again. If user only need to make 1-2 transaction in some time, then create 1-2 on-chain transaction makes more sense.


I don't see how it's centralized, you always could route your transaction through another node, even though i won't deny most likely these "super node" will have big advantage, unless they decide to charge high fees for routing.

IMO those "super node" doesn't mean centralization, but concentration and monopoly.


Your example doesn't show centralization because "United States Payment Channel" is the destination & government don't force their citizens to route LN transaction through their channel, even though it could serve as big honeypot.

Besides, if government could force their citizens to route all transaction through their channel, they also could force them to use wallet which created & managed by government.

The minimum_depth (a number of confirmations) is usually greater than 1, so it takes more than 10 minutes to fund a channel. The timelock is negotiated before funding a channel and it is usually 144 blocks (~1 day). For example, Eclair Mobile clients become an exception if the user enables payment receiving over the LN. In such case, the timelock is extented to 720 blocks (~5 days) for a local uncooperative close and to 2016 blocks (~2 weeks) for a remote one.


A 1/10 th satoshi fee sounds better to me than a 1000 satoshi one. Miners already receive a block reward while node operators don't get anything.

I've seen this discussion going towards the financial side of running a lightning node... Just to make sure no urban legends get created, i decided to share my own statistics..

Just some background info: I've been running a lightning node from before reasonably good lightning node explorers were around... Basically from the moment the first relatively stable beta version of c-lightning was released (once a week i still build c-lightning straight from the head branch on github).
I've used lightning-charged on top of c-lightning and a homebrewn payment system on top of lightning-charged for a long time. Recently i retired my own code and lightning-charged, and put btcpay on top of my c-lightning node. I've created hundreds of invoices and actually received +100 payments (so far).

Now, for the actual, up-to-date, statistics of my node:

So... currently 17 open channels, 7 with funds on my side of the channel. Dozens of other channels have been closed since i started running a node.

All of them have funds on the other side of the channel

yup... That's right... A grand total of 0 msatoshi in fees made during the months i've been running the node  ;D

Another criticism is, how secure is Lightning? Has it experienced any attacks of some kind? That should worry the users, because we simply don't know.

I believe the reason why no one has yet shown any interest in attacking Lightning, is because the total capacity is not that big yet.

How much in total in USD was commited to the DAO?

That's interesting. Xian01 had been posting his Lightning Network node stats in the Lightning Network Discussion thread before it was closed and he actually managed to earn a few satoshis. If I recall correctly, he was using LND with its built-in autopilot. Here (https://bitcointalk.org/index.php?topic=4638321.msg43600605#msg43600605)'s one of his posts.


The Lightning Network experienced a DDoS attack (https://www.trustnodes.com/2018/03/21/lightning-network-ddos-sends-20-nodes) in March last year. 20% of all nodes were down at that time due to the attack.

If you want to look at the negative aspects of lightning network there are many, the most important thing is that you cannot make a LN payment offline and both the parties needs to be online for every transaction. For micro transactions it is the best option but for larger ones i would not trust LN. Since the transactions are made outside the blockchain you literally have to trust a centralized authority who started that network, in short LN is all about centralization  ;).

Who are you referring to as the central authority who started the network? There's none. The Lightning Network Specifications (https://github.com/lightningnetwork/lightning-rfc) have not been created by a single person or company. There are many different implementations (LND, Eclair, c-lightning and more) which are open-source. Anyone is able to audit the code and set up their own Lightning Network node. Payments don't go through a central server. You can open a channel directly to a merchant so that you don't have to pay any fees for multiple transactions (routing fees are negligible anyway).

Hope you did not understand what i was referring to, i never debated about LN being a closed end program, it is an open source code and anyone can review it, how about the trust when everyone can open an LN network, how will you determine whether the channel is legit, the importance of bitcoin comes when you do not need a trust from a third party and that is why i got attracted in bitcoin back in the day, if you need trust i call it centralized, there is no two way about it mate ;).

You can't create a fake channel because the Lightning Network is strictly tied to the blockchain. How would you determine if the coins you received were not double-spent? You would run your own node. I would do exactly the same on the Lightning Network in order to watch over all of my channels. Both of these nodes have to follow some standards and rules which in LN's case are written down in the specifications (https://github.com/lightningnetwork/lightning-rfc). You have to trust any software unless you code it yourself.

that's wrong

please learn something (anything) about Lightning before you post again

I have been bouncing a reply to this one line in my head since I saw your post a few days ago.
The word perceived is wrong. They are there. Everyone wants their pretty GUI menus and buttons on everything now.

Your TV gets a lower review on AV site because the smart TV features are not pretty enough.

If you want consumer level use you need to have that. It is not a were in alpha stage we will get to it. It's now become PART of alpha stage work. It all has to be done together. Because if LN is finished tomorrow but the UI / UX is not done for another 9 months then guess what LN is not done.

Just my view.

-Dave

One of the things that may be hindering its perception is that most people who arrived in BTC turned up when the hard work was done. There's still plenty of tweaking but you can dive right in and it's all primed and waiting.

Lightning Networks are developing in real time in an organic way. Most people have no experience of that. The stuff they use every day is launched by a company when it's ready and it's immediately fully operative.

It's possible old hands will still be ignoring it thinking it isn't ready when newbies are batting their satoshis around without a second thought. Maybe someone should organise a cheesy Bitconnect style gala launch just to pander to human nature when consensus is that it's good enough.

Lightning is in a similar place development-wise that Bitcoin was in 2010 to 2012: usable product, and rough around the edges, but also moving at a decent pace.

I guess the difference was that the Bitcoin devs were "running out of road" and so needed to make sure that didn't happen before it got popular. Lightning devs have a whole network of highways, but the quality of the roads, maps and the direction signs is still a bit lacking.


@DaveF

if you want a GUI, there's:

• Lightning Labs desktop wallet (forgot the exact name :/ )
• Eclair mobile wallet (Android)
• That "Blue wallet" one (Android + maybe iOS)
• A GUI for c-lightning (pretty simple, looks like the standard Bitcoin GUI)

I mean, Lightning is still software. Software bugs and problems are pretty much inevitable; even with Bitcoin itself. It just depends on how drastic the problem is, and or how quickly it gets resolved.

Hi,

The biggest issue for me is  that you cannot have a  safe backup of your lightning funds using seed words

A safe offline backup solution is very important, if you want users to store any serious amount of funds on LN

no, the wallets used to manage Lightning channels do have a seed in every implementation


there's no seed for the channel addresses, but that's not relevant, as the funds will always end up back in the addresses of the underlying bitcoin wallet should a channel be closed.


think of it like this; Lightning channels are like a checking account, for regular comings and goings of cash. saying the channels don't have seeds is like complaining your debit card didn't come with a bank vault and an armed guard

This is relevant, user will lose funds if  his mobile phone having LN channel states crashes (https://bitcoin.stackexchange.com/questions/87463/can-funds-from-a-ln-channel-be-recovered-if-both-participants-suffer-data-loss)


In essence, what you are saying is LN is insecure for anything greater than 100USD. And you should put only small amounts that you can afford to lose. This forces me to keep transferring funds between bitcoin/LN which doesn't work with high tx fee

redundant disk solves that, a seed cannot. For a phone, just keep literal pocket change amounts on a phone. How often does an entire phone fail anyhow?



nope, I'm not saying either of those things, and that's not how I use Lightning at all. Money comes in, money goes out; there's not much need to go back on-chain, you just need to put some thought into how you manage it.

Both Eclair Mobile (https://play.google.com/store/apps/details?id=fr.acinq.eclair.wallet.mainnet2&hl=pl) and Bitcoin Lightning Wallet (https://play.google.com/store/apps/details?id=com.lightning.walletapp&hl=pl) allow user to backup their Lightning Network channels. The former allows creating local backups as well as encrypting and uploading them directly to user's Google Drive account automatically. As far as I remember, the latter asks user to pay for its backup service. It might have changed, though.

Eclair Mobile sets the timelock for the remote uncooperative close to 2 weeks which is plenty of time, especially if you take into account that most people keep their phones constantly connected to 3G or 4G networks (unless you live in the US where data plans are expensive ;) ). It's also possible to have an LND node on a VPS and a Zap app (https://github.com/LN-Zap/zap-android) on a phone which makes sending and receiving payments much easier without a risk of theft. Spark (https://github.com/shesek/spark-wallet) is an alternative if someone uses c-lightning.

I made a small assumption here. It's still 144 blocks by default, but it is extended to 2016 blocks when the user enables receiving payments over the LN. You are more likely to lose money when the other party had coins on their side in the beginning.

My Eclair client makes backups on Google Drive, and I've never paid them directly (only with my privacy). I think Google Drive is part of the ~15 GB Gmail storage space.
I've never tested the backups though.

I think it was BitCryptex who mentioned a VPS before: does it require storing the full blockchain to run a full LN node? If so, any cheap VPS won't qualify (the cheap VPS I bought recently has 25 GB only).

It looks like you have misread my post. Bitcoin Lightning Wallet (https://play.google.com/store/apps/details?id=com.lightning.walletapp&hl=pl) is the one that charges users for backups. More information can be found here (https://lightning-wallet.com/storage-tokens#storage-tokens).


No, it doesn't. If you choose LND then you can use built-in neutrino which is a light client. The Lightning Network node itself doesn't use many resources. We could set it up even on your VPS.

FWIW it's not true anymore on C-lightning. Using the [db_write plugin hook](https://lightning.readthedocs.io/PLUGINS.html#db-write) a plugin can replicate the entire database. Along with the seed (contained in `~/.lightning/hsm_secret`) it is possible to have a full backup of your LN node. To get much closer from practice here is a proposed plugin implementing that actual feature : https://github.com/lightningd/plugins/pull/40.

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

it's conceptually similar, so you can see how someone could make such a mistake (or deliberately state the falsehood as fact in order to bash Lightning)


the similarities end in the redemption; if you redeem an IOU, the issuer might just refuse (or make an excuse). But the issuer of funds in a Lighting channel is the Bitcoin blockchain, and so when you "redeem", it accepts no matter what.

i.e. payment channels have the advantages of an IOU without the drawbacks

No IOUs in Lightning. They are signed transactions made by the participants of the channel that have not been broadcasted on-chain yet. No one is holding your coins, and issued something worthless in Lightning.

I'm not sure what you're getting at. It's obvious you can't send Bitcoins without making an on-chain transaction. That statement is true with or without Lightning Network.

another way to look at it :-

• IOU's are informal contracts, that have a reputation for being easy to break
• Lightning channels are contracts too, but they're enforced by the Bitcoin blockchain. You can't break these contracts

future improvements (i.e. Eltoo / sighash_noinput) will tidy up the corner case where old copies of channel updates are put on-chain.

Well put. I think a lot of misconceptions regarding LN stem from mistaking the latter for the former. They seem to believe that LN smart contracts are governed by laws similar to legal laws (ie. a social construct based on trust and thus easily broken) while the laws smart contracts are governed by are more akin to the laws of physics.

As a side note this is what people should be pushing for when it comes to contracts with anything. Unbreakable contracts by either party which are enforced by a system such as the Blockchain. The Lightning Network is no doubt a good move even if its not perfect in itself, its a movement that will hopefully lead onto better things. Whether that's The Lightning Network or something different.

But Lightning is nothing "like" an IOU system. "Coins" sent in Lightning are actually signed transactions that haven't been broadcasted, and included in the blockchain yet.

goods in an IOU are signed by the issuer, and haven't been delivered to the recipient yet

Lightning channels are just contracts to deliver valid on-chain funds, but not to actually confirm the transaction. If it can be confirmed, then it's nigh-on identical to actually owning it on-chain, you have the signed transaction that delivers the BTC to an address own by you

(that's why Eltoo/sighash_noinput is so important, the big obstacle is unexpectedly high on-chain fees preventing you from settling a channel balance, no_input lets you change the transaction fee when you initiate a channel close, whereas with today's Lightning you must choose the transaction fee when you update the channel, which may be a while before you close)


The "IOU" thing is a psychological trick; IOU's have a bad reputation for being worthless and easy to abuse, whereas as you say, Lightning is not like that. That doesn't mean it's any less like a non-legal contract, it is a non-legal contract. Lightning channels are better guaranteed than even a legal contract, maybe we should call them cryptographic or algorithmic contracts to reflect this difference. I find "smart" contract to be an irritating expression

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.

Am I wrong in this? Was franky1 actually right that the transactions in Lightning are made up of IOUs? Hahaha.

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.



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.

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.

https://i.imgur.com/q1nONRn.png

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.


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.

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.

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.

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.

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.

Merriam Webster (https://www.merriam-webster.com/dictionary/IOU) 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.

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.

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're mistaken though :P 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.

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

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.

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


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


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.

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

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.


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.

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


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

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
https://pbs.twimg.com/media/D1uAJntUcAETD1G.jpg

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.

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.

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

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.

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

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.

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

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.

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


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.

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.

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.

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.

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 (http://istimelord2067ondtyet.tk/)...)

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.

Lol, wrong link? :P

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

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.

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?

Are you sure about that? I am quite sure that Zap is strictly related to LND (its GitHub (https://github.com/LN-Zap) seems to prove that too).