Topic: The Lightning Network FAQ - page 46. (Read 33287 times)

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.

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.

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



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)

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.

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:

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

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.

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.


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


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.


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.


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


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.


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


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

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.

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.

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.

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.

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.

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.

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.

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

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?


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

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.

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?

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.

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.

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.

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.

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.

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?

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.

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.

I gave up reading franky1's posts after I read this:
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!

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.

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


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.


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

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?)

Stop pretending every brainfart of an idea you have is Bitcoin.  It never will be.  It must grieve you tremendously to know that many people all around the world will continue their efforts working to build upon something you utterly despise, when it's unlikely a single person will ever code any of your precious ideas.  LN will keep growing as you and your fractured mind are forever to be stuck in 2017, living your sad fairytales over and over until they become the only thing you can comprehend, despite not being real.  This is literally the rest of your life now.  Lost in a dream world of your own creation.  You don't know how to move on.  Have fun with that. 

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.

Hi franky1 - I always enjoy reading your posts, they're insightful and pose the hard questions that need to be asked (sadly I can't merit you as the DT merit font trolls are on strike at the moment ^{Which in itself means they're not doing the job they signed up to do})

I've got a comment about my own observations concerning the Lightning Network.  On the block-chain, I think small value transactions with small TX fees paid are going to be sooner rather than later a thing of the past as people will either shift to another, cheaper altcoin with negligible fees, or those altcoin TX will be non-existent fees.

While I like the LN and the ease of use it promises, it's klunky at the coal face end.  (It might be good for the coders at the back-end who want to sit and watch every electron that flicker's across their computer screen, but it has a long way to go before the masses adopt it)  I've lost bitcoins via Eclair and Zap and I'm in TX limbo attempting to shift funds from one Zap wallet to a new one since the 6th of March.  (Which means I'm a glutton for punishment)

So, like other people who are buried under an ever growing list of TX that get queued ahead of their own, I was wondering (in a thought bubble kind of way) if you can explain how you would speed up transactions on the block-chain (of any price range) without having to go into a bidding war - surely a level playing field where first in, first served (and all users paying the same fare to ride the TX bus) would be a more appropriate way for the transactions to be processed?

---

---

That said:

Did you know that LN transactions look for the CHEAPEST path to the end user?  Perhaps that's why DaveF's path is seen as golden and is now well trodden - have you considered that?  (either of you?)