@ -263,7 +263,12 @@ When new nodes join the Lightning Network they collect the channel announcements
==== Closing the channel
The best way to close a channel is... to not close it! Opening and closing channels requires an on-chain transaction, which will incur transaction fees. So it's best to keep channels open as long as possible. You can keep using your channel to make and forward payments, as long as you have sufficient capacity on your end of the channel. But even if you send all the balance to the other end of the channel, you can then use the channel to receive payments from your channel partner. This concept of using a channel in one direction and then using it in the opposite direction is called "re-balancing" and we will examine it in more detail in another chapter. By re-balancing a channel, it can be kept open almost indefinitely and used for thousands of payments.
The best way to close a channel is... to not close it!
Opening and closing channels requires an on-chain transaction, which will incur transaction fees, so it's best to keep channels open as long as possible.
An open channel can always be used to send and forward payments, as long as you have sufficient capacity on your end of the channel.
Even if you have sent all of the funds in a channel, the funds are now on the other side you can still use the channel to receive payments from your channel partner.
This concept of using a channel in one direction and then using it in the opposite direction is called "re-balancing" and we will examine it in more detail in another chapter.
By re-balancing a channel, it can be kept open almost indefinitely and used for thousands of payments.
However, sometimes closing a channel is desirable or necessary. For example:
@ -274,80 +279,112 @@ However, sometimes closing a channel is desirable or necessary. For example:
There are 3 ways to close a payment channel:
* The good way - Mutual close
* The bad way - Force close
* The ugly way - Protocol breach
* Mutual close (the good way)
* Force close (the bad way)
* Protocol breach (the ugly way)
Each of these methods is useful for different circumstances which we will explore in the next section of this chapter.
For example, if your channel partner is offline you will not be able to follow "the good way" because a mutual close cannot be done without a cooperating partner.
Usually, your Lightning Network software will automatically select the best closing mechanism available under the circumstances.
Which way you close a channel will depend on the circumstances. For example, if your channel partner is offline you will not be able to follow "the good way" because a mutual close cannot be done without a cooperating partner.
Usually, you Lightning Network software will automatically select the best closing mechanism available under the circumstances.
Whether you (the user) issue a command to close a channel or the Lightning Network software automatically closes a channel due to a detected anomaly (e.g. cheating partner), it is usually the Lightning Network software that chooses the appropriate way to close the channel.
===== Mutual close (the good way)
Mutual Close is when both channel partners agree to the closure of a channel and is the preferred method of channel close.
===== The good way - Mutual close
When you decide that you want to close a channel, your Lightning Network node will inform your channel partner about your intention.
Now both your node and the channel parter's node work together to close the channel.
No new routing attempts will be accepted from either channel partner and any ongoing routing attempts will be settled or removed after they time-out.
Finalizing the routing attempts takes time, so a mutual close can also take some time to complete.
The good way to close a channel is the mutual close and this way is always preferred, if possible. When you decide that you want to close a channel, your Lightning Network node will inform your channel partner about your intention. Now both your node and the channel parter's node work together to close the channel. No new routing attempts will be accepted from either channel partner and any ongoing routing attempts will be settled or removed after they time-out. Finalizing the routing attempts takes time, so a mutual close can also take some time to complete.
Once there are no pending routing attempts, the nodes cooperate to prepare a _closing transaction_.
This transaction is similar to the commitment transaction; it encodes the last balance of the channel but the outputs are NOT encumbered with a time lock.
Once there are no pending routing attempts, the nodes cooperate to prepare a _closing transaction_. This transaction is similar to the commitment transaction, in that it distributes the channel balance to each channel partner according to their last commitment. Unlike the last commitment transaction, the outputs are not encumbered with a time lock.
The on-chain transaction fees for the closing transaction are paid by the channel partner who opened the channel and not by the one who initiated the closing procedure.
Using the on-chain fee estimator, the channel partners agree on the appropriate fee and both sign the closing transaction.
The on-chain transaction fees for the closing transaction are paid by the channel partner who opened the channel and not by the one who initiated the closing procedure. Using the on-chain fee estimator, the channel partners agree on the appropriate fee and both sign the closing transaction.
Once the closing transaction is broadcast and confirmed by the Bitcoin network, the channel is effectively closed and each channel partner has received their share of the channel balance.
Depsite the waiting time, a mutual close is typically faster than a force close.
Once the closing transaction is broadcast and confirmed by the Bitcoin network, the channel is effectively closed and each channel partner has received their share of the channel balance. A mutual close is usually the fastest way to close a channel.
===== The bad way - Force close
===== Force close (the bad way)
Mutual close is not always possible. Sometimes, for example if your channel partner cannot be reached, you have to unilaterally close the channel in order to "free" the funds. Closing the channel unilaterally is called a _force close_. To do a force close, Alice can simply publish the last commitment transaction. After all, that's what commitment transactions are for - they offer a guarantee that Alice doesn't need to trust Bob to retrieve the balance of the channel that belongs to her.
A Force Close is when one channel partner attempts to close a channel without the other channel partner's consent.
Once Alice broadcasts the last commitment transaction she has to the Bitcoin network and it is confirmed, it will create two spendable outputs, one for Alice and one for Bob. As we discussed previously, because this commitment transaction is held by Alice, it gives a slight "advantage" to Bob. Alice's output will have a timelock delay and Bob's will be spendable immediately. This is to protect Bob, so that Alice can't broadcast an old commitment transaction and steal some of the balance. The timelock delay gives Bob the opportunity to "dispute" the transaction using the revocation secret and punish Alice for cheating.
This is usually in the case that one of the channel partners is unreachable, and so a mutual close is not possible.
In this case, you would initiate a force close to unilaterally close the channel and "free" the funds.
To initiate a force close, you can simply publish the last commitment transaction your node has.
After all, that's what commitment transactions are for - they offer a guarantee that you don't need to trust your channel to retrieve the balance of your channel.
Once you broadcast the last commitment transaction the Bitcoin network and it is confirmed, it will create two spendable outputs, one for you and one for your partner.
As we discussed previously, the Bitcoin network has no way of knowing if this was the most recent commitment transaction or an old one which was published to steal from your partner.
Hence this commitment transaction will give a slight "advantage" to your partner.
The partner who initiated the force close will their output encumbered by a timelock, and the other partner's output will be spendable immediately.
In the case that you broadcasted an earlier commitment transaction, the timelock delay gives your partner the opportunity to "dispute" the transaction using the revocation secret and punish you for cheating.
When publishing a commitment transaction during a force close, the on-chain fees will be higher than a mutual close for several reasons:
. When the commitment transaction was negotiated, the channel partners didn't know how much the on-chain fees would be at the future time the transaction would be broadcast. Since the fees cannot be changed without changing the outputs of the commitment transaction (needs both signatures) and since the force close happens when a channel partner is not available to sign, the protocol developers decided to be very generous with the fee rate included in the commitment transactions. It can be up to 5 times higher than the fee estimators suggest at the time the commitment transaction is negotiated.
. The commitment transaction includes additional outputs for any pending routing attempts (HTLCs), which makes the commitment transaction bigger than a mutual close transaction. Bigger transactions incur more fees.
. The commitment transaction includes additional outputs for any pending routing attempts (HTLCs), which makes the commitment transaction larger (in terms of bytes) than a mutual close transaction. Larger transactions incur more fees.
. Any pending routing attempts will have to be resolved on-chain causing additional on-chain transactions.
[NOTE]
====
Hash Time-Locked Contracts (HTLCs) will be covered in detail in <<htlcs>>. For now, assume that these are payments that are routed across the Ligntning Network, rather than payments made directly between the two channel partners. These HTLCs are carried as additional outputs in the commitment transactions, thereby increasing the transaction size and on-chain fees.
Hash Time-Locked Contracts (HTLCs) will be covered in detail in <<htlcs>>.
For now, assume that these are payments that are routed across the Ligntning Network, rather than payments made directly between the two channel partners.
These HTLCs are carried as additional outputs in the commitment transactions, thereby increasing the transaction size and on-chain fees.
====
In general, you should not do a "force close" unless absolutely necessary. Your funds will be locked for a longer time and the person who opened the channel will have to pay higher fees. Furthermore, you might have to pay on-chain fees to abort or settle routing attempts even if you haven't opened the channel.
In general, a force close is not recommended unless absolutely necessary.
Your funds will be locked for a longer time and the person who opened the channel will have to pay higher fees.
Furthermore, you might have to pay on-chain fees to abort or settle routing attempts even if you didn't open the channel.
If the channel partner is known to you, you might consider contacting that individual or company and inquire why their Lightning Node is down and request that they restart it so that you can achieve a mutual close of the channel.
You should consider a force close, only as the last resort.
You should consider a force close only as the last resort.
===== The ugly way - Protocol breach
===== Protocol Breach (the ugly way)
If your channel partner broadcasts an old (revoked) commitment transaction - whether deliberately or not - your node should be able to detect this protocol breach. Your node must be online and watching new blocks and transactions on the Bitcoin blockchain to detect this. Because your channel partner's payment will be encumbered by a timelock, your node has some time to act, before your channel partner can spend the payment and profit from the protocol breach.
A Protocol Breach is when your channel partner tries to cheat you, whether deliberately or not, by publishing an outdated commitment transaction to the Bitcoin blockchain, essentially initiating a (dishonest) force close from their side.
During the timelock, your node can broadcast a _punishment transaction_ that takes your own balance and uses the revocation secret to also take the balance of your channel partner.
Your node must be online and watching new blocks and transactions on the Bitcoin blockchain to detect this.
Because your channel partner's payment will be encumbered by a timelock, your node has some time to act.
You have until the time lock expires to detect a protocl breach and publish a _punishment transaction_.
If you successfully detect the protocol breach and enforce the penalty, you will receive all of the funds in channel, including your channel partner's funds.
In this scenario the channel closure will be rather fast. You will have to pay on-chain fees to publish the punishment transaction, but your node can set these fees according to the fee estimation and not overpay. Furthermore, you will be taking the funds from your channel partner's balance too, so in a way the fees are unlikely to be a factor.
In this scenario the channel closure will be rather fast.
You will have to pay on-chain fees to publish the punishment transaction, but your node can set these fees according to the fee estimation and not overpay.
You will generally want to pay higher fees to guarantee confirmation as soon as possible.
However, as you will eventually receive all of the cheater's funds, it is essentially the cheater who will be paying for this transaction.
If your node is not online and the timelock expires, your channel partner will be able to take whatever balance was allocated to them in that old commitment, perhaps as much as the entire channel balance. If there is any balance allocated to you, you will have to pay on-chain fees to collect that balance.
If you fail to detect the protocol breach and the timelock expires, you will receive only the funds allocated to you by the commitment transaction your partner published.
Any funds you received after this will have been stolen by your partner.
If there is any balance allocated to you, you will have to pay on-chain fees to collect that balance.
Also all pending routing attempts will have to be resolved just as we saw in the force close scenario.
As with a force close, all pending routing attempts will also have to be resolved in the commitment transaction.
The "ugly way" of channel closure can be executed faster than both the "good" and "bad" ways, because you can immediately publish the punishment transaction and collect all the funds.
A Protocol Breach can be executed faster than a mutual close, as you do not wait to negotiate a close with your partner, and faster than a force close as you do not need to wait for your timelock to expire.
Game theory predicts that cheating is not a successful strategy because it is easy to detect a cheater and the cheater will lose all funds committed in the channel.
Game theory predicts that cheating is not an appealing strategy because it is easy to detect a cheater, and the cheater risks losing _all_ of their funds while only standing to gain what they had in an earlier state.
Furthermore, as the Lightning Network matures, and watchtowers become widely available, cheaters will be able to be detected by a third party even if the cheated channel partner is offline.
Hence, we do not recommend cheating. We do, however, recommend that anyone catching a cheater punish them by taking their funds.
Hence, we do not recommend cheating.
We do, however, recommend that anyone catching a cheater punish them by taking their funds.
So, how do you catch a cheat or a protocol breach in your day-to-day activities?
You do so by running software that monitors the public Bitcoin blockchain for on-chain transactions that correspond to any commitment transactions for any of your channels.
This software is either:
You do so by running software that monitors the public Bitcoin blockchain for on-line transactions that correspond to any commitment transactions for any of your channels. This software is either:
* A properly maintained Lightning node, running 24x7.
* A properly maintained Lightning node, running 24/7.
* A single-purpose _watchtower_ node that you run to watch your channels.
* A third-party watchtower node that you pay to watch your channels.
We will look at watchtowers in more detail in <<watchtowers>>.
Remember that the commitment transaction has a timeout period specified in a given number of blocks, up to a maximum of 2016.
As long as you run your Lightning node once before the timeout period is reached, it will catch all cheats. It is not advisable to take this kind of risk; it is just as easy to keep a well maintained node running continuously.
Remember that the commitment transaction has a timeout period specified in a given number of blocks, up to a maximum of 2016 blocks.
As long as you run your Lightning node once before the timeout period is reached, it will catch all cheating attempts.
It is not advisable to take this kind of risk; it is just as easy to keep a well maintained node running continuously.
- Does a node need to keep up with all gossip updates? Does this change if they're a routing node or mobile client?
* Protocol Extensions via Feature Bits and TLV:
- How can the channel graph be upgraded using feature bits and TLV fields?
- How does a receiver signal that they can accept MPP/AMP payments?
* How can the channel graph be upgraded using feature bits and TLV fields?
* How does a receiver signal that they can accept MPP/AMP payments?
### What are "Zombie" channels and why do they matter?
A zombie channel can be defined as a channel in which your channel partner has been inactive for so long, that you do not expect them come back online in the future.
This could be because your channel partner has lost access to their or has permanently shut down that node.
As such, a zombie channel is technically still an open channel, but cannot be used to route payments.
Zombie channels offer no benefit to the user but have several downsides:
* Any capacity you have locked in the channel is useless for routing payments and could be allocated elsehwere
* If you lose access to your own node and restore it with only your private key, you will lose access to funds in open zombie channels
* If you lose access to your own node and restore it with your private key and channel backups, you will not be able to contact your channel partner to cooperatively close the channel and may also lose the funds
* Public zombie channels are a burden on the network, as information about them is communicated to the rest of the network, but they cannot be used to route payments
Identifying zombie channels is a challenge as it is not always clear if the channel partner is permanently offline.
A partner node that is offline for a long period may eventually return online in the future.
However, once a zombie channel is identified, it is recommended to close them and a force close is generally required.
* presentation layer, applications, how payment details are exchanged
Relevant questions to answer:
* What is BOLT 11?
* What information does an invoice contain?
* How can invoices be extended to integrate new protocol features?
* What are some unique things that can be done with LN?
* recurring payments
* donation addrs
* keysend
* custom data
- recurring payments
- donation addrs
- keysend
- custom data
=== What information does an invoice contain?
@ -76,41 +78,51 @@ If we enter the above invoice into a invoice decoding tool, such as https://lnde
=== What are some unique things that can be done with LN?
**Micropayments**: The current financial system in most countries is divisible to a certain extent and not lower (E.g. $1 = 100c).
However it is usually not viable to send small amounts, e.g. $1 and less, due to transaction fees and other friction in the system.
**Micropayments**: The currencies in most countries are divisible to a certain extent and not lower (e.g. $1 = 100c).
However, it is usually not viable to send small amounts, e.g. $1 and less, due to transaction fees and other friction in the system.
Bitcoin has similar issues due to transaction fees, and fees are likely to increase in the long-term.
The Lightning Network can reasonably accommodate payments of the value of 1 satoshi i.e. one hundred millionth of a Bitcoin.
The Lightning Network can reasonably accommodate payments of the value of 1 satoshi, i.e. one hundred millionth of a Bitcoin.
Even at an obscenely high Bitcoin value of $1m per Bitcoin, this would still allow the transfer of 1 US cent worth of value.
As many Lightning implementations track values to the thousandth of a Satoshi (i.e. one milli-satoshi), payments could conceivably be even smaller than this.
This would allow for micropayment business models such as "pay-per-article", which are not viable in the current system.
This would allow for micropayment business models such as "pay-per-article" or "pay-per-minute", which are not viable in the current financial system.
**Anonymous Payments**: Bitcoin is pseudonymous at best and transactions are permanently stored on the public Bitcoin blockchain.
Hence there is always a risk that transactions can be linked back to users post-hoc.
Hence, there is always a risk that transactions can be linked back to users post-hoc.
Technologies like CoinJoin and Pay-to-EndPoint can assist in giving Bitcoin users a greater degree of anonymity but cannot completely solve this problem.
In contrast, users of the Lightning Network are not aware of other users' payments and, since channels can be private, they may not even be aware of other users' channels.
Users are only aware of other users' payments insofar as they assist in routing payments; in this case they are unaware of both the source and the destination of the payment.
As such, the Lightning Network has a strong use case for anonymous purchases.
This would be of particular benefit to online stores and exchanges that accept Bitcoin as malicious attackers can monitor their addresses on the Bitcoin network to try and determine how much bitcoin the businesses owns; something that is not possible on the Lightning Network
As such, the Lightning Network provides for strong use cases for anonymous purchases.
This would be of particular benefit to online stores and exchanges that accept Bitcoin as malicious attackers can monitor their addresses on the Bitcoin network to try and determine how much bitcoin the businesses owns
footnote:[One variant of this is called a "dust attack", whereby an attacker can send a very small amount of Bitcoin (called a "dust output") to an address it knows is owned by a store or exchange.
By monitoring where this small amount of bitcoin moves, it can determine which other addresses the exchange to store owns.
This kind of attack is not possible on the Lightning Network].
This is not possible on the Lightning Network
**Multiplayer Games**: Lightning Payments can be integrated into online and collaborative games.
One example of this is Satoshi's Place, an online billboard where users can pay 1 satoshi to paint 1 pixel on a million pixel canvas.
What emerges is a constantly changing picture where anyone add, remove, or paint over by paying.
This example can be extended to many other kinds of collaborative games where users can pay to participate.
One example of this is _Satoshi's Place_, an online billboard where users can pay 1 satoshi to paint 1 pixel on a one-million-pixel canvas.
What emerges is a constantly changing picture, where anyone can add, remove, or paint over pixels by paying.
This example can be extended to many other kinds of collaborative games, where users can pay to participate.
The Lightning Network can also be implemented directly into online games, such as MMORPGs, to facilitate in-game transactions.
As Lightning wallets and Lightning invoices can be built directly into the games themselves, this completely bypasses the need for the credit cards and the traditional financial system.
As Lightning wallets and Lightning invoices can be built directly into the games themselves, this completely bypasses the need for credit cards and the traditional financial system.
While all of this is technically possible on Bitcoin, confirmation times and fees make this unfeasible.
Transactions are confirmed on average every ten minutes, although it could potentially take even longer.
Bitcoin transactions are confirmed on average every ten minutes, although it could potentially take even longer.
This exposes the merchant to the risk of accepting unconfirmed transactions.
Lightning transactions, on the other hand, settle instantly and so are better from a user experience standpoint for.
Lightning transactions, on the other hand, settle instantly and so are better from a user experience standpoint.
**Earning "interest" on Bitcoin trustlessly**
While Bitcoin may increase or decrease in value in terms of fiat currencies, it is an asset that does not offer a return in and off itself simply by holding it.
The amount of Bitcoin one holds remains constant, and actually decreases as one moves it around due to transaction fees.
Those wishing to earn a return on their holdings in Bitcoin terms can do so by opening channels and routing payments in return for routing fees.
In this way, users can earn a return (i.e. "interest") by locking their Bitcoin into channels and offering liquidity to other users wishing to transact on the Lightning Network.
Users doing so will need to pay the fees to open and close channels, as well as the cost of maintaining any hardware to run a Lightning Node.
However, as channels can be left open indefinitely, they could earn a profit as long as there are sufficient users of the Lightning Network such that their routing fees are in excess of their channel fees and maintenance costs over the long term.
This is trustless as users do not need to loan or send anyone their Bitcoin; they only need to take the risks of operating a Lightning node and storing Bitcoin in a hot wallet.
Third-party services exist that provide interest on Bitcoin, but these services are in general not trustless.
Those wishing to earn a return on their Bitcoin holdings _trustlessly_ can do so by opening channels and routing payments in return for routing fees.
This way, users can earn a return (i.e. "interest") by locking their Bitcoin into channels and offering liquidity to other users wishing to transact on the Lightning Network.
Users doing so will need to pay the fees to open and close channels, as well as the cost of maintaining any hardware and network infrastructure to run a Lightning Node.
However, as channels can be left open indefinitely, they _could_ earn a profit as long as there are sufficient users of the Lightning Network such that their routing fees are in excess of their channel fees and maintenance costs over the long term.
This is trustless as users do not need to loan or send anyone their Bitcoin. Users only need to take on the efforts and risks of operating a Lightning node and storing Bitcoin in a hot wallet.
**Use Cases outside of Finance**
The Lightning Network's principal object is to move payments across a network.
Could it move data other than payments across its network too? It can.
Some projects such as _Whatsat_, _Sphinx Chat_, and _Juggernaut_ are implementing instant messaging chat apps on top of the Ligtning Network.
One can imaging other types of data such as electronic tickets, QR codes, or other forms of tokens flowing across the Lightning Network as well.
The use cases are limited only by our imagination and reach beyond finance.
Lightning network capacity is the value of bitcoin locked and circulated inside Lightning Network and is the sum of capacities of each channel.
It is a mesurement of the maximum value a user can transfer in Lightning Network because routing nodes will need to have sufficient balances. It also reflects the usage of Lightning Network to some extent, because the higher value is circulated inside Lightning Network the more likely that more people are using it.
Lightning network capacity is the total amount of bitcoin locked and circulated inside the Lightning Network.
It is the sum of capacities of each public channel.
It reflects the usage of the Lightning Network to some extent because we expect that people lock bitcoin into Lightning channels in order to spend it or forward other users' payments.
Hence the higher the amount of bitcoin locked in channels, the higher the expected usage of the Lightning Network.
Note that since only public channel capacity can be observed, the true network capacity is unknown.
See private channel.
Noise_XK::
The template of the Noise protocol framework to establish an authenticated and encrypted communication channel between two peers of the Lightning Network.
@ -713,7 +713,7 @@ The main thing to watch out when running the lnd autopilot is that as soon as it
If you want to have full controll over the bitcoin transactions that you make and the channels that you open make sure to turn off the autopilot before you load your lnd wallet with bitcoin funds.
If the autopilot was previously turned on you might have to restart your lnd before you top up your wallet with an onchain transaction or before you lose channels which effectively gives you on chain funds again..
Another thing to keep in mind is to set the most important config values if you want to run the autopilot.
here you can find an example configuration:
here you can find an example configuration:
----
[lnd-autopilot]
@ -834,25 +834,62 @@ Channel rebalancing is a complex issue that is the subject of active research an
=== Routing fees
* Earning fees from routing
* Setting routing fees
* High volume/low cost vs. High cost/low volume
* Zero fee routing
Running a Lightning node allows you to earn fees by routing payments across your channels. Routing fees are generally not a significant source of income and dwarfed by the cost of operating a node. For example, on a relatively busy node that routes a dozen payments a day, the fees amount to no more than 2000 satoshis.
=== Node monitoring
Nodes compete for routing fees by setting their desired fee rate on each channel. Routing fees are set by two parameters on each channel: a fixed _base fee_ that is charged for any payment and an additional variable _fee rate_ that is proportional to the payment amount.
When sending a Lightning payment, a node will select a path so as to minimize fees, minimize hops or both. As a result, a routing fee market emerges from these interactions. There are many nodes that charge very low or no fees for routing, creating downward pressure on the routing fee "market".
If you make no choices, your Lightning node will set a default base fee and fee rate for each new channel. The default values depend on the node implementation you use. Routing fees are set as millisatoshi (thousandths of a satoshi) for the base fee and millionths per satoshi for the proportional fee rate. For example, a base fee of 1000 (millisatoshi) and fee rate of 10 (millionths) would result in the following charges for a 100,000 satoshi payment:
[latexmath]
====
P = 100,000
F_base = 1000 millisatoshi
F_rate = 10/1,000,000 * payment size
F_total = F_base + F_rate * P
\Rightarrow F_total = 1 satoshi + 100 satoshi
\Rightarrow F_total = 101 satoshi
====
Broadly speaking, you can take one of two approaches to routing fees. You can route lots of payments with low fees, making up for low fees by lots of volume. Or you can choose to charge higher fees, expecting you will route fewer payments. If you choose to set higher fees your node will be selected only when other cheaper routes don't exist. Therefore, you will route less often but earn more per successful routing.
For most nodes, it is usually best to leave the default routing fee values, so that your node is competing on a mostly level playing field with other nodes who use the default values.
You can also use the routing fee settings to re-balance channels. If most of your channels have the default fees but you want to rebalance a channel, just decrease the fees on that channel to zero or very low rates. Then sit back and wait for someone to route a payment over your "cheap" route and re-balance your channels for you as a side-effect.
=== Node management
Managing your Lightning node on the command-line is obviously not easy. It gives you the full flexibility of the node's API and the ability to write your own custom scripts to achieve whatever goals you want. But if you don't want to deal with the complexity of the command line and only need some basic node management capabilities, you should consider installing a web-based user interface that makes node management much easier.
There are a number of competing projects that offer web-based Lightning node management. Some of the most popular ones are described below.
==== Ride The Lightning (RTL)
==== RTL
Maintaining a Lightning node using the command-line can be a tedious task sometimes, fortunately we can use Ride The Lightning, most commonly known as RTL.
RTL is web graphical user interface to help users to manage lightning node operations for the three main lightning implementations (LND, c-lightning and Eclair), RTL is an open source project developed by Suheb, Shahana Farooqi and many other contributors. You can find the RTL software here:
https://github.com/Ride-The-Lightning/RTL
One of the advantages of RTL is that it can be run via a web interface.
it is implemented this way in MyNodeBTC and can be accessed using Google Chrome or Internet Explorer.
The advantage of this is that RTL can be used to operate the node remotely, such as by using a laptop or mobile phone.
Here's an example of RTL's web interface, as provided on the project repository:
.Example RTL web interface
image::images/RTL-LND-Dashboard.png[]
==== LNDMon
Lightning Labs, the makers of LND provide a web based graphical user interface called +lndmon+ to monitor the various metrics of an LND Lightning node. The lndmon interface only works with LND nodes, and is a read-only interface that does not allow you to manage the node directly (e.g. open channels and make payments). Find lndmon here:
https://github.com/lightninglabs/lndmon
==== lndash
=== Conclusion
==== External node monitors (1ml etc.)
As you grow and maintain your node you will learn a lot about the Lightning Network. It is a challenging but rewarding task. Mastering these skills will allow you to contribute to the growth and development of this technology and the Lightning Network itself. You will also gain the ability to send and receive Lightning payments with the greatest degree of control and ease, as your node will be a central part of the network's infrastructure and not just a participant on the edges.
Andreas M. Antonopoulos
4 years ago
committed by
GitHub
