The Lightning Network FAQ

[DaveF]

I would like to say what the actual fuck?

When fees were low this weekend I sent some funds to my node, around about the time I made this post:
https://bitcointalk.org/index.php?topic=5158920.msg55715316#msg55715316

Anyway, I opened 3 channels and wound up having someone route a somewhat large payment through and last night I decided to close it because I wanted to try something else today. I closed it with a somewhat low fee and figured it would happen overnight. Which it did.

Woke up, has a cup of coffee and looking at the console. 5 small channels were opened with large fees and then closed with small fees so it's going to be a bit before the funds clear.

This is the 2nd time it's been done to me and it's on a node I do not advertise is mine and is on an IP that does not come back to me in any public way, so I know it's not a "screw with Dave" thing. I can't be be only one, at least I don't think I can be.

With the "yeah I know ask on github"  bit I am asking here 1st is there anyway I can set in the LND config the minimum you have to pay in sat/b to open or close a channel to my node?

Thanks,
Dave

[LoyceV]

Woke up, has a cup of coffee and looking at the console. 5 small channels were opened with large fees and then closed with small fees so it's going to be a bit before the funds clear.

I once tried to open a channel with low fee, which didn't confirm in time. The node then closed the channel with a much higher fee, basically doing CPFP. When connecting to the node, I had no option to choose the fee to close the channel.
I'm surprised yours allows that.
Back to your case: what would happen if the low-fee closing transaction doesn't confirm in time? Does that give the client any chance to force close the channel with detrimental effects on your node?

[DaveF]

Woke up, has a cup of coffee and looking at the console. 5 small channels were opened with large fees and then closed with small fees so it's going to be a bit before the funds clear.

I once tried to open a channel with low fee, which didn't confirm in time. The node then closed the channel with a much higher fee, basically doing CPFP. When connecting to the node, I had no option to choose the fee to close the channel.
I'm surprised yours allows that.
Back to your case: what would happen if the low-fee closing transaction doesn't confirm in time? Does that give the client any chance to force close the channel with detrimental effects on your node?

If it times out my node should CPFP the channel like your did.
With LND from the command line you can specify the fee or just use the default.
Same if you are using Ride The Lightning. You can pick your fee and it broadcasts and then you wait.

-Dave

[Wind_FURY]

It's just a matter of record keeping offchain?

For the time being, yes.

OK, thank you. I tried searching. I believe more ELI5 educational information on how Lightning nodes keep transaction records should be more available for the newbies, and non-technical people like me.

 There will be no need for rounding down millisatoshis on channel closure once we increase the number of decimal places on-chain. It is bound to happen some day.

That would be bigger than the scaling debate.

[LoyceV]

There will be no need for rounding down millisatoshis on channel closure once we increase the number of decimal places on-chain.

If that happens, LN can go to microsatoshis so the "problem" remains. But I don't think it'll ever happen on-chain. At the moment, there are no decimals on-chain, only satoshis (no "Bitcoins").
But more importantly, 1 satoshi is small enough no matter what happens. And even if you were to create a system that requires millions of sub-satoshi-payments to make it worth using such small values, it won't happen on-chain because of block space.

[Wind_FURY]

There will be no need for rounding down millisatoshis on channel closure once we increase the number of decimal places on-chain. It is bound to happen some day.

That would be bigger than the scaling debate.

I doubt it'd be bigger than scaling debate since the debate itself should be on very technical level (e.g. whether older software can process higher float precision and higher transaction size due to higher float precision) rather than politic or ideology.

Maybe you're right, but if it requires a hard fork, and it requires that the whole community to come together behind a, not "life or death", upgrade for Bitcoin that could contentious, then I believe it will cause another big debate.

[PrimeNumber7]

There will be no need for rounding down millisatoshis on channel closure once we increase the number of decimal places on-chain. It is bound to happen some day.

That would be bigger than the scaling debate.

I would be surprised if this was the case.

Increasing the max block size was one solution to a technical problem that it was unclear was an actual problem in the present. Increasing transaction value precision will be the only solution (that I can think of) to a problem, and it will be very obvious if it is a problem, as it would be reflected in the price of bitcoin.

[Wind_FURY]

There will be no need for rounding down millisatoshis on channel closure once we increase the number of decimal places on-chain. It is bound to happen some day.

That would be bigger than the scaling debate.

I would be surprised if this was the case.

Increasing the max block size was one solution to a technical problem that it was unclear was an actual problem in the present. Increasing transaction value precision will be the only solution (that I can think of) to a problem, and it will be very obvious if it is a problem, as it would be reflected in the price of bitcoin.

Bigger than the scaling debate, or not, I believe it will still be a "big debate", simply because it will require a hard fork. But unless, maybe, if Bitcoin surges to an 8 digit valuation or more, which is very crazy, even for me, then maybe everyone can agree for it not to become a contentious hard fork.

[DaveF]

Does anyone know if there is a simple way to do an IFTT for opening and closing channels?
I think it would be nice to be able to deal with the opening and closing of channels when onchain fees are low.
So set and IF suggested fees are lower then "X" then open / close these channels.

For now I just keep an eye on what is going on, but would like to automate it a bit.

-Dave

[Carlton Banks]

Does anyone know if there is a simple way to do an IFTT for opening and closing channels?
I think it would be nice to be able to deal with the opening and closing of channels when onchain fees are low.
So set and IF suggested fees are lower then "X" then open / close these channels.

For now I just keep an eye on what is going on, but would like to automate it a bit.

there's a c-lightning plugin that does that, it automates quite alot (including channel re-balancing and soliciting incoming channel liquidity)

it's available only as C++ source for now, from the ZmnSCPx character's github (I may have spelled the name wrong....)

you basically start the plugin, and it more or less runs your node for you (but it's still possible to intervene manually)

[DaveF]

Does anyone know if there is a simple way to do an IFTT for opening and closing channels?
I think it would be nice to be able to deal with the opening and closing of channels when onchain fees are low.
So set and IF suggested fees are lower then "X" then open / close these channels.

For now I just keep an eye on what is going on, but would like to automate it a bit.

there's a c-lightning plugin that does that, it automates quite alot (including channel re-balancing and soliciting incoming channel liquidity)

it's available only as C++ source for now, from the ZmnSCPx character's github (I may have spelled the name wrong....)

you basically start the plugin, and it more or less runs your node for you (but it's still possible to intervene manually)

Playing with it now. Seems interesting. I have been running LND so getting c-lightning running took me a while.

On a separate note: I finally have everything running behind TOR, so locally I can connect on my local network IP while out in the world I use TOR.
But, does anyone know of an Android wallet with built in TOR that works? As of now I am using Orbot & Zap but would prefer and all in one.

-Dave

[Wind_FURY]

Shower thought. The reason why exchanges have never/will never implement Lightning for lower fees is not because of UI/UX issues, or the absence of business development for Lightning. It's because exchanges want more altcoin usage, and to collect fees from trading.

[DaveF]

Shower thought. The reason why exchanges have never/will never implement Lightning for lower fees is not because of UI/UX issues, or the absence of business development for Lightning. It's because exchanges want more altcoin usage, and to collect fees from trading.

Also, the issues of dealing with people who have their wallets not setup properly. Probably some other issues too.
Don't forget most withdraws on exchanges also are a profit center.
As of now 7:15 AM EST 15-Dec-2020   25 sat/b will get you into the next block more or less.
To sweep one of my wallets at that will cost me 0.0000455 (3 inputs -> 1 output)
Show me an exchange that will do a withdraw for less then .0005 even when the mempool is empty.

-Dave
 

[LoyceV]

Show me an exchange that will do a withdraw for less then .0005 even when the mempool is empty.

At the moment:
https://www.coinplaza.it/: 0.00119815LNBTC gives 0.001BTC on-chain.
https://fixedfloat.com/: 0.00108384LNBTC gives 0.001BTC on-chain.
That's 8384 sat fee for the cheapest, including the 1% exchange fee. Just don't use big exchanges for this.

I'm not sure if it's the intended result, but the fees on exchanges make me keep funds there for a long time in order to avoid paying the withdrawal fee.
Amazingly, most exchanges don't charge a fee on small deposits, while those lead to higher consolidation costs. Most payment processors on the other hand add enough to make the user pay for their consolidation. I remember paying something small in 2017, and later saw my payment being consolidated together with many others at a $6k fee. That's huge, but for exchanges this cost is included in the withdrawal fees.

[Rath_]

Shower thought. The reason why exchanges have never/will never implement Lightning for lower fees is not because of UI/UX issues, or the absence of business development for Lightning. It's because exchanges want more altcoin usage, and to collect fees from trading.

Kraken has just announced that they are going to enable withdrawals and deposits over the Lightning Network in the first half of the next year. Do you think it will set off a chain reaction among other exchanges?

[LoyceV]

Kraken has just announced that they are going to enable withdrawals and deposits over the Lightning Network in the first half of the next year.

They still have to start hiring a team to start LN implementation, but it's something
I'm curious what limits they'll choose: they probably don't allow withdrawing very low amounts and I don't expect very low fees either. They don't even allow trading cents for performance reasons.

Do you think it will set off a chain reaction among other exchanges?

Probably not, but if that happens arbitrage trading is going to be fun if you can make large-transfers between exchanges in a few seconds.

[DaveF]

Kraken has just announced that they are going to enable withdrawals and deposits over the Lightning Network in the first half of the next year.

They still have to start hiring a team to start LN implementation, but it's something
I'm curious what limits they'll choose: they probably don't allow withdrawing very low amounts and I don't expect very low fees either. They don't even allow trading cents for performance reasons.

Do you think it will set off a chain reaction among other exchanges?

Probably not, but if that happens arbitrage trading is going to be fun if you can make large-transfers between exchanges in a few seconds.

Just because of what I said before about fees I can't see them just walking away from the profit center of withdrawal fees like that.
That or there are going to be some stilly restrictions and rules put in place.
Or there is another angel I am missing.

-Dave

[PrimeNumber7]

Kraken has just announced that they are going to enable withdrawals and deposits over the Lightning Network in the first half of the next year.

They still have to start hiring a team to start LN implementation, but it's something
I'm curious what limits they'll choose: they probably don't allow withdrawing very low amounts and I don't expect very low fees either. They don't even allow trading cents for performance reasons.

I would think the opposite. An exchange facilitating LN deposits/withdrawals will want to keep the amounts low because large transactions have the potential to make LN channels become unbalanced, and will need to be closed. Very small transactions may be prohibited to avoid database bloat.

I don't think exchanges will have especially high fees either. Deposit/withdrawal fees charged by exchanges are generally in line with actual costs associated with receiving/sending a deposit/withdrawals.

Do you think it will set off a chain reaction among other exchanges?

Probably not, but if that happens arbitrage trading is going to be fun if you can make large-transfers between exchanges in a few seconds.

I don't think LN will cause much additional arbitrage trading. Today, traders can hold both BTC and USDt on both exchange A and exchange B, execute trades on both exchanges once the price deviates by a predefined threshold, and transfer coin between exchanges after both arb trades are executed.

[Wind_FURY]

Kraken has just announced that they are going to enable withdrawals and deposits over the Lightning Network in the first half of the next year.

They still have to start hiring a team to start LN implementation, but it's something
I'm curious what limits they'll choose: they probably don't allow withdrawing very low amounts and I don't expect very low fees either. They don't even allow trading cents for performance reasons.

I would think the opposite. An exchange facilitating LN deposits/withdrawals will want to keep the amounts low because large transactions have the potential to make LN channels become unbalanced, and will need to be closed. Very small transactions may be prohibited to avoid database bloat.

I don't think exchanges will have especially high fees either. Deposit/withdrawal fees charged by exchanges are generally in line with actual costs associated with receiving/sending a deposit/withdrawals.

Do you think it will set off a chain reaction among other exchanges?

Probably not, but if that happens arbitrage trading is going to be fun if you can make large-transfers between exchanges in a few seconds.

I don't think LN will cause much additional arbitrage trading. Today, traders can hold both BTC and USDt on both exchange A and exchange B, execute trades on both exchanges once the price deviates by a predefined threshold, and transfer coin between exchanges after both arb trades are executed.

Plus if they are willing to accept the trade-off. I believe exchanges that want large transfers between them should join the federation of BTC-issued tokens in the Liquid sidechain.

[DaveF]

Plus if they are willing to accept the trade-off. I believe exchanges that want large transfers between them should join the federation of BTC-issued tokens in the Liquid sidechain.

The other side of that is that can cause exchanges to become more "bank like"
All you need is of of them to start.
There will be no BTC transferred till certain limits have been hit or till the end of the day everything else would just be a journal entry.

Think about it. If I am going to send from a to b all they have to do is note it in their database someplace.
Then if you send from b to a it's just notes BTC going the other way and deducts from the total owed.
Overnight they settle up, and send in one tx.
Unless the amount goes over over a certain level, then they trigger a settlement.

You now have Chase and CitiBank but with BTC instead of $.

Others want to join in. Look banking 2.0 same as 1.0 just with BTC.

OK it's a worst case scenario and probably not going to happen but.....

-Dave