Contents: https://blog.csdn.net/qq_40452317/article/details/89646633
Excerpt from "Mastering Bitcoin"
Lightning network is a two-way end to end payment channel connection can be routed network. Such networks may allow any participant routed through one channel to another channel for payment, without need for any trusted intermediary . Lightning network for the first time described by JosephPoon and ThadeusDryja in February 2015, which is based on a lot of other people made and explained the concept of pay channels.
"Lightning Network" is a route specific payment channel network design, has been implemented by at least five different open source team. These embodiments is independent of a set of interoperability standards "technical basis Lightning" (the BOLT) described in the paper collaborate.
Lightning prototype implementation of the network have been released by several teams. Now, these implementations can run on TestNet, because they use segwit, the bit is not active in block credits backbone (mainnet).
Lightning routable network is one possible way to achieve passage of pay. There are several other design aimed at achieving similar goals, such as Teechan and Tumblebit.
Let's see how it works.
In this example, we have five players: Alice, Bob, Carol, Diana, andEric. The five participants have opened a paid channel between each other. Alice and Bob have paid channel. Bob connecting Carol, Carol connected to Diana, Diana connection Eric. For simplicity, we assume that each channel of each participant funding two Bitcoin funds, with a total capacity of each channel is 4 bits coins.
The following figure shows a series of two-way connection through the channel paid together to form a network to support a sum of lightning lightning network shows five participants from Alice to Eric's payment, payment via bilateral channels, pay from Alice to Eric (Routing pay channels (lightning network)).
Alice wants to be paid to Eric1 bits coins. However, Alice is not connected to Eric through the payment channel. Create a channel needs the funds to pay transaction, and the deal must first be submitted to the bitcoin block chain. Alice did not want to open a new payment channel and spending more fees. There is no way to indirectly pay for Eric?
The following figure shows the connection by all participants in the payment channel through a series of promises to pay HTLC process step by step route from Alice to Eric's.
Alice is running lightning network (LN) node, which is tracking its pay channel to Bob, and can find a route between the pay channel. Alice has a further node LN of Eric's ability to connect to the Internet through the node LN. Eric's LN node using a random number generator to create a secret R. Eric node does not leak the secret to anyone. Instead, Eric's secret node calculation corresponding to the hash R H, and the hash to the node of Alice.
Now Alice's node LN built route between Alice's and LN LN node node Eric's. Routing algorithm used will be explained in more detail later, but for now we assume that Alice node can find an efficient route.
Then, the node structure of a HTLC Alice, payment to the hash H, having a refund timeout time blocks 10 (current block +10), in an amount of 1.003 bits credits. Additional 0.003 will be used to pay compensation to participate in the intermediate nodes this route. This provides HTLC Alice to Bob, 1.003 deducting credits from the channel bits and Bob in the balance between, and submit it to the HTLC. The HTLC have the following meanings: "If Bob knows the secret, Alice will pay 1.003 of its channel to Bob balance, or if more than 10 blocks, Alice will be refunded the balance." Channel balance between Alice and Bob is now represented by the commitment transactions, which has three outputs: Bob 2 bits currency balance, the balance of 0.997 bits Alice's credits, in Alice's promise HTLC 1.003 bits credits. HTLC the commitment amount is subtracted from the balance of Alice's.
Bob 现在有一个承诺，如果他能够在接下来的 10 个区块生产时间内获得秘密 R， 他可以获取 Alice 锁定的 1.003。手上有了这一承诺，Bob 的节点在和 Carol 的支付通道上构建了一个 HTLC。Bob 的 HTLC 提交 1.002 比特币到哈希 H 共 9 个区块时 间，这个 HTLC 中如果 Carol 有秘密 R 她可以兑换。Bob 知道，如果 Carol 要获取他的 HTLC，她必须出示秘密 R。如果 Bob 在 9 个区块的时间内有 R，他可以用它来获取 Alice 的 HTLC 给自己。通过承诺自己的通道余额 9 个区块的时间，他也赚了 0.001 比特币。如果 Carol 无法获取他的 HTLC，并且他也无法获取 Alice 的 HTLC，那么一切都将恢复到以前的通道余额，没有人会亏损。 Bob 和 Carol 之间的通道余额现在是：2 比特币给 Carol，0.998 给 Bob，1.002 由 Bob 承诺给 HTLC。
Carol 现在有一个承诺，如果她在接下来的 9 个区块时间内获得 R，她可以获取 Bob 的锁定 1.002 比特币。现在她可以在她与 Diana 的通道上构建 HTLC 承诺。她提交 了一个 1.001 比特币的 HTLC 到哈希 H，共计 8 个区块时间，如果 Diana 有秘密 R ， 她就可以兑换。从 Carol 的角度来看，如果能够实现，她 就可以获得的 0.001 比特币，否则也没有失去任何东西。她提交给 Diana 的 HTLC， 只有在 R 被泄漏的情况下才可行，到那时候她可以从 Bob 那里索取 HTLC。Carol 和 Diana 之间的通道余额现在是：2 给 Diana，0.999 给 Carol，1.001 由 Carol 承诺 给 HTLC。
最后，Diana 可以提供给 Eric 一个 HTLC，承诺 1 比特币，7 个区块时间，到哈希 H 。Diana 与 Eric 之间的通道余额现在是：2 给 Eric，1 给 Diana，1 由 Diana 承诺给 HTLC。
然而，在这条路上，Eric 拥有秘密 R，他可以获取 Diana 提供的 HTLC。他将 R 发 送给 Diana，并获取 1 个比特币，添加到他的通道余额中。 通道平衡现在是：1 给 Diana，3 给 Eric。
现在，Diana 有秘密 R，因此，她现在可以获取来自 Carol 的 HTLC。Diana 将 R 发 送给 Carol，并将 1.001 比特币添加到其通道余额中。现 在 Carol 与 Diana 之间的通道余额是：0.999 给 Carol，3.001 给 Diana。Diana 已经 “赚了”参与这个付款路线 0.001 比特币。
通过路由回传，秘密 R 允许每个参与者获取未完成的 HTLC。Carol 从 Bob 那里获 取 1.002 个比特币，将他们通道余额设为：0.998 给 Bob，3.002 给 Carol。
最后，Bob 获取来自 Alice 的 HTLC。他们的通道余额更新为：0.997 给 Alice，3.003 给 Bob。
在没有向 Eric 打开通道的情况下，Alice 已经支付了 Eric1 比特币。付款路线中的 中间方不必要互相信任。在他们的通道内做一个短时间的资金承诺，他们可以赚 取一小笔费用，唯一的风险是，如果通道关闭或路由付款失败，退款有段短短的 延迟时间。