This thread is now self-moderated. The previous one got derailed. Please, don't discuss here whether or not the Lightning Network is a good scaling solution.If you don't know anything about the Lightning Network, consider reading "Basics of The Lightning Network" first.Table of contents 1.
Lightning basics 2.
Wallets 3.
Running a node 4.
Concerns 5.
Other questionsLightning basicsHow are coins on the Lightning Network different from the on-chain ones?They are exactly the same coins. They are stored in a multi-signature address and transactions are settled between two parties without broadcasting anything to the blockchain (except when opening and closing the channel). Every time a payment is settled, a new commitment transaction is signed. Such a transaction reflects the current state of the channel and can be broadcast if one of the participant disappears.
How many times can a payment channel be used?Payment channels can be used as long as both parties continue to cooperate with each other. Channels do not have any use or time limit.
How large is the Lightning Network?The total number of nodes, channels and network capacity has been constantly increasing for quite some time now. You can use
1ml.com to see up-to-date statistics. Keep in mind that some channels are private; they are not advertised across the network so they are not included in those stats.
How fast are Lightning Network payments?They are usually instantaneous. Although, some payments might take a few seconds if a wallet needs to try multiple different paths.
How often do payments fail?A payment fails if there is no route to the destination or if there is no enough liquidity in the channels in the selected routing path. The latter problem can be mitigated by
splitting the payment into few small chunks and sending them through different paths.
How high are transaction fees?Most channels charge a base fee and a fee proportional to the amount sent, so the larger the payment, the more you are going to pay. You should pay less than 3 satoshi for transactions <= $10 for most of the time.
Are Lightning Network payments more anonymous than on-chain transactions?Yes, Lightning Network payments are more anonymous. They use
onion routing. In short, when a payment is being routed, an intermediary node knows only the previous and the next node in the path. It is impossible to tell who initiated the payment and what the final destination is.
WalletsWhich wallet would be the best for me?There are quite a few interesting options for different kinds of users.
No-coiners:
StrikeBitcoin newbies:
BlueWalletRegular users:
Phoenix Wallet,
Breez Wallet,
Blixt WalletAdvanced users: run your own node
Electrum also has a built-in support for the Lightning Network. Make sure to read
Electrum Lightning Network walkthrough if you decide to give it a try.
Should I run my own node instead of using some wallet?You could benefit from running your own node in a few ways. Assuming that you would run your node 24/7, you would be able to receive payments at all times. Nodes can also help the network by forwarding payments. You would also be able to take advantage of advanced features like: opening multiple channels in a single transaction, dual-funding and keysend payments.
Do I have to generate an invoice every time I want to receive coins over the Lightning Network?No, invoiceless (keysend/spontaneous) payments are supported by LND and c-lightning. Most wallets do not support this feature, though.
Why can't I receive coins?First of all, the timelock is decided before the channel is established. By default, most nodes force the other peer to wait 144 blocks (~1 day). The maximum acceptable value by default is 2016 blocks (~2 weeks). I configured my node to create channels with their_to_self_delay = 432 blocks (~3 days), so if someone decides to close the channel opened to my node uncooperatively, they will have to wait 432 blocks (after the commitment transaction has been included in a block) before they can spend the output belonging to them. Those timelocks are relative which means that you do not have to sign a new commitment transaction whenever a new block is mined. New commitment transactions are signed periodically because their fees need to match the current state of the mempool. There is no point in paying 60 sat/vbyte when 1 sat/vbyte transactions are getting confirmed in just a few minutes. It also applies the other way around.
The first transaction is the commitment transaction. Let's say there's node A(lice) and node B(ob), and node A broadcasts the commitment transaction. That commitment transaction includes two outputs:
- output #0: 3 BTC (spendable by node B's private key) - reflecting node B balance
- output #1: 6 BTC (RSMC) - reflecting node A balance
There is one more important detail before we go any further. Whenever a new commitment transaction is signed, both parties exchange revocation keys for the previous commitment transaction so that they can both be sure that the other party is very unlikely to broadcast an old state of the channel.
RSMC is short for Revocable Sequence Maturing Contract. Such an output contains a relative timelock. This means that you can't spend this output until a certain amount of blocks have been mined since the transaction which includes that output was mined.
Let's say node B didn't change the default value of 144 blocks and the commitment transaction has been confirmed. There are two possible scenarios.
1) Node A attempts to cheat and broadcast an old commitment transaction. Node B has 144 blocks to spend the RSMC output using his and node A's revocation key which he got while they were working on a new commitment transaction.
2) Node A broadcasts the latest commitment transaction. In such a case, node B never got node A's revocation key for that commitment transaction, so he cannot spend that RSMC. Node A can broadcast another transaction spending that output after 144 blocks have been mined.
ConcernsIs the Lightning Network centralized?The common argument is that users are more likely to open channels to large nodes rather than small/medium ones. While that's true, as the networks continues to grow, we can expect hundreds or even thousands of nodes to concentrate end users.
This post speculates on possible types of nodes; you should read it if you are still concerned.
Can it have a negative impact on the first layer?If many channels are closed at once, the transaction fees could immediately spike and remain high for an extended period of time.
Does the Lightning Network solve Bitcoin's scalability problem?Not completely. The Lightning Network was designed mostly for micro-transactions which would not be cost-effective on the first layer. Large payments are also feasible thanks to multi-path payments. Opening a channel involves an on-chain transaction so if we expect every user to open at least one channel, the blockchain would quickly become congested for a long time. Thus, other scaling solutions are needed. Alternatively, more layers can be built on top of the Lightning Network.
What would happen if some nodes went temporarily offline?Should many large nodes go offline at the same time, payment failures might become more common. If you have only one channel and your peer goes offline then you obviously won't be able to send and receive any payments.
Other questionsWhat shops accept Lightning Network payments?Here you can find a list of merchants who accept LN payments.
Do any exchanges support the Lightning Network?Yes, the biggest exchange which supports Lightning deposits and withdrawals is
Bitfinex.
Here you can find an up-to-date list of exchanges which support the LN.
What are the upcoming features?Dual funded channels - both parties will be able to fund a channel. This feature is available in c-lightning (experimentally).
Splicing-In & Out - it will be possible to add and remove funds from existing Lightning Network channels without having to close them.
Channel factories - existing Lightning Network channels could be used for creating new channels without broadcasting anything to the Bitcoin network. Normally, a channel is opened to only one person. In channel factories, there is a group of people. Group members maintain channels between themselves. More involved users = more savings. If one of the participants is uncooperative, existing channels are not affected - new channels can't be created, though.
