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
Last part of node_client: English touch ups (bitcoin#348)
- 10 cents, hence 10 satoshis (different is : a 10 cent coin, a 20 dollar suit), but in an amount: use plural: one dollar and 32 cents. Here 10,000 satoshiS (s)
- "a bunch of", very colloquial, --> "several"
- Oxford comma in list of 3 or more
- "funny" --> "unusual"
- "could" --> "can", more encouraging
- "cheap long" and "expensive short" --> add comma, comma should be placed between two adjectives of equal rank
- "it's own" (incorrect) --> its (possessive)
- "explore and dig deeper" (one does not explore deeper) --> explore further and dig deeper
Copy file name to clipboardExpand all lines: node_client.asciidoc
+17-17Lines changed: 17 additions & 17 deletions
Original file line number
Diff line number
Diff line change
@@ -1070,60 +1070,60 @@ Now that +Alice+ is connected, we open a 1,000,000 satoshi channel to +Bob+ with
1070
1070
1071
1071
We do the same with the other nodes, setting up connections and channels. Each node type has a slightly different syntax for these commands, but the overall principle is the same:
1072
1072
1073
-
To Bob's node (c-lightning), we send the command:
1073
+
To Bob's node (c-lightning) we send these commands:
1074
1074
----
1075
1075
docker-compose exec -T Bob lightning-cli connect ${wei_address//\"}@Wei
1076
1076
docker-compose exec -T Bob lightning-cli fundchannel ${wei_address//\"} 1000000
The +addinvoice+ command creates an invoice for the specified amount (in satoshis) and produces a JSON object with the invoice details. From that JSON object, we only need the actual bech32-encoded payment request, and we use +jq+ to extract it.
1091
+
The +addinvoice+ command creates an invoice for the specified amount in satoshis and produces a JSON object with the invoice details. From that JSON object we only need the actual bech32-encoded payment request, which we extract with +jq+.
1092
1092
1093
-
Next, we have to wait. We just created a bunch of channels, which means that our nodes broadcast a bunch of funding transactions. The channels can't be used until the funding transactions are mined with 6 confirmations. Since our Bitcoin regtest blockchain is set to mine blocks every ten seconds, we have to wait 60 seconds for all the channels to be ready to use.
1093
+
Next, we have to wait. We just created a bunch of channels. Hence, our nodes broadcast several funding transactions. The channels can't be used until the funding transactions are mined and collect 6 confirmations. Since our Bitcoin +regtest+ blockchain is set to mine blocks every ten seconds, we have to wait 60 seconds for all the channels to be ready to use.
1094
1094
1095
-
The final command is the actual payment. We connect to Alice's node and present Gloria's invoice for payment.
1095
+
The final command is the actual invoice payment. We connect to Alice's node and present Gloria's invoice for payment.
We ask Alice's node to pay the invoice, but also ask for +inflight_updates+ in +json+ format. That will give us detailed output about the invoice, the route, the HTLCs and the final payment result, so we can study and learn!
1101
+
We ask Alice's node to pay the invoice, but also ask for +inflight_updates+ in +json+ format. That will give us detailed output about the invoice, the route, the HTLCs, and the final payment result. We can study this additional output and learn from it!
1102
1102
1103
-
Since Alice's node doesn't have a direct channel to Gloria, her node has to find a route. There's only one viable route here (Alice->Bob->Wei->Gloria), which Alice will be able to discover now that all the channels are active and have been advertised to all the nodes by the Lightning gossip protocol. Alice's node will construct the route and create an onion packet to establish HTLCs across the channels. All of this happens in a fraction of a second and Alice's node will report the result of the payment attempt. If all goes well, you will see the last line of the JSON output showing:
1103
+
Since Alice's node doesn't have a direct channel to Gloria, her node has to find a route. There is only one viable route here (Alice->Bob->Wei->Gloria), which Alice will be able to discover now that all the channels are active and have been advertised to all the nodes by the Lightning gossip protocol. Alice's node will construct the route and create an onion packet to establish HTLCs across the channels. All of this happens in a fraction of a second and Alice's node will report the result of the payment attempt. If all goes well, you will see the last line of the JSON output showing:
1104
1104
1105
1105
----
1106
1106
"failure_reason": "FAILURE_REASON_NONE"
1107
1107
----
1108
1108
1109
-
Arguably, this is a weird message, but technically if there is no failure reason, it is a success!
1109
+
This is arguably a weird message, but the fact that there was no failure reason, in a round-about way, implies that the operation was a success!
1110
1110
1111
-
Scrolling above that funny message you will see all the details of the payment. There's a lot to review, but as you gain understanding of the underlying technology, more and more of that information will become clear. Come back to this example later.
1111
+
Scrolling above that unusual message you will see all the details of the payment. There is a lot to review, but as you gain understanding of the underlying technology, more and more of that information will become clear. You are invited to revisit this example later.
1112
1112
1113
-
Of course, you could do a lot more with this test network than a 3-channel, 4-node payment. Here are some ideas for your experiments:
1113
+
Of course, you can do a lot more with this test network than a 3-channel, 4-node payment. Here are some ideas for your experiments:
1114
1114
1115
-
* Create a more complex network by launching many more nodes of different types. Edit the +docker-compose.yml+ file and copy sections, renaming as needed.
1115
+
* Create a more complex network by launching many more nodes of different types. Edit the +docker-compose.yml+ file and copy sections, renaming containers as needed.
1116
1116
1117
-
* Connect the nodes in more complex topologies: circular routes, hub-and-spoke, full mesh
1117
+
* Connect the nodes in more complex topologies: circular routes, hub-and-spoke, or full mesh.
1118
1118
1119
1119
* Run lots of payments to exhaust channel capacity. Then run payments in the opposite direction to rebalance the channels. See how the routing algorithm adapts.
1120
1120
1121
-
* Change the channel fees to see how the routing algorithm negotiates multiple routes and what optimizations it applies. Is a cheap long route better than an expensive short route?
1121
+
* Change the channel fees to see how the routing algorithm negotiates multiple routes and what optimizations it applies. Is a cheap, long route better than an expensive, short route?
1122
1122
1123
-
* Run a circular payment from a node back to itself, in order to rebalance it's own channels. See how that affects all the other channels and nodes.
1123
+
* Run a circular payment from a node back to itself in order to rebalance its own channels. See how that affects all the other channels and nodes.
1124
1124
1125
-
* Generate hundreds or thousands of small invoices in a loop and then pay them as fast as possible in another loop. See how many transactions per second you can squeeze out of this test network.
1125
+
* Generate hundreds or thousands of small invoices in a loop and then pay them as fast as possible in another loop. Measure how many transactions per second you can squeeze out of this test network.
1126
1126
1127
1127
=== Conclusion
1128
1128
1129
-
In this chapter we looked at various projects which implement the BOLT specifications. We built containers to run complete networks and learned how to build each project from source code. You are now ready to explore and dig deeper.
1129
+
In this chapter we looked at various projects that implement the BOLT specifications. We built containers to run a sample Lightning network and learned how to build each project from source code. You are now ready to explore further and dig deeper.
0 commit comments