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

There is no reason why you could not set the base fee to zero. I am not sure if that's the case here, though.

Edit:

That 0.01% is the fee rate of Phoenix wallet isn't it? It's the percentage that the node charges for routing the payment. Besides the fee rate, there should also be a base fee. What's the base rate of each transaction charged by Phoenix wallet?

All true But: the LN fees aren't high, it's usually around 0.01% when I send a five-digit transaction (although one 2 sat transaction took 3 sat in fee). It's a lot lower than (custodial) BlueWallet, which charges 0.3 to 1% fee (and doesn't round up, so small transactions are free).
All in all I'm happy with these fees.

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.

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

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.

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.

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.