A guide to Lightning Network and LND – for new users.

In this article I will try to answer some beginner-questions, that seems to be asked time and time again. I hope that it will evolve to be a FAQ of sort, but for now it is just random bits I remember having heard asked too often.

Opening a channel.

Push amount

When opening a channel, you can specify an amount to push to the remote end, to start off with remote liquidity. What some people often do not understand, is that doing this is actually equal to giving BTC to your channel partner. Now, it may have use cases – I can see a future when, if you don’t have liquidity in your channels to pay for something, the Lightning Wallet will ask you if you want to open a channel to the remote node. If you open this with a push amount set, the receiver may accept this as the payment instead of the original invoice.  I have also seen people winning more than they can accept over LN on gambling sites – and there could be a use case for this here to (although I guess a lot of end-user wallets will be mobile, and incomning channels to a mobile device might be difficult).

Channel management

Why can’t I receive when I just opened a channel?

To receive, you’d need to have balance in the remote end. Funding the channel from your end, you will not be able to receive. This is an issue hitting a lot of beginners, who want to test out both sending and receiving, naturally.

To fix it, you have two options, you can either pay using your channel, or you can have someone create a channel to you. As Lightning Network matures, I expect we’ll see services popping up that will make this easier.

In the meantime, this actually encourages spending. Why not try some of the services at http://lightningnetworkstores.com/ ?

Why can’t I send/receive all of my channel balance?

This is because there should always be a penalty to cheat. If your channel partner publishes an old channel state, your node will automatically present a proof that he did so, and submit a different transaction to the blockchain, giving you all the funds, even your fraudulent channel partners funds. Likewise, when you are paying, your channel partners node will not allow you to spend everything, because there has to be something left as a penalty.

There are ongoing research to replace this penalty system with a system called eltoo, so the requirement for these limits may go away at a later stage.

There is also an amount of the channel balance set aside to fee for force-closing a channel. This fee will periodically be recalculated depending on the conditions of the mempool.

Inactive channel – what is it?

A lot of people ask why channels have become inactive. Should one close inactive channels? In my opinion, that might be a little rushed. An inactive channel is when your node and your channel partners node currently can’t talk to each others. Normally, you will see this when your channel partner is down, for example for maintenance. It can also be that his node isn’t up 24/7, perhaps he only run it occationally.

Inactive channels doesn’t hurt your node. In general, I’d leave them alone – also as a courtesy to your channel partner. However, if a channel have been inactive for a long time and you have a significant balance in your end that you need to use elsewhere, you may opt to close it. Rember: If you close a channel when your channel partner is not there, you’ll have to do a force-close. They are always more expensive than a cooperative close.

Inactive channels become active again when you and the remote node finds each other again, i.e. when the remote node is started up again.

Closing a channel

There are two types of channel closures: Cooperative and force-closed.

In a cooperative close, both partners are online, the channel is active, but one of the parties want to close the channel. They can then  calculate the optimal fee, fully sign a final closing transaction, and both parties gets their funds.

In a force-close, one of the channel partners decides to close the channel on-chain without waiting for the cooperation of the other node. This can happen when the other node are down, but it can also happen because your node doesn’t like the channel parameters that the other node has set. There has historically been – and still is – a lot of these issues.

In a force-close, the node closing the channel have to wait for a time – minimum a day – to get their funds back. This is because there has been a number of valid pre-signed force-close-transactions, and the channel partner node (or in the future, a watchtower node) will get some time to send a penalty transaction. Does this sound unsafe? Well, it will all happen automatically for you, and your channel partner will lose money when your node proves that he submitted an old transaction. This is because of a smart contract that says if an old transaction is submitted and someone proves it, the one who submitted the old transaction loses all his money in the channel, no matter how much balance he really had upon closing time.

There will also potentially be extra time-delays to wait for timeout of stuck payments.

Payments

What does “TemporaryChannelFailure” mean when paying an invoice?

This means that there was no liquidity to pay your invoice, somewhere on the way to the destination. Currently, you need to have the full amount ready to spend on “your” side of the channel all the way to the destination. There is ongoing work to allow splitting up a payment, and have the different parts of a payment be routed different ways across the network. This will help on this issue. Since all of this has to be done atomically, i.e. make sure you don’t end up with a payment that is paid halfway and have the other half fail, this is a bit harder than it sounds. The theory is known, though, it’s just that there is lots of work to be done on implementing and testing it in a safe way. It’s safe to retry the payment. If you can split up the payment in smaller payments, it will also help. In the future, a mechanism called AMP (Atomic Multipath Payments) will offer to do this for your automatically.

What does “UnknownNextPeer” mean?

This means that somewhere along the way, a channel has become inactive before the payment was tried routed accross it. It’s safe to try the same payment again, or try splitting up the payment so that your node has more routing options.