Bitpie v3.9.8 now supports LApps
LApps are now available on Bitpie and we have an article for Non-tech Readers to introduce the Plainest Interpretation of Rationale of Lightning Network.
In the last few months, the discussion of lighting network is increasing sharply among the world. Especially the Lightning Torch which involves a lot of famous people, like Twitter ‘s founder Jack Dorsey, making the discussion much more influenceable. It’s inspiring because the bitcoin community made so much efforts to achieve it in the past few years .
There are several points that helped a lot in facilitating the Lighting Network works. Such as the author of Lighting Network white paper who bring the idea to the community. The lnd developed by Lighting Labs becomes the most popular way to set up a node. The long-term tech investment by the Blockstream company, including bringing in Ruby, the famous geek, to be fully devoted in the development of Lighting Network for years.
Today I am going to use a simple way to explain the Lighting Network. To help you to understand it.
Let’s assume we are playing poker cards with bitcoin together. We shall put our money on the table first. Just like we start a business with each other and we put the money into a Lightning channel. But if we pay each other in every round，it will be inconvenient and also with highly cost for paying tx fees. So, we decide to make an account to record all the payment information. And settle with each other after the last payment. In this way, we don’t need to wait for block to confirm every time and we don’t spend too much on the tx fee.
It is how it works in the really poker game. And the principle for Lightning Network is just like that. But there are serval things need to be solved. As a no need to trust, decentralized solution for transaction. How to guarantee no one is cheating on the payment? We can make it happen on the table because we know each other. But for strangers, we need a third party to help us on it. And it is hard to solve it through the Bitcoin blockchain, but it can be realized on Lightning Network.
Firstly, Let’s look at figure 1:
Let’s start with the Funding Tx, we assume Alice and Bob each put 0.5 Bitcoin in the LN channel. The LN channel is a 2/2 multisig in technological philosophy. Which means u can withdraw coins from this address only if Alice and Bob both agree to it.
Only a Funding Tx is not enough, because you cannot guarantee that you can withdraw your coins if the other one refuse to sign or he lost his private key by mistake.
So, we need to prepare a Commitment Tx. Like an unsigned tx on a multisig address for Alice and Bob to withdraw their 0.5 Bitcoin. Because it is a multisig address, means Bob shall sign and send his signature to Alice, also same as Alice. In this way, Alice and Bob both have the ability to withdraw the coins back. Thus, they don`t need to worry about any missing or regret from each other. It`s better than before.
After all of these, they can broadcast their Funding Tx on Bitcoin blockchain viz. to store coins in LN channel.
I want to explain more about the meaning of SegWit to Lightning Nerwork. First of all, SegWit solved the extension problem by take out the signature form a unsigned tx. As we already know, the Funding Tx + Commitment Tx model rely on lots of broadcast that doesn`t happened yet. If the pre-transaction hash changes the commitment Tx will be nonsense. So that is the meaning of SegWit to Lightning Network.
Now, let’s look at figure 2:
It is not enough for a Funding Tx + Commitment Tx model, a static state cannot afford all we need. We need to record all the txs.
The state was Alice (0.5 bitcoin) and Bob (0.5bitcoin) at the very beginning. Then assume Alice shall pay 0.1 bitcoin to Bob. What happens in the LN channel is transfer 0.4 bitcoin to Alice and transfer 0.6 bitcoin to Bob. A new state appears. They are capable of withdrew 0.4 and 0.6 bitcoin.
But the problems are, for Alice, she is more willing to broadcast the 0.5/0.5 tx, and Bob is willing to Broadcast the new 0.4/0.6 tx. So, we haven`t finishing yet.
Now, what we need is to do is to mark the order of this two txs. We need to discard the former tx right after the new tx is generated.
Now figure 3:
(The purple line means Alice has Bob`s signature on her hand, and she can sign to broadcast. And the blue line means the same thing that Bob can do)
The RSMC (Revocable Sequence Maturity Contract) is the key point.
The logic in picture three is if Alice want to end up the trade and broadcast the tx, she needs to broadcast C1a and RD1a to the bitcoin blockchain. Once she did it, Bob can get 0.5 bitcoin immediately, but Alice shall wait for 1,000 block to get her 0.5 bitcoin back which is stored in the RSMC.
The RSMC gives a small punishment to the person who end up the trade first. In another word, any one can cut off the LN channel without the permit of the other person. But after that, his opponent can get their money back instantly, and he need to wait for a period.
Figure 4:
Now we can refer to Figure 3 to update the state of the channel. From the state of Figure 3 to the state of Figure 4, C1a/C1b is updated to C2a/C2b, but we must discard the old state. How to do it?
In fact, we need to introduce a punishment mechanism, please see Figure 5:
Before Alice generates C2a/RD2a, she will send her private key Alice2 in C1a to Bob and Bob will send his own private key Bob2 in C1b to Alice.
In fact, here is the private key of the multi-signature address corresponding to the RSMC contract. Taking C1a as an example, Bob signed the unsigned transaction of C1a and gave it to Alice, but Bob could not broadcast C1a. Because Alice didn’t sign. In other words, only Alice can broadcast the deal. But when the channel status is updated to C2a, Alice does not dare to broadcast C1a, because before updating to C2a, she has to put the private key of RSMC in C1a (another private key) to Bob, and Bob gets the private key. If you see C1a on the Bitcoin network, it means that Alice cheats, Bob can use Alice2 private key in RSMC and his own Bob2 private key to directly take Alice’s 0.5 BTC, and Alice has to wait for 1000 blocks to take back 0.5 BTC, Bob broadcasts the trade fair, and the punishment succeeds.
And if Alice does not default on broadcasting C1a transactions (but the transaction is discarded by agreement), C1a will never appear on the Bitcoin network. Bob holds the Alice2 private key in RSMC, but it is useless because there is no coin on the address.
through this way, the channel state is finally updated from C1 to C2, Alice and Bob will never return to the previous state, because whoever goes back will be punished, the currency will be returned to the other party.
This is actually the most fundamental principle of the lightning network.
So, we can follow this rule in every game, C1 is updated to C2, C2 is updated to C3…
In the end, the results of the latter game will discard the accounts of the previous game. In the process, no one will dare to cheat because the cheater will be punished.
This is actually the basic logic of the lightning network.
Through the above introduction, you should be able to understand that for Alice and Bob, all the “credentials” (including signatures, historical private keys, etc.) sent by the other party in the lightning network channel are safe. It is very important to keep it. If you lose any credential, you will not be able to punish the other party if the other party defaults, that is, you will face asset losses.
In addition, for any party in the lightning network channel, the data on the blockchain must be kept monitored. For example, after the channel is updated to the C2 state, Bob must always monitor the data on the blockchain to see if Alice broadcast the C1a because he needs to punish Alice within a period of time after Alice broadcasts C1a, otherwise Alice’s default will be successful and Bob will face asset loss. This is actually a technical problem that needs to be solved. You need to run an SPV light node to monitor the data of the Bitcoin blockchain or rely on the Watch Towers provided by others.
Nevertheless, if a lightning network is only a 1:1 channel, it is obviously not a network.
After we understand the basic principles of the underlying payment channel of the lightning network, one of the problems now is that we can’t make all the people establish channels in pairs. First of all, from the operational point of view, it is not realistic, let alone through the above principles, both sides of the channel have to deposit a certain amount of bitcoin into the channel. If you and all the Bitcoin users have established channels, the cost is obviously unaffordable.
Therefore, it requires a network structure. For example, there is a channel between Alice and Bob. There is a channel between Bob and Carol, and between Carol and Dave. Connecting these channels together is equivalent to Alice and Dave. With a channel in between, Alice can transfer money to Dave via the lightning network.
See Figure 6 for related steps:
First, Dave prepares a random number R (other than Dave, Alice, Bob, Carol don’t know R) and computes its hash H, then gives H to Alice.
An agreement is reached between Alice and Bob. If Bob can give R within 3 days, Alice will give Bob 0.102 BTC, and if it is more than 3 days, Alice gets back the coins.
An agreement is reached between Bob and Carol. If Carol can give R within 2 days, Bob will give Carol 0.101 BTC. If it is more than 2 days, Bob gets back the coins.
Carol and Dave reached an agreement. If Dave can give R within 1 day, Carol will give Dave 0.1 BTC. If it is more than 1 day, Carol gets back the coins.
When these agreements are all established, Dave gives R to Carol, gets 0.1 BTC, Carol gives R to Bob, gets 0.101 BTC, and Bob gives R to Alice, in which he sends 0.102 BTC. In the end, Alice pays 0.102 BTC, Dave gets 0.1 BTC, and Bob and Carol get a 0.001 BTC fee.
The above logic is implemented in a lightning network by a Hashed Timelock Contract (HTLC). Bitcoin scripts are written in contracts that support HTLC.
Through the above logical description, users who understand the principle should be able to understand why the trading process of Lightning Network would be like this:
The payee prepares a QR code first, and then the payer scans the code to pay. The most important thing is that the payee needs to prepare a message first, then calculate its hash H and provide H and the public key. The payer pays with this information. This process is actually the transfer process of H, and then everyone takes R to collect the money.
In other words, the lightning network transaction must be initiated by the “recipient”, which is why users who are accustomed to Bitcoin and Ethereum wallets tend to be confused. Normally, one will say, you give me an address first, I will pay you the coins, and I can pay to this address repeatedly. I can’t do it now, I have to give you an H (plus public key) first, then you can transfer money to me through the lightning network channel. This H is only valid for a period of time, and can only be used once, to another person. At the time of the payment, I have to give another H’. I can’t take the previous H.
When we embed the HTLC contract into the RSMC channel, a more complete lightning network (multi-node model) was established. The white paper of Lightning Network spends a lot of space to describe how to realize decentralization+ trustless based on RSMC + HTLC network model.
The channel establishments and node transfer process are actually a very complicated project. In addition, for the “network” system of lightning network, it is necessary to consider things similar to node searching and routing protocols on the Internet (fee volume/channel size also affect the choice of routing) . All of these are actually a very complicated job, which is why the lightning network infrastructure has only entered into the early stage of allowing users to try and experience until today.
In the ends, we should thank the engineers who have devoted themselves into the lightning network developments, thank you!
