Merge pull request bitcoin#623 from aantonop/rename_stories

WIP: Rename story actors: Fixes bitcoin#464 bitcoin#517 bitcoin#590
rajarshimaitra · Feb 8, 2021 · 8abe629 · 8abe629
2 parents 6b7cef9 + 40835e9
commit 8abe629
Show file tree

Hide file tree

Showing 23 changed files with 192 additions and 192 deletions.
diff --git a/01_introduction.asciidoc b/01_introduction.asciidoc
@@ -138,14 +138,14 @@ Furthermore, most legacy financial systems wouldn't even allow a nine-year old l
 By using a global currency such as bitcoin, John was able to sell his artwork to customers all over the world, store the money he's earned without a bank account and, in the end, buy the games console he so desperately wanted.
 
 gamer::
-Gloria is a teenage gamer from the Philippines. She plays many different computer games, but her favorite ones are those that have an "in-game economy" based on real money. As she plays games, she also earns money by acquiring and selling virtual in-game items. The Lightning Network allows her to transact in small amounts for in-game items as well as earn small amounts for completing quests.
+Dina is a teenage gamer from Russia. She plays many different computer games, but her favorite ones are those that have an "in-game economy" based on real money. As she plays games, she also earns money by acquiring and selling virtual in-game items. The Lightning Network allows her to transact in small amounts for in-game items as well as earn small amounts for completing quests.
 
 migrant::
 Farel is an immigrant who works in the Middle East and sends money home to his family in Indonesia. Remittance companies and banks charge high fees, and Farel prefers to send smaller amounts more often. Using the Lightning Network, Farel can send bitcoin as often as he wants, with negligible fees.
 
 software service business::
-Wei is an entrepreneur who sells information services related to the Lightning Network, as well as Bitcoin and other cryptocurrencies. Wei is selling these information services over the Internet by implementing micro-payments over the Lightning Network. Additionally, Wei has implemented a liquidity provider service that rents inbound channel capacity on the Lightning Network, charging a small bitcoin fee for each rental period.
+Chan is a Chinese entrepreneur who sells information services related to the Lightning Network, as well as Bitcoin and other cryptocurrencies. Chan is selling these information services over the Internet by implementing micro-payments over the Lightning Network. Additionally, Chan has implemented a liquidity provider service that rents inbound channel capacity on the Lightning Network, charging a small bitcoin fee for each rental period.
 
 === Chapter Summary
 
-In this chapter, we looked at the history of the Lightning Network and the motivations behind second layer scaling solutions for Bitcoin and other blockchain based networks. We learned basic terminology including node, payment channel, on-chain transactions, and off-chain payments. Finally, we met Alice, Bob, Saanvi, John, Gloria, Farel, and Wei who we'll be following throughout the rest of the book. In the next chapter, we'll meet Alice and walk through her thought process as she selects a Lightning wallet and prepares to make her first Lightning payment to buy a cup of coffee from Bob's Cafe.
+In this chapter, we looked at the history of the Lightning Network and the motivations behind second layer scaling solutions for Bitcoin and other blockchain based networks. We learned basic terminology including node, payment channel, on-chain transactions, and off-chain payments. Finally, we met Alice, Bob, Saanvi, John, Dina, Farel, and Chan who we'll be following throughout the rest of the book. In the next chapter, we'll meet Alice and walk through her thought process as she selects a Lightning wallet and prepares to make her first Lightning payment to buy a cup of coffee from Bob's Cafe.
diff --git a/channel-graph.asciidoc b/channel-graph.asciidoc
@@ -67,20 +67,20 @@ But first, how do their peers verify that the channel announcement is legitimate
 
 #### Verifying the channel
 
-Let's assume Wei receives this announcement from Bob.
+Let's assume Chan receives this announcement from Bob.
 How does he know that this is a real channel, and why should he even bother to check it?
 
 Well, verifying a channel is pretty important.
-If Wei tries to forward any payments through a channel that doesn't exist, his payments are going to fail.
-Even if the channel does exist, Wei still needs assurances that Bob and Alice actually control the funds inside of it.
+If Chan tries to forward any payments through a channel that doesn't exist, his payments are going to fail.
+Even if the channel does exist, Chan still needs assurances that Bob and Alice actually control the funds inside of it.
 Alice and Bob could potentially dupe him by claiming ownership of a channel that actually belongs to someone else.
-So Wei will definitely want to verify before he updates his channel graph.
+So Chan will definitely want to verify before he updates his channel graph.
 
-Firstly, Wei will check the channel ID to discover which Bitcoin transaction contains the channel funds.
+Firstly, Chan will check the channel ID to discover which Bitcoin transaction contains the channel funds.
 He will then look up this transaction on the Bitcoin blockchain and he should discover a P2WSH bitcoin UTXO that is signed by both Alice and Bob.
-Secondly, Wei will verify the signatures in the channel announcement message and confirm that the two nodes who signed the channel announcement are actually Alice and Bob.
+Secondly, Chan will verify the signatures in the channel announcement message and confirm that the two nodes who signed the channel announcement are actually Alice and Bob.
 Once he's done so, he's convinced that the channel is funded and that Alice and Bob are the funders and owners of that channel.
 If any of these checks fail, he'll ignore the channel announcement.
 
-Once Wei is satisfied that the channel announcement checks out, he'll update his channel graph.
+Once Chan is satisfied that the channel announcement checks out, he'll update his channel graph.
 He will also send information about this channel to his peers, and they will verify it for themselves.
diff --git a/channel-operation.asciidoc b/channel-operation.asciidoc
@@ -37,7 +37,7 @@ As the name suggests the amount is depicted in millisatoshi even those cannot be
 Still Lightning nodes keep track of subsatoshi amounts to avoid rounding issues.
 As in the offline example Alice includes the `payment_hash` in the next data field.
 This was told to Alice by Bob in case she wants to just send money to him.
-If Alice was to send Money to Gloria the payment hash would have been given to Alice by Gloria.
+If Alice was to send Money to Dina the payment hash would have been given to Alice by Dina.
 We discussed the potential of time lock or deadline of the contract.
 This is encoded in the `cltv_expiry`.
 cltv stands for OP_CHECKTIMELOCKVERIFY and is the OP_CODE that will be used in the HTLC output and serve as the deadline in which the contract is valid.
@@ -116,7 +116,7 @@ He will just not have received the funds from Alice.
 This is important!
 Despite the fact that Bob has a new commitment transaction with two valid signatures and an HTLC output inside he cannot consider his HTLC as being set up successfully.
 He first needs to have Alice invalidate her old state.
-That is why - in the case that he is not the final recipient of the funds - he should not forward the HTLC yet by setting up a new HTLC on the next channel with Wei.
+That is why - in the case that he is not the final recipient of the funds - he should not forward the HTLC yet by setting up a new HTLC on the next channel with Chan.
 Alice will not invalidate her commitment transaction yet as she has to first get her new commitment transaction and she wants Bob to invalidate his old commitment transaction which he can safely do at this time.
 
 [[routing-setup-htlc-3]]

diff --git a/code/docker/docker-compose.yml b/code/docker/docker-compose.yml
@@ -38,8 +38,8 @@ services:
       - "9735"
     restart: always
 
-  Wei:
-    container_name: Wei
+  Chan:
+    container_name: Chan
     build:
         context: eclair
     image: lnbook/eclair:latest
@@ -49,8 +49,8 @@ services:
       - "9735"
     restart: always
 
-  Gloria:
-    container_name: Gloria
+  Dina:
+    container_name: Dina
     build:
         context: lnd
     image: lnbook/lnd:latest

diff --git a/code/docker/setup-channels.sh b/code/docker/setup-channels.sh
@@ -3,35 +3,35 @@
 echo Getting node IDs
 alice_address=$(docker-compose exec -T Alice bash -c "lncli -n regtest getinfo | jq -r .identity_pubkey")
 bob_address=$(docker-compose exec -T Bob bash -c "lightning-cli getinfo | jq -r .id")
-wei_address=$(docker-compose exec -T Wei bash -c "eclair-cli -s -j -p eclair getinfo| jq -r .nodeId")
-gloria_address=$(docker-compose exec -T Gloria bash -c "lncli -n regtest getinfo | jq -r .identity_pubkey")
+chan_address=$(docker-compose exec -T Chan bash -c "eclair-cli -s -j -p eclair getinfo| jq -r .nodeId")
+dina_address=$(docker-compose exec -T Dina bash -c "lncli -n regtest getinfo | jq -r .identity_pubkey")
 
 # Let's tell everyone what we found!
 echo Alice:  ${alice_address}
 echo Bob:    ${bob_address}
-echo Wei:    ${wei_address}
-echo Gloria: ${gloria_address}
+echo Chan:    ${chan_address}
+echo Dina: ${dina_address}
 
 echo Setting up channels...
 echo Alice to Bob
 docker-compose exec -T Alice lncli -n regtest connect ${bob_address}@Bob
 docker-compose exec -T Alice lncli -n regtest openchannel ${bob_address} 1000000
 
-echo Bob to Wei
-docker-compose exec -T Bob lightning-cli connect ${wei_address}@Wei
-docker-compose exec -T Bob lightning-cli fundchannel ${wei_address} 1000000
+echo Bob to Chan
+docker-compose exec -T Bob lightning-cli connect ${chan_address}@Chan
+docker-compose exec -T Bob lightning-cli fundchannel ${chan_address} 1000000
 
-echo Wei to Gloria
-docker-compose exec -T Wei eclair-cli -p eclair connect --uri=${gloria_address}@Gloria
-docker-compose exec -T Wei eclair-cli -p eclair open --nodeId=${gloria_address} --fundingSatoshis=1000000
+echo Chan to Dina
+docker-compose exec -T Chan eclair-cli -p eclair connect --uri=${dina_address}@Dina
+docker-compose exec -T Chan eclair-cli -p eclair open --nodeId=${dina_address} --fundingSatoshis=1000000
 
-echo Get 10k sats invoice from Gloria
-gloria_invoice=$(docker-compose exec -T Gloria bash -c "lncli -n regtest addinvoice 10000 | jq -r .payment_request")
+echo Get 10k sats invoice from Dina
+dina_invoice=$(docker-compose exec -T Dina bash -c "lncli -n regtest addinvoice 10000 | jq -r .payment_request")
 
-echo Gloria invoice ${gloria_invoice}
+echo Dina invoice ${dina_invoice}
 
 echo Wait for channel establishment - 60 seconds for 6 blocks
 sleep 60
 
-echo Alice pays Gloria 10k sats, routed around the network
-docker-compose exec -T Alice lncli -n regtest payinvoice --json --inflight_updates -f ${gloria_invoice}
+echo Alice pays Dina 10k sats, routed around the network
+docker-compose exec -T Alice lncli -n regtest payinvoice --json --inflight_updates -f ${dina_invoice}
diff --git a/images/circular-rebalancing.png b/images/circular-rebalancing.png
diff --git a/images/rebalancing-1.png b/images/rebalancing-1.png
diff --git a/images/rebalancing-2.png b/images/rebalancing-2.png
diff --git a/images/rebalancing-3.png b/images/rebalancing-3.png
diff --git a/images/rebalancing-4.png b/images/rebalancing-4.png
diff --git a/images/rebalancing-5.png b/images/rebalancing-5.png
diff --git a/images/rebalancing-6.png b/images/rebalancing-6.png
diff --git a/images/rebalancing-7.png b/images/rebalancing-7.png
diff --git a/images/routing-network.png b/images/routing-network.png
diff --git a/images/routing-onion-1.png b/images/routing-onion-1.png
diff --git a/images/routing-onion-2.png b/images/routing-onion-2.png
diff --git a/images/routing-onion-3.png b/images/routing-onion-3.png
diff --git a/images/routing-onion-4.png b/images/routing-onion-4.png
diff --git a/images/routing-onion-5.png b/images/routing-onion-5.png
diff --git a/images/routing-onion-6.png b/images/routing-onion-6.png
diff --git a/node_client.asciidoc b/node_client.asciidoc
@@ -944,7 +944,7 @@ Congratulations! You have built Eclair from source and you are ready to code, te
 
 Our final example, presented in this section, will bring together all the various containers we have built to form a Lightning network made of diverse (LND, c-lightning, Eclair) node implementations. We will compose the network by connecting the nodes together and opening channels from one node to another. As the final step we route a payment across these channels.
 
-In this example, we will replicate the Lighting network example from <<routing_on_a_network_of_payment_channels>>. Specifically, we will create four Lightning nodes named Alice, Bob, Wei, and Gloria. We will connect Alice to Bob, Bob to Wei, and Wei to Gloria. Finally, we will have Gloria create an invoice and have Alice pay that invoice. Since Alice and Gloria are not directly connected, the payment will be routed as an HTLC across all the payment channels.
+In this example, we will replicate the Lighting network example from <<routing_on_a_network_of_payment_channels>>. Specifically, we will create four Lightning nodes named Alice, Bob, Chan, and Dina. We will connect Alice to Bob, Bob to Chan, and Chan to Dina. Finally, we will have Dina create an invoice and have Alice pay that invoice. Since Alice and Dina are not directly connected, the payment will be routed as an HTLC across all the payment channels.
 
 ==== Using docker-compose to orchestrate docker containers
 
@@ -991,7 +991,7 @@ services:
     container_name: Alice
 ----
 
-The fragment above defines a network called +lnnet+ and a container called +bitcoind+ which will attach to the +lnnet+ network. The container is the same one we built at the beginning of this chapter. We expose three of the container's ports allowing us to send commands to it and monitor blocks and transactions. Next, the configuration specifies an LND container called "Alice". Further down you will also see specifications for containers called "Bob" (c-lightning), "Wei" (Eclair) and "Gloria" (LND again).
+The fragment above defines a network called +lnnet+ and a container called +bitcoind+ which will attach to the +lnnet+ network. The container is the same one we built at the beginning of this chapter. We expose three of the container's ports allowing us to send commands to it and monitor blocks and transactions. Next, the configuration specifies an LND container called "Alice". Further down you will also see specifications for containers called "Bob" (c-lightning), "Chan" (Eclair) and "Dina" (LND again).
 
 Since all these diverse implementations follow the Basis of Lightning Technologies (BOLT) specification and have been extensively tested for interoperability, they have no difficulty working together to build a Lightning network.
 
@@ -1010,16 +1010,16 @@ To start the example, we switch to the directory that contains the +docker-compo
 $ cd code/docker
 $ docker-compose up
 Creating network "docker_lnnet" with the default driver
-Creating Wei      ... done
+Creating Chan      ... done
 Creating Bob      ... done
-Creating Gloria   ... done
+Creating Dina   ... done
 Creating Alice    ... done
 Creating bitcoind ... done
-Attaching to Wei, Bob, Gloria, Alice, bitcoind
+Attaching to Chan, Bob, Dina, Alice, bitcoind
 Bob         | Waiting for bitcoind to start...
-Wei         | Waiting for bitcoind to start...
+Chan         | Waiting for bitcoind to start...
 Alice       | Waiting for bitcoind to start...
-Gloria      | Waiting for bitcoind to start...
+Dina      | Waiting for bitcoind to start...
 bitcoind    | Starting bitcoind...
 
 [...]
@@ -1051,19 +1051,19 @@ $ bash setup-channels.sh
 Getting node IDs
 Alice: 02c93da7a0a341d28e6d7742721a7d182f878e0c524e3666d80a58e1406d6d9391
 Bob: 0343b8f8d27a02d6fe688e3596b2d0834c576672e8750106540617b6d5755c812b
-Wei: 03e17cbc7b46d553bade8687310ee0726e40dfa2c629b8b85ca5d888257757edc1
-Gloria: 038c9dd0f0153cba3089616836936b2dad9ea7f97ef839f5fbca3a808d232db77b
+Chan: 03e17cbc7b46d553bade8687310ee0726e40dfa2c629b8b85ca5d888257757edc1
+Dina: 038c9dd0f0153cba3089616836936b2dad9ea7f97ef839f5fbca3a808d232db77b
 
 Setting up channels...
 Alice to Bob
 
-Bob to Wei
+Bob to Chan
 
-Wei to Gloria
+Chan to Dina
 
-Get 10k sats invoice from Gloria
+Get 10k sats invoice from Dina
 
-Gloria invoice lnbcrt100u1p00w5sypp5fw2gk98v6s4s2ldfwxa6jay0yl3f90j82kv6xx97jfwpa3s964vqdqqcqzpgsp5jpasdchlcx85hzfp9v0zc7zqs9sa3vyasj3nm0t4rsufrl7xge6s9qy9qsqpdd5d640agrhqe907ueq8n8f5h2p42vpheuzen58g5fwz94jvvnrwsgzd89v70utn4d7k6uh2kvp866zjgl6g85cxj6wtvdn89hllvgpflrnex
+Dina invoice lnbcrt100u1p00w5sypp5fw2gk98v6s4s2ldfwxa6jay0yl3f90j82kv6xx97jfwpa3s964vqdqqcqzpgsp5jpasdchlcx85hzfp9v0zc7zqs9sa3vyasj3nm0t4rsufrl7xge6s9qy9qsqpdd5d640agrhqe907ueq8n8f5h2p42vpheuzen58g5fwz94jvvnrwsgzd89v70utn4d7k6uh2kvp866zjgl6g85cxj6wtvdn89hllvgpflrnex
 
 Wait for channel establishment - 60 seconds for 6 blocks
 
@@ -1077,8 +1077,8 @@ Looking inside the script, we see the part that gets all the node IDs and stores
 ----
 alice_address=$(docker-compose exec -T Alice bash -c "lncli -n regtest getinfo | jq .identity_pubkey")
 bob_address=$(docker-compose exec -T Bob bash -c "lightning-cli getinfo | jq .id")
-wei_address=$(docker-compose exec -T Wei bash -c "eclair-cli -s -j -p eclair getinfo| jq .nodeId")
-gloria_address=$(docker-compose exec -T Gloria bash -c "lncli -n regtest getinfo | jq .identity_pubkey")
+chan_address=$(docker-compose exec -T Chan bash -c "eclair-cli -s -j -p eclair getinfo| jq .nodeId")
+dina_address=$(docker-compose exec -T Dina bash -c "lncli -n regtest getinfo | jq .identity_pubkey")
 ----
 
 If you have followed the first part of the chapter you will recognise these commands and be able to "decipher" their meaning. It looks quite complex, but we will walk through it step-by-step and you'll quickly get the hang of it.
@@ -1106,38 +1106,38 @@ We do the same with the other nodes, setting up connections and channels. Each n
 To Bob's node (c-lightning) we send these commands:
 [source,bash]
 ----
-docker-compose exec -T Bob lightning-cli connect ${wei_address//\"}@Wei 
-docker-compose exec -T Bob lightning-cli fundchannel ${wei_address//\"} 1000000
+docker-compose exec -T Bob lightning-cli connect ${chan_address//\"}@Chan 
+docker-compose exec -T Bob lightning-cli fundchannel ${chan_address//\"} 1000000
 ----
 
-To Wei's node (Eclair) we send:
+To Chan's node (Eclair) we send:
 [source,bash]
 ----
-docker-compose exec -T Wei eclair-cli -p eclair connect --uri=${gloria_address//\"}@Gloria
-docker-compose exec -T Wei eclair-cli -p eclair open --nodeId=${gloria_address//\"} --fundingSatoshis=1000000
+docker-compose exec -T Chan eclair-cli -p eclair connect --uri=${dina_address//\"}@Dina
+docker-compose exec -T Chan eclair-cli -p eclair open --nodeId=${dina_address//\"} --fundingSatoshis=1000000
 ----
 
-At this point we create a new invoice for 10,000 satoshis on Gloria's node:
+At this point we create a new invoice for 10,000 satoshis on Dina's node:
 
 [source,bash]
 ----
-gloria_invoice=$(docker-compose exec -T Gloria lncli -n regtest addinvoice 10000 | jq .payment_request)
+dina_invoice=$(docker-compose exec -T Dina lncli -n regtest addinvoice 10000 | jq .payment_request)
 ----
 
 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+.
 
 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.
 
-The final command is the actual invoice payment. We connect to Alice's node and present Gloria's invoice for payment.
+The final command is the actual invoice payment. We connect to Alice's node and present Dina's invoice for payment.
 
 [source,bash]
 ----
-docker-compose exec -T Alice lncli -n regtest payinvoice --json --inflight_updates -f ${gloria_invoice//\"}
+docker-compose exec -T Alice lncli -n regtest payinvoice --json --inflight_updates -f ${dina_invoice//\"}
 ----
 
 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!
 
-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:
+Since Alice's node doesn't have a direct channel to Dina, her node has to find a route. There is only one viable route here (Alice->Bob->Chan->Dina), 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:
 
 ----
 "failure_reason": "FAILURE_REASON_NONE"