The Lightning Network FAQ

[Timelord2067]

but bitcoin doesn't have the middle men to do the clogging up

This is true - it's the miners who are clogging the system up by only cheery-picking the cream transaction fees all the while leaving the lesser paying transactions to wallow and even fall out of the mempool because of how much better bitcoin is to allow transactions to be ignored for so long.

How many times have we heard about the blocks with very few transactions (which incidentally are the highest paying for their ride).

Do you imagine banks would remain open if they told their customers they didn't feel like processing transactions at the moment? (Or, until the recipient of the transaction then on spent those funds and paid a higher fee to do so?)

[Wind_FURY]

did you know a service can clog the block with just 5 transactions. where if you break down the number of max sigops and work out how many outputs they can squeeze in means they can have their average 'payment' cost alot and i mean alot less than a normal person doing a 1in2out payment

But Bitcoin continues to chug along, functioning, without breaking, without network downtime. It was attacked, socially and technically, it was forked to many different forked-shitcoins, but it continues to be the most valued cryptocurrency, and the most robust network.

but bitcoin doesnt have the middle men to do the clogging up
LN has not got the same safety features.
LN is not a Push network.. its a handshake/passthe parcel network

Get the context of my post, in response to yours.

please try to learn about LN

I am the self-proclaimed, the most stupid one in the forum, but I’m insulted when you say “learn about LN” when you were the person who said that LN transactions are made of IOUs.

and stop promoting LN as if its as secure as bitcoin.. heck start by not pretending it is bitcoin.. because its not

When did I promote LN that it’s as “secure as Bitcoin”? Stop gaslighting.

[LoyceV]

LN will keep growing as you and your fractured mind are forever to be stuck in 2017

I gave up reading franky1's posts after I read this:

i personally only move my funds every 3-6 months.

It means franky1 isn't using Bitcoin for payments. That's totally fine, but please just let me be when I actually want to use Bitcoin for what it's designed to be: p2p electronic cash!

Do you imagine banks would remain open if they told their customers they didn't feel like processing transactions at the moment? (Or, until the recipient of the transaction then on spent those funds and paid a higher fee to do so?)

Fees follow pretty much the standard market mechanisms for a scarce good. Banks also reject users who don't want to pay their fees, but a better example could be a parcel business: if you pay less, your packages takes longer to reach their destination.

[Wind_FURY]

LN will keep growing as you and your fractured mind are forever to be stuck in 2017

I gave up reading franky1's posts after I read this:

i personally only move my funds every 3-6 months.

It means franky1 isn't using Bitcoin for payments. That's totally fine, but please just let me be when I actually want to use Bitcoin for what it's designed to be: p2p electronic cash!

His criticisms would have been more acceptable if he simply told the truth. Because in his posts, some criticisms are sound but with misinformation to confuse the newbies. If he had said that it’s NOT EASY to be a liquidity provider in Lightning because getting inbound channels isn’t simple, then OK. Sound argument.

[Rath_]

I would appreciate if you could move your "LN is (not) Bitcoin" discussion to a different thread. Feel free to share your concerns about the liquidity here, though.

[LoyceV]

its like having $500 in a bank.. but writing 2 cheques to two different people for $500 each and before the cheques clear (onchain confirm close session) both think they have liquidity

I'll make you a deal: you send me $500 on LN twice, and I'll send you $600 on-chain once in return. Put your money where your mouth is! Deal?

[BlackHatCoiner]

I've been reading about LN in the last days and I have some queries gathered. I guess that I should asked them here, they're probably frequently asked.

1) The entire system of the LN is based on the node's judgment, as far as I've understood. If both parties remain cooperative, including the node, then they'll successfully transact their money. If one of them becomes uncooperative, then the other party can force-close the channel and both parties will receive their analogous funds. But what happens if the node stops being cooperative? For example, if it stops being online. Isn't the node the one that keeps the channel "alive"? Without it, do both parties own their funds? Can they broadcast the final result to the blockchain?

2) What is the difference between "Close Channel" and "Force-Close Channel"? I don't get it. Is the first one executed by the node and the second one means "uncooperative broadcasting to the blockchain"?

3) Why do we need LN invoices? Couldn't this work with bitcoin addresses? The first party would simply request money on one of his/her addresses and the second one would select an output to spend.

4) Maybe the one that seems the most curious to me. Why is there a "receiving capacity"? I haven't understood this at all and why LN can't work without it. (Swaping on-chain with LN funds)

I may have more queries on my way to fully understand the way LN works, but firstly I'd like to have an answer on these four.

[vjudeu]

But what happens if the node stops being cooperative? For example, if it stops being online. Isn't the node the one that keeps the channel "alive"? Without it, do both parties own their funds? Can they broadcast the final result to the blockchain?

It depends how the channel was created and what kind of channel you have. If it is bidirectional channel, then it is possible to close the channel with some old transaction when the other party will be offline, but that will result in publishing the penalty transaction by some watchtower. But: if the channel is one-directional (or if there are two one-directional channels to allow moving funds in both directions), then broadcasting some old transaction is possible, but is not profitable, because the latest transaction gives the most coins to the other party. Also, even if some channel is bidirectional, closing it when the other party is offline would mean locking the funds for some time specified by the timelock. And that means the other party can become online and send penalty transaction, if no watchtowers were used.

2) What is the difference between "Close Channel" and "Force-Close Channel"? I don't get it. Is the first one executed by the node and the second one means "uncooperative broadcasting to the blockchain"?

If you close your channel, then both parties are online and you create a transaction that is signed by the other party. Force closing means you broadcast your closing transaction when the other party is offline or stops cooperating. And that usually means your funds are locked by some timelock, because your closing transaction may be not the last one that happened.

3) Why do we need LN invoices? Couldn't this work with bitcoin addresses? The first party would simply request money on one of his/her addresses and the second one would select an output to spend.

If you deal with address, you have to make on-chain transaction. Also, the status of the channels is changing dynamically, an invoice is temporary, it can be quickly invalid, because it depends on having sufficient liquidity on each side.

4) Maybe the one that seems the most curious to me. Why is there a "receiving capacity"? I haven't understood this at all and why LN can't work without it. (Swaping on-chain with LN funds)

If you put 1 BTC in some LN channel, then you can receive up to 1 BTC. Putting the coins in some channel creates a connection with the network, you cannot receive LN coins without having a channel (and someone has to pay for creating it). If you are paying for channel creation, then you for example receive less coins. If the sender is paying for it, then you have some debt that is paid to that sender when you use your channel. For example: in Phoenix wallet there are fees around 0.1%, they are listed explicitly in their FAQ. LN cannot work without it, because you have to put your coins inside some channel to use LN. It is related to double-spending problem. Alice with some on-chain coins could of course create off-chain transaction to Bob, but that is not enough, because Bob has no way to check that Alice did not create any transaction to Charlie before. And that is the reason why coins should be locked in channels: just to avoid double-spending attempts.

[BlackHatCoiner]

If you put 1 BTC in some LN channel, then you can receive up to 1 BTC.

On my electrum, once I opened a channel and locked all of my testnet bitcoins to a multi-signature address, it showed me that I could send up to 10 mBTC, but 0 mBTC to receive. As for the person that pays the channel, don't they both pay it? They both open a channel on the same node, and thus they both create an on-chain transaction locking funds on a multi-signature address.

Specifically, I'll have to "swap" coins in order to increase my receiving capacity. This is what I don't get. The money are on the multi-signature address and node can confirm that. Why do we differentiate "sending funds" and "receiving funds" since they're both "funds" on the same address?

Also, the status of the channels is changing dynamically, an invoice is temporary, it can be quickly invalid, because it depends on having sufficient liquidity on each side.

Doesn't the node verifies the liquidity? Why should the users do?

If you close your channel, then both parties are online and you create a transaction that is signed by the other party.

I tried closing cooperatively a channel and I received money on my wallet that closed the channel. On the other one, nothing happened. I had to cancel that too, to receive my on-chain funds.

Force closing means you broadcast your closing transaction when the other party is offline or stops cooperating. And that usually means your funds are locked by some timelock, because your closing transaction may be not the last one that happened.

Yes, but what happens if the node is uncooperative? I get it that there is no problem with the other party, I can cancel it whenever I want. Is the node necessary to force-close a channel?

[vjudeu]

it showed me that I could send up to 10 mBTC, but 0 mBTC to receive

You put your coins in the channel and all of your coins are now on your side, so you can send them to someone else. Since that moment, you can send up to 10 mBTC to someone and later receive up to 10 mBTC by using your channel. You just have one channel with 10 mBTC capacity. You can change the amount you can send or receive by making LN transactions and that will work for amounts from 0 to 10 mBTC.

As you can see, you can now receive 0 mBTC. Giving someone just your address will allow only on-chain transaction. Giving an invoice will also not work (yet), because you cannot receive any coins. But if you send some coins, you could receive them later, up to the amount you sent to someone else. LN transactions just change your sending and receiving capacity. If you send some coins, you can receive that amount from someone in the future, if you receive some coins, you can send that amount later to someone else. It is just simple addition and subtraction between your sending and receiving capacity, nothing else.

As for the person that pays the channel, don't they both pay it?

It depends, from on-chain point of view you just have one 2-of-2 multisig address that represents single channel. Who pays for what and how much? It depends on both parties agreement, they create some on-chain transaction, sign it and broadcast it. You can create a channel with a friend and have totally free transactions, you can have some channel with some HUB and agree with their fees, you can be a HUB for someone else and get some fees from your customer. As mentioned before, all such things depends directly on what kind of channel is created and what rules both sides accept.

Specifically, I'll have to "swap" coins in order to increase my receiving capacity. This is what I don't get.

Imagine that there is Alice that just put 10 mBTC in her channel. There is also Bob who also put 10 mBTC in his channel. If they both have some LN channels and there exist some path between them, they can send 5 mBTC to each other and increase their capacity in this way. Before that transaction, Alice could send 10 mBTC and receive nothing, the same for Bob. After that transaction, Alice could receive up to 5 mBTC (because she sent them to Bob), and Bob also could receive up to 5 mBTC (because he sent them to Alice). So, you start from a state where you have all of your coins on your side and you have to send something to receive it in the future.

Why do we differentiate "sending funds" and "receiving funds" since they're both "funds" on the same address?

Because all transactions are off-chain. If something is done on-chain, then it is simple, you have some address and you have some funds on that address. But if you have LN multisig address, then you can make off-chain transactions. So, from on-chain point of view there is still the same 2-of-2 multisig address, but if you did some LN transactions, then you no longer own all funds from that address. You could for example send all of your coins to someone else. On-chain you still have your 2-of-2 multisig address, but all coins from that address are no longer yours. Splitting funds to "sending" and "receiving" is needed to keep track of how many coins from each on-chain address you own.

So, at the beginning you create your channel with 10 mBTC on your side. On-chain you have one 2-of-2 multisig address and 10 mBTC amount is assigned to you. But if you swap 5 mBTC with someone else, then from on-chain point of view you own 5 mBTC from one multisig address and 5 mBTC from another multisig address. But all of such things are known only inside LN, there are no on-chain transactions, as long as they are not needed and as long as every LN user has enough coins locked in each channel.

Doesn't the node verifies the liquidity? Why should the users do?

Yes, the node simply checks if some transaction is possible or not and if everything is ok, then that transaction passes. If you have sending capacity, you can send coins. If you have receiving capacity, you can receive them. If someone does not have enough coins, that LN transaction can simply fail, that is why users should check their liquidity and have enough coins locked for sending and receiving.

I tried closing cooperatively a channel and I received money on my wallet that closed the channel. On the other one, nothing happened. I had to cancel that too, to receive my on-chain funds.

It depends how it looked like from on-chain point of view. If for example each party had its own input, then maybe there was no need of cooperation if no LN transactions were made. If you just put your coins inside LN, you sent them to some multisig address. If the other party did the same, but in separate transaction, then probably there was some separate output created. And if you closed your channel without making any LN transaction (or if all of your transactions turned you into the state where there was no need for cooperating) then each party could close the channel on its own.

Yes, but what happens if the node is uncooperative?

Then you close your channel with the latest transaction that was signed by the other party. That is enough to take your funds back, and after timelock you can just spend your coins.

Is the node necessary to force-close a channel?

The word "force" here means that there is no cooperation between parties.

[Rath_]

1) The entire system of the LN is based on the node's judgment, as far as I've understood. If both parties remain cooperative, including the node, then they'll successfully transact their money. If one of them becomes uncooperative, then the other party can force-close the channel and both parties will receive their analogous funds. But what happens if the node stops being cooperative? For example, if it stops being online. Isn't the node the one that keeps the channel "alive"? Without it, do both parties own their funds? Can they broadcast the final result to the blockchain?

If one of the nodes goes offline then the channel becomes inactive. It cannot be used for sending and routing payments in such a state. The other party can either wait for its peer to come back online or close the channel forcefully by broadcasting (the latest) commitment transaction.

A new commitment transaction is signed every time the channel is updated and at the same time both parties are supposed to share their preimage which allows the other party to revoke the previous commitment transaction and publish a penalty transaction in case the old commitment transaction is ever broadcast. A commitment transaction records the current state of the channel.

2) What is the difference between "Close Channel" and "Force-Close Channel"? I don't get it. Is the first one executed by the node and the second one means "uncooperative broadcasting to the blockchain"?

"Force-Close Channel" can be initiated at any time. Although, it doesn't make much sense to use it when the other party is cooperative because you have to wait a certain amount of time before your transaction is accepted by Bitcoin nodes. Usually, such a timelock is equal to 144 blocks (~1 day)

3) Why do we need LN invoices? Couldn't this work with bitcoin addresses? The first party would simply request money on one of his/her addresses and the second one would select an output to spend.

LN invoices contain some useful information, including a hashed "payment preimage" (see this). Actually, it is possible to send payments over the Lightning Network without a valid invoice thanks to keysend. As far as I remember, this feature is still not enabled by default in any implementation, so hardly any nodes use it.

Also, the status of the channels is changing dynamically, an invoice is temporary, it can be quickly invalid, because it depends on having sufficient liquidity on each side.

An invoice does not contain any information about the receiver's liquidity. You can generate an invoice even if you have never spent any coins over the Lightning Network.

If you put 1 BTC in some LN channel, then you can receive up to 1 BTC.

It would be actually slightly less than that. Keep in mind that both parties need to maintain a channel reserve (1-3% of the channel's capacity).

On my electrum, once I opened a channel and locked all of my testnet bitcoins to a multi-signature address, it showed me that I could send up to 10 mBTC, but 0 mBTC to receive.

That sounds about right. When you open a channel, all the funds are on your side of the channel. You won't be able to receive any coins unless you make room for them.

Specifically, I'll have to "swap" coins in order to increase my receiving capacity. This is what I don't get. The money are on the multi-signature address and node can confirm that. Why do we differentiate "sending funds" and "receiving funds" since they're both "funds" on the same address?

You don't have to swap those coins specifically. You can simply spend those coins and you should gain incoming liquidity this way.

As for the person that pays the channel, don't they both pay it? They both open a channel on the same node, and thus they both create an on-chain transaction locking funds on a multi-signature address.

As of right now, the person who initiates the channel is considered as its founder, and the founder always pays the closing transaction fee.

[Carlton Banks]

Why do we differentiate "sending funds" and "receiving funds" since they're both "funds" on the same address?

only 1 party provides funds to open the channel.

There's a new feature in c-lightning 0.10.0 that allows both parties to provide some funds to open a new channel (called "dual-funding"), which would be quite useful to create more balanced liquidity across the channels of the lightning network. Not sure if this is a part of the Lightning specification, or whether it's a c-lightning feature.

[Timelord2067]

Why do we differentiate "sending funds" and "receiving funds" since they're both "funds" on the same address?

only 1 party provides funds to open the channel.

There's a new feature in c-lightning 0.10.0 that allows both parties to provide some funds to open a new channel (called "dual-funding"), which would be quite useful to create more balanced liquidity across the channels of the lightning network. Not sure if this is a part of the Lightning specification, or whether it's a c-lightning feature.

For me the benefit of having both sides funding the opening of a channel is that both sides already have a mixture of inbound and outbound capacity.

A cafe would appreciate a customer coming in and opening a channel worth say ten cups of coffee and immediately making a LN purchase as it gives the store a small amount of initial outbound capacity.  However, (an more extreme example) a gaming site co-contributing would enable a user to collect on a one-roll play that won (think Roulette 35:1).

[LoyceV]

For me the benefit of having both sides funding the opening of a channel is that both sides already have a mixture of inbound and outbound capacity.

That's one of the reasons I like Phoenix Wallet so much: when I sent 420,000 sat, I got a channel with 420,000 sat (minus 0.1%) outgoing capacity, and also more than 200,000 sat incoming capacity. I didn't have to do anything.

A cafe would appreciate a customer coming in and opening a channel worth say ten cups of coffee and immediately making a LN purchase as it gives the store a small amount of initial outbound capacity.

Any outbound capacity the cafe needs will be to their suppliers. I don't expect the customer to bring his own node, he'll just use a light wallet. As capacity towards the customer won't be routed further, it's useless for the cafe.

I think it's much more likely the cafe will use a payment processor. For example, here are some cafes that actually accept Bitcoin and LN as payment:

They use BitKassa to handle payments, and won't have to manually deal with channel capacity.

Don't go to Arnhem now, cafes are in lockdown! That's also the reason the number of Bitcoin transactions dropped.
This graph shows LN is more popular for small in-store payments in Arnhem than on-chain Bitcoin:

[Carlton Banks]

For me the benefit of having both sides funding the opening of a channel is that both sides already have a mixture of inbound and outbound capacity.

it's a cheap way to get incoming capacity, it doesn't make a difference if you already have other channels.

And it means the in/out ratio can be balanced right from the outset, instead of paying even more sending fees to rebalance unbalanced channels

i.e. two channels, one 100% inbound and one 100% outbound could be opened instead as 1 on-chain opening tx in just one channel, with 50% inbound and 50% outbound

Any outbound capacity the cafe needs will be to their suppliers.

no it doesn't.

It's called "Lightning Network" because... it's a network. It doesn't make any difference who you have in/out bound channel capacity from/to, you can use it to pay or receive from anybody on the network (aggregate capacity needs to be enough sats for the payment, obviously)

[LoyceV]

Any outbound capacity the cafe needs will be to their suppliers.

no it doesn't.

It's called "Lightning Network" because... it's a network. It doesn't make any difference who you have in/out bound channel capacity from/to, you can use it to pay or receive from anybody on the network (aggregate capacity needs to be enough sats for the payment, obviously)

But.......... If I, a customer, open a channel to the cafe from my mobile wallet, my wallet is not a node so doesn't route other payments through my wallet. So if I pay 1 cup of coffee, the cafe can only use that capacity to pay me back my cup of coffee, right? Unless I'm mistaken here, this is how I understood it.

If I would open a channel from a well-connected node, and pay the cafe from there, I would agree the cafe can use that capacity to pay someone else again.

[Carlton Banks]

If I would open a channel from a well-connected node, and pay the cafe from there, I would agree the cafe can use that capacity to pay someone else again.

yeah, that's what I meant

I kinda agree that some people will use these LN-wallet phone apps that take care of all the balancing stuff for them, at least initially. I expect a significant slice of people will end up setting up their own node, because it's cheaper cutting out middlemen, and because people are more motivated to learn tech that involves managing their own money (it's the Bitcoin ethos, after all)

even if Phoenix/Breez etc begin to use these new cheaper dual-funded channels (which is also a lighter burden on the blockchain & utxo set...), they will still presumably charge a small premium to do so. Some people won't want to pay that.

[LoyceV]

I kinda agree that some people will use these LN-wallet phone apps that take care of all the balancing stuff for them, at least initially. I expect a significant slice of people will end up setting up their own node

I have different expectations: I expect only a small percentage to run their own node, just like only a small number of people use a full Bitcoin Core installation. Especially if LN accomplishes mass adoption, many people won't really care how it works as long as it works.

even if Phoenix/Breez etc begin to use these new cheaper dual-funded channels (which is also a lighter burden on the blockchain & utxo set...), they will still presumably charge a small premium to do so. Some people won't want to pay that.

At the moment, Phoenix is cheaper to fund than creating my own challel, and doesn't reduce the amount I can spend for a channel reserve either. I can't imagine this is sustainable as a business model, so if they change it, I might change my wallet too.

[DaveF]

At the moment, Phoenix is cheaper to fund than creating my own challel, and doesn't reduce the amount I can spend for a channel reserve either. I can't imagine this is sustainable as a business model, so if they change it, I might change my wallet too.

Depends on the business model. From what I can see if they get a lot of BTC in and open channels to a lot of other places they can charge a bit more in fees since they might be able to do transactions is less hops. IF and that is a big if they get large enough they can get enough fees to make a profit. Or they can SaaS it and sell it white label to people who want to run a node without doing the back end.

There are some other thoughts I have too on how to make a small profit doing this. Not sure it would work to run a real business.

Anyway having an odd issue with my nodes  that I have to take a look at so if anyone here has channels open to them they will be going up and down most of Easter weekend.
They yet again refuse to talk to each other. The rest of the LN world is fine, but as far as they are concerned the other one does not exist.

-Dave

[PrimeNumber7]

even if Phoenix/Breez etc begin to use these new cheaper dual-funded channels (which is also a lighter burden on the blockchain & utxo set...), they will still presumably charge a small premium to do so. Some people won't want to pay that.

At the moment, Phoenix is cheaper to fund than creating my own challel, and doesn't reduce the amount I can spend for a channel reserve either. I can't imagine this is sustainable as a business model, so if they change it, I might change my wallet too.

Phoenix has a well-connected node. They are basically forcing you to route your LN transactions through their nodes, so they receive the routing fees, and are also receiving the portion of the transaction fee that is a % of the transaction amount. Since all transactions must go through their channels, they control the fees that are paid both by you and by anyone who sends a payment to you.