The Lightning Network FAQ

[darosior]

Would pathfinding be made easier if you use a higher setting for fees? I believe that might support also the theory that fees in Lightning would be a little higher than the promoted, "unfairly cheap fees".

No, pathfinding is hard because you (currently, will be optimized when needed) have to browse the whole graph to find a route, and thus you need to keep this big graph up-to-date (hard on bandwidth).

I guess those promoting these "unfairly" cheap fees would now argue that "it was 'unfairly cheap' in the context of Bitcoin" lol. But of course Lightning *needs* higher fees to be sustainable, and I'd argue that anyway the real value proposition of Lightning Network is not "cheap fees" but "instant confirmation", which makes Bitcoin usable as an instantaneous mean of payment (or at least now it's secure ).

[Chlotide]

What do you guys think of channel probing? Is there a way to ensure someone does not find out the channel ballance?

https://arxiv.org/abs/2004.00333

[jackg]

What do you guys think of channel probing? Is there a way to ensure someone does not find out the channel ballance?

https://arxiv.org/abs/2004.00333

Haven't checked the doc but I remember there being a difference between the amount the channel had avaliable to send to help with routing and the full balance? A lot of clients mention a push and pull figure so this would just find the avaliable to be pushed amount?

The amount was made to help nodes decide how much funds they wanted to have locked up in a contract if a party declined to comply with a htlc or lost connectivity.

[Wind_FURY]

Would pathfinding be made easier if you use a higher setting for fees? I believe that might support also the theory that fees in Lightning would be a little higher than the promoted, "unfairly cheap fees".

No, pathfinding is hard because you (currently, will be optimized when needed) have to browse the whole graph to find a route, and thus you need to keep this big graph up-to-date (hard on bandwidth).

I guess those promoting these "unfairly" cheap fees would now argue that "it was 'unfairly cheap' in the context of Bitcoin" lol. But of course Lightning *needs* higher fees to be sustainable, and I'd argue that anyway the real value proposition of Lightning Network is not "cheap fees" but "instant confirmation", which makes Bitcoin usable as an instantaneous mean of payment (or at least now it's secure ).

I was asking about easier pathfinding, when there are multiple fee settings across the channels. Plus if it would make transactions pass through to its destination with less errors?

[darosior]

I was asking about easier pathfinding, when there are multiple fee settings across the channels. Plus if it would make transactions pass through to its destination with less errors?

Pathfinding I'm not sure but maybe you asked if routes with higher fees were statistically more reliable ? If so I don't have stats but I would expect people who raise their node's fees would at least try to please the LND rating algorithm (and so have balanced channels, be more reliable, etc..).

Those routes are not easier to find though .

[Wind_FURY]

I was asking about easier pathfinding, when there are multiple fee settings across the channels. Plus if it would make transactions pass through to its destination with less errors?

Pathfinding I'm not sure but maybe you asked if routes with higher fees were statistically more reliable ? If so I don't have stats but I would expect people who raise their node's fees would at least try to please the LND rating algorithm (and so have balanced channels, be more reliable, etc..).

Those routes are not easier to find though .

Haha. Maybe it was wrong of me to expect that, "balanced/more reliable channels = more right to set higher fees. Therefore higher fees = better"?

[Chlotide]

CMIIW, but isn't it possible to get available balance of both direction (push and pull figure) simply by reverse the direction of transaction routing?

Code:

Attacker A -> Bob -> Attacker B

Attacker A <- Bob <- Attacker B

In both scenarios you probe and can find Bob's ballance.
You actually don't need any funds as you can use random payment hashes and observe the errors you get. Oversimplifying this a bit.. you send 0.5 btc. "not enough funds" means try with less.. "invalid payment hash" means try more... untill you can find out the ballance pretty accurately.

Code:

Attacker - > Bob - > John   ... find out Bob's ballance
Attacker - > John - > Bob   ... find out John's ballance

At least from what I understood.
And yeah... ignoring routing does not seem to be the way to go

[Wind_FURY]

Is this device worth the $99.00? http://mynodebtc.com/products/premium

Asking for a friend. Real reviews from real users only, no shilling. It might be the cheapest way to start "staking" coins in Lightning, without the installation headache.

[DaveF]

Is this device worth the $99.00? http://mynodebtc.com/products/premium

Asking for a friend. Real reviews from real users only, no shilling. It might be the cheapest way to start "staking" coins in Lightning, without the installation headache.

I'll start with the tl;dr
Yes, if for no other reason then to support the developer. And it does a lot with very little work on your part. If you run the VM or have an RPi with a GOOD external drive it's free. I would still pay to support the dev. You can do it all yourself but....

Dave's long rambling:
I have 3 "nodes in a box" up at the moment 1 is the raspiblitz that I have spoken about in this and other threads. It's running on a RPi4 under a desk at home.
I have 2 mynodes running. 1 paid for 1 not since I tinker and re-set it a lot. They are both virtualbox VMs but the RPi version is just as good. It's not just a lightning node.
It also runs the Ride the Lightning webapp so you can use your lightning wallet from your local web browser. It also has Dojo and Whirlpool so you can connect your Samourai wallet to it. [still needs tweaking but it does work if you put in the time]  Also, it's running an Electrum Server so you can connect that to it also. Along with some other apps.

Now all of that put together has saved *me* WAYYYYY more then $100 in time. I don't know where you live and how much you get paid, but they have put it all together in once nice more or less click to run package. I could do it myself. Probably take days and days and not even have the nice web front end. For me that alone is worth it. YMMV on that. Also, with the paid version you get more "stuff" the TOR & VPN are nice and I do like having the local mempool.space explorer. So you do have to factor in the cost in your time to get those running if you wanted them. BTC pay server is also in the paid version, but for me I would always run that as a separate stand alone thing, but that is me.

So yeah I would pay the $99.
The $279 for the hardware with the APP....that's a tough call. RPi4 + 512GB Samsung SSD + SD card + 5A power adapter is less then $179 they are giving a 1TB but don't know the brand. And if there is a hardware issue I don't know their service. Also, again, not knowing where you are in the world changes price matters.

Stay safe.

-Dave

[PrimeNumber7]

What do you guys think of channel probing? Is there a way to ensure someone does not find out the channel ballance?

https://arxiv.org/abs/2004.00333

I am not sure if this is currently implemented, but the parties to a LN channel could agree that neither side will agree to a transaction that causes one side's balance to fall below a threshold. The parties could agree that this threshold changes periodically.

Also if bob has three open LN channels, if he has a receiving capacity of 1 BTC on channel A, someone trying to send coin via channel A will not necessarily know what other channels he has open, and a transaction getting declined would only reflect the balance on the channel with the smaller sending capacity. Or the computer behind one of the other channels might be down temporarily.

What the authors in the paper also describe is also expensive. To make 50k 'hops' in the LN network, it would cost ~$3-4 assuming 1 sat/hop, this is not much money, but in order to meaningful information, you would need to determine the balance of LN channels many times per day.

[LoyceV]

I am not sure if this is currently implemented, but the parties to a LN channel could agree that neither side will agree to a transaction that causes one side's balance to fall below a threshold. The parties could agree that this threshold changes periodically.

It's probably possible to implement, but why would you do that? If you don't want to use your full channel balance, you could just deposit less.

If you really don't want to use the entire channel capacity, I don't think you need the other party for it: if you're the one who opened the channel, you can just decide on your own not to use the full capacity. If you're the receiving party, it's not in your interest to refuse payments even though the channel has enough capacity.
If it's about balancing the channel, there are other ways to do this.

[DaveF]

What do you guys think of channel probing? Is there a way to ensure someone does not find out the channel ballance?

https://arxiv.org/abs/2004.00333

Unless I am missing something, which is possible, when network utilization is low like it is now it will work. Once it gets busy it's going to be useless since if 100s or 1000s of transactions are happening per minute by the time you get the data and parse the data the data might have changed.

Now that channels can stay unused for weeks at a time it's a different story.

Stay safe.

-Dave

[Chlotide]

Also if bob has three open LN channels, if he has a receiving capacity of 1 BTC on channel A, someone trying to send coin via channel A will not necessarily know what other channels he has open, and a transaction getting declined would only reflect the balance on the channel with the smaller sending capacity. Or the computer behind one of the other channels might be down temporarily.

I was referring to something else, to ensure someone does not find out my balance within a certain channel. Guess I wrote wrong, sorry.

Let's say I open a payment channel with godaddy (first thing that came to mind)
I deposit 0.1BTC and godaddy 0BTC.
Now you (for example) can connect to my payment channel (they are public and also total balance is too) and you try to send godaddy bogus payment of 0.05BTC. You get invalid hash (because you can do that when off-chain). That means I have at least 0.05BTC. Then try 0.07-8-9... and finnaly you find out (with 99% certainty) that my balance is 0.1BTC

It is about one's balance in each channel, true, I could have 100 open channels at a given time... but some might not appreciate that info to be that accessible

What the authors in the paper also describe is also expensive. To make 50k 'hops' in the LN network, it would cost ~$3-4 assuming 1 sat/hop, this is not much money, but in order to meaningful information, you would need to determine the balance of LN channels many times per day.

From what I understood you can also use "made-up"/bogus transaction hashes and you base the next move on the error receives (as I said above). So could also be free

Unless I am missing something, which is possible, when network utilization is low like it is now it will work. Once it gets busy it's going to be useless since if 100s or 1000s of transactions are happening per minute by the time you get the data and parse the data the data might have changed.

Now that channels can stay unused for weeks at a time it's a different story.

The idea was to identify someone`s "stake" in a channel.
Routing a payment through node A to node B in order to find out node A's balance.

[PrimeNumber7]

I am not sure if this is currently implemented, but the parties to a LN channel could agree that neither side will agree to a transaction that causes one side's balance to fall below a threshold. The parties could agree that this threshold changes periodically.

It's probably possible to implement, but why would you do that? If you don't want to use your full channel balance, you could just deposit less.

If you really don't want to use the entire channel capacity, I don't think you need the other party for it: if you're the one who opened the channel, you can just decide on your own not to use the full capacity. If you're the receiving party, it's not in your interest to refuse payments even though the channel has enough capacity.
If it's about balancing the channel, there are other ways to do this.

If Alice and Bob have an open channel, and for simplicity sake, say the average TX fee necessary to close a channel is 0.001 btc.

If Alice has a balance of 0.0015 and spends 0.006, it would not make sense for Bob to broadcast the penalty transaction because the transaction fee would be more than the additional amount he will receive. If Alice spends her balance down to a small number of sats, she could delay the closing of the channel even though she is basically owed nothing.

[LoyceV]

If Alice spends her balance down to a small number of sats, she could delay the closing of the channel even though she is basically owed nothing.

If that's the reason not to use the entire channel balance, you can just keep a higher channel reserve. I've had my Eclair channels in such a state: emptying them as far as possible when fees were low meant there was nothing to gain (for me) anymore by closing the channel. That gave me inbound capacity without having "invested" much.

[Wind_FURY]

I remember franky1 going on a disinformation rampage about "Bitcoins in Lightning are IOUs because milli-sats", but I never researched how Lightning actually make milli-sats possible. Can anyone ELI5?

Yes, I'm ashamed.

[darosior]

I remember franky1 going on a disinformation rampage about "Bitcoins in Lightning are IOUs because milli-sats", but I never researched how Lightning actually make milli-sats possible. Can anyone ELI5?

Yes, I'm ashamed.

They are accounted until it reaches 1sat (and rounded down to sat for transactions), at which point they are added to the fees. Once the amount of sats is enough to create an output (above the dust limit [1]), an HTLC output is created instead of adding the amount to the fees.

[1] The dust limit here isn't the "real" one (which can vary), it's a fixed limit agreed at channel creation by the peers.

[Wind_FURY]

I remember franky1 going on a disinformation rampage about "Bitcoins in Lightning are IOUs because milli-sats", but I never researched how Lightning actually make milli-sats possible. Can anyone ELI5?

Yes, I'm ashamed.

They are accounted until it reaches 1sat (and rounded down to sat for transactions), at which point they are added to the fees. Once the amount of sats is enough to create an output (above the dust limit [1]), an HTLC output is created instead of adding the amount to the fees.

[1] The dust limit here isn't the "real" one (which can vary), it's a fixed limit agreed at channel creation by the peers.

OK, is it as simple as changing the most basic unit of account from sats to millisats? How does that "transformation" happen in Lightning. Or is it simply because any rule can be made up in L2 networks?

[DaveF]

OK, is it as simple as changing the most basic unit of account from sats to millisats? How does that "transformation" happen in Lightning. Or is it simply because any rule can be made up in L2 networks?

Any rule that the L2 agrees upon.

Automotive version:

Think of it as having a car that is street legal that you can also drive on the track.
While driving it to the racetrack (L2 network) you have to obey all the local traffic rules (main chain), once you are the track there are a different set of rules. Still the same car (BTC) however, once you leave the track for the drive home, the local traffic rules apply again.

Probably nor 100% technically accurate but *I* feel it is a good example. Others will disagree.

-Dave

[darosior]

OK, is it as simple as changing the most basic unit of account from sats to millisats? How does that "transformation" happen in Lightning. Or is it simply because any rule can be made up in L2 networks?

Yes, and making it unenforceable onchain (as dust outputs once again!). Some are critic regarding that choice.

However, accounting for such small amounts are really handy : for example for the fees. Fees are denominated in msat and most are below the thousand msat, without such an accounting system how could fees that low (or that precise !) be enforced ? Paying one whole sat but once each X forwarded payments ? That's not viable.

Secondly, we need to bear in mind that channels may be (some are already) used at a high frequency : 10 forwarded payments paying 100msat each can be enforced directly at the creation of the next commitment transactions (at least in the fees), and they don't originate from the same payer.

Thus, it might seem a bad idea to allow unenforceable amounts while giving the system a quick look but things are more complex and there are also benefits