You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Fill in some info for the _Username_, _Title_, and _Content_ fields, then click on the **Submit** button. You will be redirected back to the screen displaying the list of posts.
25
25
26
-
.png>)
26
+
27
27
28
28
Add a couple more posts, just to have some data to play with.
29
29
30
-
.png>)
30
+
31
31
32
32
Click on the **Upvote** button on a post to see the votes counter increment and the posts reorder based on which has the highest votes.
33
33
34
-
.png>)
34
+
35
35
36
36
The app makes use of WebSockets to update the UI in real-time when posts are created and upvoted on the backend. To see this in action, open a second browser window side-by-side with the first window. Create a new post on the left to see it automatically appear on the right. Upvote a post on the right to see it increment and reorder on the left automatically.
37
37
38
-
.png>)
38
+
39
39
40
40
## Architecture
41
41
42
42
This application is split into two parts, the backend API server and the frontend browser-based UI.
Faraday comes bundled in Lightning Terminal. Meaning if you have Lightning Terminal installed, you can already access Faraday through the command line and you may skip the step below. If you want to install Lightning Terminal, [follow this guide](../lightning-terminal/).
By default, a pairing phrase created with `litcli` is valid for only 1h. You may extend this with the `--expiry <seconds>`flag.
25
+
By default, a pairing phrase created with `litcli` is valid for only 1h and is set to "readonly", meaning invoices cannot be paid or created and channels cannot be opened. You may extend this with the `--expiry <seconds>`and `--type` flags.
Copy file name to clipboardExpand all lines: lightning-network-tools/lightning-terminal/get-lit.md
+1-1
Original file line number
Diff line number
Diff line change
@@ -4,7 +4,7 @@ description: >-
4
4
integrated or remote mode.
5
5
---
6
6
7
-
# Get litd
7
+
# 🛠 Get litd
8
8
9
9
You can install `litd` from source or via the provided binary. If you are running LND as part of a software bundle like Umbrel, `litd` might already be installed on your node.
Copy file name to clipboardExpand all lines: lightning-network-tools/lnd/run-lnd.md
+1-1
Original file line number
Diff line number
Diff line change
@@ -4,7 +4,7 @@ description: >-
4
4
first steps in the Lightning Network.
5
5
---
6
6
7
-
# Get Started
7
+
# 🛠 Get Started
8
8
9
9
The Lightning Network Daemon (LND) is a complete implementation of a Lightning Network node. That means that LND is able to perform all actions necessary to participate and interact with all aspects of the Lightning Network and its nodes. It fully complies with all Lightning Network specifications (BOLTs) [as described here](https://github.com/lightningnetwork/lightning-rfc/blob/master/00-introduction.md). As these specifications are currently rapidly evolving, so is LND.
Loop comes bundled with [Lightning Terminal](../lightning-terminal/). Meaning, if you have Lightning Terminal installed, you can already access Loop through the command line and you may skip the step below. 
9
+
Loop comes bundled with [Lightning Terminal](../lightning-terminal/). Meaning, if you have Lightning Terminal installed, you can already access Loop through the command line and you may skip the step below.
10
10
11
11
\[[Follow this guide to install Lightning Terminal](../lightning-terminal/get-lit.md)]
Copy file name to clipboardExpand all lines: lightning-network-tools/pool/install.md
+13-14
Original file line number
Diff line number
Diff line change
@@ -1,16 +1,16 @@
1
-
# Installation
1
+
# 🛠 Installation
2
2
3
3
## Installation
4
4
5
-
Lightning Pool is built very similarly to [Lightning Loop](https://github.com/lightninglabs/loop): There is a process that is constantly running in the background, called the trader daemon \(`poold`\) and a command line tool to interact with the daemon, called just `pool`.
5
+
Lightning Pool is built very similarly to [Lightning Loop](https://github.com/lightninglabs/loop): There is a process that is constantly running in the background, called the trader daemon (`poold`) and a command line tool to interact with the daemon, called just `pool`.
6
6
7
-
The `poold` trader daemon can be run either as a standalone binary connected to a compatible `lnd` node or integrated into [Lightning Terminal \(LiT\)](https://github.com/lightninglabs/lightning-terminal).
7
+
The `poold` trader daemon can be run either as a standalone binary connected to a compatible `lnd` node or integrated into [Lightning Terminal (LiT)](https://github.com/lightninglabs/lightning-terminal).
8
8
9
9
### Downloading the standalone binaries
10
10
11
11
The latest official release binaries can be [downloaded from the GitHub releases page](https://github.com/lightninglabs/pool/releases).
12
12
13
-
### Downloading as part of Lightning Terminal \(LiT\)
13
+
### Downloading as part of Lightning Terminal (LiT)
14
14
15
15
To run `poold` integrated into the Lightning Terminal, download [the latest release of LiT](https://github.com/lightninglabs/lightning-terminal/releases) and follow [the installation instructions of LiT](https://github.com/lightninglabs/lightning-terminal#execution)
16
16
@@ -20,7 +20,7 @@ To build both the `poold` and `pool` binaries from the source code, at least the
20
20
21
21
To download the code, compile and install it, the following commands can then be run:
22
22
23
-
```text
23
+
```
24
24
$ git clone https://github.com/lightninglabs/pool
25
25
$ cd pool
26
26
$ make install
@@ -34,15 +34,15 @@ Lightning Pool needs to be connected to an `lnd` node version `v0.11.1-beta` or
34
34
35
35
[Installing `lnd` from source](https://github.com/lightningnetwork/lnd/blob/master/docs/INSTALL.md#installing-lnd) is also possible but needs to be done **with all sub-server build flags enabled**:
36
36
37
-
```text
37
+
```
38
38
$ make install tags="signrpc walletrpc chainrpc invoicesrpc"
39
39
```
40
40
41
41
### Running `poold`
42
42
43
43
If `lnd` is configured with the default values and is running on the same machine, `poold` will be able to connect to it automatically and can be started by simply running:
44
44
45
-
```text
45
+
```
46
46
$ poold
47
47
48
48
# Or if you want to do everything in the same terminal and run poold in the
@@ -58,17 +58,17 @@ In the case that `lnd` is running on a remote node, the `tls.cert` and the `admi
58
58
59
59
The daemon can then be configured to connect to the remote `lnd` node by using the following command line flags:
Copy file name to clipboardExpand all lines: the-lightning-network/liquidity/understanding-liquidity.md
+7-8
Original file line number
Diff line number
Diff line change
@@ -4,19 +4,19 @@ description: >-
4
4
and how you can optimize your node's liquidity.
5
5
---
6
6
7
-
# Understanding Liquidity
7
+
# ⭐ Understanding Liquidity
8
8
9
9
In the context of the Lightning Network, liquidity refers to the ability to move funds between participants on the network. Correctly defining and [managing liquidity](manage-liquidity.md) can be complex on the Lightning Network, but this complexity is rewarded by the more fluid movement of value in comparison to other systems or networks.
10
10
11
-
The same satoshis held in our node may both provide liquidity to us while simultaneously consuming the liquidity of others \(or vice versa\). In general, we should expect to be compensated for providing liquidity while paying others to provide us with liquidity. Such arrangements should be mutually beneficial. But, one of the biggest challenges of the Lightning Network is appropriately pricing liquidity and building a reliable and efficient market around it.
11
+
The same satoshis held in our node may both provide liquidity to us while simultaneously consuming the liquidity of others (or vice versa). In general, we should expect to be compensated for providing liquidity while paying others to provide us with liquidity. Such arrangements should be mutually beneficial. But, one of the biggest challenges of the Lightning Network is appropriately pricing liquidity and building a reliable and efficient market around it.
12
12
13
13
## On-chain liquidity
14
14
15
-
The liquidity of on-chain bitcoin is likely the easiest to understand. An on-chain bitcoin transaction can be moved at any time for a predictable, but varying fee. This proposed fee does not guarantee the inclusion in a block, but rather represents a bid in a perpetual auctioning process in which miners pick the highest fee paying ~2MB worth of transactions from the mempool. They are included in a block, which are created on average every 10 minutes.
15
+
The liquidity of on-chain bitcoin is likely the easiest to understand. An on-chain bitcoin transaction can be moved at any time for a predictable, but varying fee. This proposed fee does not guarantee the inclusion in a block, but rather represents a bid in a perpetual auctioning process in which miners pick the highest fee paying \~2MB worth of transactions from the mempool. They are included in a block, which are created on average every 10 minutes.
16
16
17
-
Some on-chain transactions, such as unilateral channel closures \(also called force closes\), have their own unique liquidity properties. Typically, the party initiating the force close will have to wait to spend their bitcoin, while the other side can spend their funds immediately. The length of the waiting period is defined when the channel is opened. It can range from just a day to a few weeks.
17
+
Some on-chain transactions, such as unilateral channel closures (also called force closes), have their own unique liquidity properties. Typically, the party initiating the force close will have to wait to spend their bitcoin, while the other side can spend their funds immediately. The length of the waiting period is defined when the channel is opened. It can range from just a day to a few weeks.
18
18
19
-
Such force closes may be the only way to retrieve funds from an “illiquid” channel if a peer hasn’t been online for a while. They could also be requested by the peer in case of data loss \([see static channel backup](understanding-liquidity.md)\) or they may be the result of a HTLC that has to be settled on-chain.
19
+
Such force closes may be the only way to retrieve funds from an “illiquid” channel if a peer hasn’t been online for a while. They could also be requested by the peer in case of data loss ([see static channel backup](understanding-liquidity.md)) or they may be the result of a HTLC that has to be settled on-chain.
20
20
21
21
## Different nodes for different purposes
22
22
@@ -34,7 +34,7 @@ For a node that is solely used for making payments, it may be appropriate to ope
34
34
35
35
At times, your channels will need to be replenished. It might be most cost effective to fill your channels directly via the Lightning Network, for example by earning satoshis or withdrawing BTC from exchanges using Lightning.
36
36
37
-
Alternatively, [Lightning Loop](https://lightning.engineering/loop/) is a service that allows you to send on-chain Bitcoin directly into a Lightning channel \(Loop In\). [Loop](../../lightning-network-tools/loop/) can help manage channel liquidity for those using Lightning for payments by allowing them to stay connected to the network, instead of requiring them to open new channels.
37
+
Alternatively, [Lightning Loop](https://lightning.engineering/loop/) is a service that allows you to send on-chain Bitcoin directly into a Lightning channel (Loop In). [Loop](../../lightning-network-tools/loop/) can help manage channel liquidity for those using Lightning for payments by allowing them to stay connected to the network, instead of requiring them to open new channels.
38
38
39
39
### Receiving funds
40
40
@@ -62,11 +62,10 @@ Such private channels however can be a great source of routing income, especiall
62
62
63
63
There are other cases where a routing node provides liquidity to others by locking up or committing its funds in channels with others.
64
64
65
-
A node set up primarily to receive payments might have to keep its balance low for operational reasons, and any funds forwarded into this channel might be quickly “pushed back” by the recipient \(i.e. to an exchange or to pay suppliers\).
65
+
A node set up primarily to receive payments might have to keep its balance low for operational reasons, and any funds forwarded into this channel might be quickly “pushed back” by the recipient (i.e. to an exchange or to pay suppliers).
66
66
67
67
While such a channel might appear to be unbalanced and consume significant amounts of capital, it might function as intended by providing the routing node with stable income from routing fees. Depending on the traffic to such a merchant, it may be appropriate to replace the channel with a larger or smaller one to more efficiently deploy capital.
68
68
69
69
## Identify the needs of your own node and that of your peers
70
70
71
71
The concept of liquidity is highly contextual on the Lightning Network. To ensure your node functions properly with regard to your context, its channels and peers need to be carefully managed. In addition to understanding the liquidity needs of your own node, it is also important to understand the needs of your peers, such as whether they are primarily spending, receiving or routing funds.
Copy file name to clipboardExpand all lines: the-lightning-network/multihop-payments/hash-time-lock-contract-htlc.md
+1-1
Original file line number
Diff line number
Diff line change
@@ -4,7 +4,7 @@ description: >-
4
4
are formed to create secure multi-hop transactions.
5
5
---
6
6
7
-
# Hash Time-lock Contract (HTLC)
7
+
# ⭐ Hash Time-lock Contract (HTLC)
8
8
9
9
Hash Time-lock Contracts (HTLCs) are the centerpiece of any Lightning transaction. While your Lightning Network channel is a 2-of-2 multisignature address with funds on the bitcoin blockchain, a HTLC is an output of an unconfirmed transaction to a separate “smart contract” address with the following properties:
Copy file name to clipboardExpand all lines: the-lightning-network/routing/what-makes-a-good-routing-node.md
+3-3
Original file line number
Diff line number
Diff line change
@@ -4,15 +4,15 @@ description: >-
4
4
provide five basic functions.
5
5
---
6
6
7
-
# What Makes a Good Routing Node
7
+
# ⭐ What Makes a Good Routing Node
8
8
9
9
Every channel in the network has a total capacity, limited by the amount of bitcoin committed at its creation. This balance can be held by either side of the channel, impacting its ability to pass on payments. The total capacity is the sum of the local capacity of each channel peer, or the local and remote capacity of your channel.
10
10
11
11
As a result, a route that worked for one payment might not work for the next, and the path a satoshi takes through the network might seem unpredictable. Additionally, the network is constantly changing, as balances shift, new channels are opened and old channels are closed.
12
12
13
13
Operating a good routing node does not require a highly specialized set of skills. You do not need to be a programmer, understand the details of cryptography or complex financial markets. Your Lightning routing node, however, will require plenty of close attention. While more and more software becomes available to help you gain insights into how capital is deployed and moves inside your node, a basic understanding of the command line is useful.
14
14
15
-
## Criteria of a good routing node <ahref="docs-internal-guid-dd2a34c7-7fff-95b2-e67c-77c25612a06d"id="docs-internal-guid-dd2a34c7-7fff-95b2-e67c-77c25612a06d"></a>
15
+
## Criteria of a good routing node <ahref="#docs-internal-guid-dd2a34c7-7fff-95b2-e67c-77c25612a06d"id="docs-internal-guid-dd2a34c7-7fff-95b2-e67c-77c25612a06d"></a>
16
16
17
17
A good routing node needs to fulfill a wide range of requirements.
18
18
@@ -22,7 +22,7 @@ A good routing node needs to fulfill a wide range of requirements.
22
22
4. Capitalization: Channels need to be well capitalized in order to efficiently route payments. That means they need to have sufficient capacity, with enough incoming and outgoing liquidity.
23
23
5. Buffer: Each channel needs to maintain some buffer capital, meaning a minimum balance of outgoing and incoming capacity. This is to ensure the channel is able to route at all times, as other nodes may no longer choose you as a hop if they experience routing failures due to low buffer capital.
24
24
25
-
## Allocating capital <ahref="docs-internal-guid-7be79f26-7fff-950d-8c15-8319b41bb0d4"id="docs-internal-guid-7be79f26-7fff-950d-8c15-8319b41bb0d4"></a>
25
+
## Allocating capital <ahref="#docs-internal-guid-7be79f26-7fff-950d-8c15-8319b41bb0d4"id="docs-internal-guid-7be79f26-7fff-950d-8c15-8319b41bb0d4"></a>
26
26
27
27
Generally, large channels are better for routing, but concentrating all capital into two or three large channels might be less desirable than having a greater number of small channels with the broader network.
0 commit comments