Skip to content

Commit 763ea48

Browse files
author
8go
authored
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
1 parent 661034a commit 763ea48

File tree

1 file changed

+17
-17
lines changed

1 file changed

+17
-17
lines changed

node_client.asciidoc

Lines changed: 17 additions & 17 deletions
Original file line numberDiff line numberDiff line change
@@ -1070,60 +1070,60 @@ Now that +Alice+ is connected, we open a 1,000,000 satoshi channel to +Bob+ with
10701070

10711071
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:
10721072

1073-
To Bob's node (c-lightning), we send the command:
1073+
To Bob's node (c-lightning) we send these commands:
10741074
----
10751075
docker-compose exec -T Bob lightning-cli connect ${wei_address//\"}@Wei
10761076
docker-compose exec -T Bob lightning-cli fundchannel ${wei_address//\"} 1000000
10771077
----
10781078

1079-
To Wei's node (Eclair), we send:
1079+
To Wei's node (Eclair) we send:
10801080
----
10811081
docker-compose exec -T Wei eclair-cli -p eclair connect --uri=${gloria_address//\"}@Gloria
10821082
docker-compose exec -T Wei eclair-cli -p eclair open --nodeId=${gloria_address//\"} --fundingSatoshis=1000000
10831083
----
10841084

1085-
Now, on Gloria's node, we create a new invoice, for 10,000 satoshi:
1085+
At this point we create a new invoice for 10,000 satoshis on Gloria's node:
10861086

10871087
----
10881088
gloria_invoice=$(docker-compose exec -T Gloria lncli -n regtest addinvoice 10000 | jq .payment_request)
10891089
----
10901090

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, 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+.
10921092

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.
10941094

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.
10961096

10971097
----
10981098
docker-compose exec -T Alice lncli -n regtest payinvoice --json --inflight_updates -f ${gloria_invoice//\"}
10991099
----
11001100

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, 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!
11021102

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:
11041104

11051105
----
11061106
"failure_reason": "FAILURE_REASON_NONE"
11071107
----
11081108

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!
11101110

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.
11121112

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:
11141114

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.
11161116

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.
11181118

11191119
* 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.
11201120

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?
11221122

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.
11241124

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.
11261126

11271127
=== Conclusion
11281128

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

Comments
 (0)