@ -18,7 +18,7 @@ In <<dina_routing_diagram>> we see a possible network layout created by various
[[dina_routing_diagram]]
.Fans connected indirectly to Dina on the Lightning Network
image:images/dina-routing-diagram.png["Fans connected indirectly to Dina on the Lightning Network"]
image::images/dina-routing-diagram.png["Fans connected indirectly to Dina on the Lightning Network"]
The nodes along the path from the fan to Dina are intermediaries and called "routing nodes" in the context of routing a payment. There is no functional difference between the "routing nodes" and the nodes operated by Dina's fans. Any Lightning node is capable of routing payments across its payment channels.
@ -70,7 +70,7 @@ As you can see in <<routing_network>>, Alice has an open channel with Bob, the c
[[routing_network]]
.A network of payment channels between Alice and Dina
image:images/routing-network.png["A network of payment channels between Alice and Dina"]
image::images/routing-network.png["A network of payment channels between Alice and Dina"]
It's possible to trace a _path_ from Alice to Dina that uses Bob and Chan as intermediary routing nodes.
Alice can then craft a _route_ from this outlined path, and use it to send a tip of a few thousand satoshis to Dina, with the payment being _forwarded_ by Bob and Chan.
@ -86,7 +86,7 @@ Assume Alice wants to give 10 gold coins to Dina, but does not have direct acces
[[alice-dina-routing-1]]
.Alice wants to pay Dina 10 gold coins
image:images/gold-coins-network1.png[]
image::images/gold-coins-network1.png[]
Alice can pay Bob to pay Chan to pay Dina, but how does she make sure that Bob or Chan don't run off with the coins after receiving them?
In the physical world contracts could be used for safely carrying out a series of payments.
@ -130,7 +130,7 @@ The difference of 1 gold coin is the fee that Bob will earn for helping out with
[[alice-dina-routing-2]]
.Alice pays Bob, Bob pays Chan, Chan pays Dina
image:images/gold-coins-network2.png[]
image::images/gold-coins-network2.png[]
As there is still the issue of trust and the risk that either Alice or Bob won't honor the contract, all parties decide to use an escrow service.
At the start of the exchange, Alice could "lock up" these 12 golden coins in escrow that will only be paid to Bob once he proves that he's paid 11 golden coins to Chan.
@ -157,7 +157,7 @@ To facilitate Alice's payment, Dina will create the payment secret and the payme
[[alice-dina-routing-3]]
.Dina sends the hashed secret to Alice
image:images/gold-coins-network3.png["Dina sends the hashed secret to Alice"]
image::images/gold-coins-network3.png["Dina sends the hashed secret to Alice"]
Alice doesn't know the secret but she can rewrite her contract to use the hash of the secret as a proof of payment:
@ -306,7 +306,7 @@ Alice visits Dina's site, enters the amount of 50,000 satoshis in a form and in
[[alice-dina-invoice-1]]
.Alice requests an invoice from Dina's website
image:images/alice-dina-invoice-1.png["Alice requests an invoice from Dina's website"]
image::images/alice-dina-invoice-1.png["Alice requests an invoice from Dina's website"]
As we saw in previous examples, we assume that Alice does not have a direct payment channel to Dina. Instead, Alice has a channel to Bob, Bob has a channel to Chan and Chan has a channel to Dina. To pay Dina, Alice must find a path that connects her to Dina. We will discuss that step in more detail in <<path_finding>>. For now, let's assume that Alice is able to gather information about available channels and sees that there is a path from her to Dina, via Bob and Chan.
@ -336,7 +336,7 @@ In <<alice_dina_invoice_2>> we see Alice getting a Lightning invoice from Dina.
[[alice_dina_invoice_2]]
.Alice gets a payment hash from Dina
image:images/alice-dina-invoice-2.png["Alice gets a payment hash from Dina"]
image::images/alice-dina-invoice-2.png["Alice gets a payment hash from Dina"]
In the Lightning Network, Dina's payment pre-image won't be a phrase like "Dina's secret", but a random number generated by Dina's node. Let's call that random number +R+.
@ -433,7 +433,7 @@ Alice will now extend the HTLC across the network so that it reaches Dina.
[[alice_dina_htlc_1]]
.Propagating the HTLC across the network
image:images/alice-dina-htlc-1.png["Propagating the HTLC across the network"]
image::images/alice-dina-htlc-1.png["Propagating the HTLC across the network"]
In <<alice_dina_htlc_1>> we see te HTLC propagated across the network from Alice to Dina. Alice has given Bob an HTLC for 50,200 satoshi. Bob can now create an HTLC for 50,100 satoshi and give it to Chan.
@ -451,7 +451,7 @@ Once Dina receives a 50,000 HTLC from Chan, she can now get paid. Dina could sim
Notice Dina's channel balance goes from 50,000 satoshi to 100,000 satoshi. Chan's channel balance is reduced from 200,000 satoshi to 150,000 satoshi. The channel capacity hasn't changed, but 50,000 has moved from Chan's side of the channel to Dina's side of the channel.
@ -459,7 +459,7 @@ Chan now has the secret and has paid Dina 50,000 satoshi. He can do this without
Chan has paid Dina 50,000 satoshi, and received 50,100 satoshi from Bob. So Chan has 100 satoshi more in his channel balances, which he earned as a routing fee.
@ -467,7 +467,7 @@ Bob now has the secret too. He can use it to spend Alice's HTLC on-chain. Or, he
Andreas M. Antonopoulos
3 years ago