Explain why Bitcoin needs lightning network with the example of Bar Judy

There have been a lot of "eye-catching" events in the circle recently, but what impact will they have on the entire ecology?

I don't think it is necessary to lengthen the time dimension, and technological progress is the key factor.

Today's article is one of the hottest posts in Reddit last week. It uses very popular examples to explain why Bitcoin needs a lightning network and how bitcoin payments are gradually improving.

The article is very long, it is recommended to look at the code first, enjoy~

• Don't wait! The altcoin spring will not come
• A paper on the cryptocurrency mining industry panorama
• USDT, the invisible sword of Damocles

1

The first generation: Nakamoto's broken nSequence channel

Although Satoshi Nakamoto made the product, but the version of Nakamoto Satoshi (including the payment channel) is too bad. We had to fix it ourselves, and by the way added RBF (translator-by-fee, allowing the payment of higher transaction fees to replace the unconfirmed same transaction) as an incidental feature.

The first rule is that if the input to the A transaction is the same as the B transaction, and the nSequence of A is larger, then the memory pool will replace B with A.

0xFFFFFFFF is the maximum value that nSequence can take, which causes the transaction to be marked as "final transaction" and cannot be replaced in the memory pool.

nLockTime and nSequence are the reasons why the "nSequence channel" has such a strange rule. nLockTime can only work if nSequence is less than 0xFFFFFFFF. If nSequence is 0xFFFFFFFF, nLocktime will not work.

Give a simple example:

1. You go to a bar and say to the bartender that you will check out when the bar is closed. Because we are in the Bitcoin universe, time is measured in the form of block height, so the bar closing time is the height of a block in the future.

2. When you drink the first drink, you will take a sum of money from your funds and make a transaction to the bartender. The deal has an nSequence starting at 0 and an nLocktime (equivalent to the closing time of the bar). You create this deal and the bartender gives you the wine.

3. If you want to drink a few more cups, you need to recreate a similar transaction and add the extra money to the bartender's transaction (so as the amount of money increases, the output of the transaction grows larger), but this The nSequence of the pen transaction is increased by one compared to the original one.

4. In any case, you may end up leaving the bar for two reasons:

(1) The bar is closed. When the closing time of the nLockTime mark is reached, the bartender can broadcast the latest transaction, and then the security guard will kick you out.

(2) You don't want to drink any more, so you re-sign the latest transaction nSequence to 0xFFFFFFFF, which is the maximum value it can reach. This allows the bartender to get his money immediately (if nSequence is 0xFFFFFFFF, nLocktine will no longer work), so he can let the security politely send you out the door.

This is the payment channel, which is closed by creating a "final" transaction that includes the previous transaction. There is of course no rounting here, because the channel is unidirectional and has a maximum life cycle limit. But still letting Nakamoto go to school, he needs a break, and he is busy inventing bitcoin at that time.

Remember that I said that this payment channel is broken?

This is because the memory pool rules are not consensus rules and cannot be verified (anything in the memory pool can't be verified on the chain, whenever I hear someone ask "Let's determine the block size based on the size of the memory pool!" I have to sigh, the state of the memory pool can not be verified by the data on the chain). All nodes can't see all the transactions you signed, only the one with the largest nSequence is actually used in the chain.

So you can do this like this:

1. Become a friend of Wu Jihan because he has more than 51% of computing power.

2. Give Wu Jihan some of your wine as a reward for working with you. For example, if you have set a hundred glasses of wine, you and Wu Jihan will divide the wine and give him 50 cups.

3. When the bar closed, Wu Jihan let his mining machine dig nSequence to 0. That is the deal you paid for only one drink.

4. Because there is no way for the whole node to verify nSequence, they will accept the version of nSequence=0 and then confirm that it is silly to write the money for only one glass of wine into the blockchain.

5. The bartender was irritated. He took a gun from under the bar and wanted to kill you and Wu Jihan.

6. Wu Jihan uses his magical power (in fact, the steam of the mining machine) to slow down the bullets. As a result, the bullets just touched you like a wind-blown petal.

7. The bartender muttered incomprehensibly, suddenly his clothes were torn open, and he really became a bear!

8. You stare at it, thinking that Leonardo can survive from the bear's claws, then you can survive, and he is just a rich actor, then you pose and shout "Eat me!"

9. Can someone continue to help me edit it? Here are the knowledge points:

1. It’s very bad to meet bears.

2. You can't just deny it because the lightning network is not on the chain, and then enable the so-called "Zhongben Cong version."

The Nakamoto version is a semi-finished product with nSequence payment channel. In this scenario, the chain transaction represents the sum of multiple logical transactions, which is almost the same as the modern version of the chain technology (no matter the modern chain) How does the technology work?) nSequence (single-finger this field, not referring to its modern meaning) existed as early as Windows Alpha 0.1.0.

3. The miner is completely able to bypass the memory pool rules. In fact, nSequence can be turned into an optional function (RBF) because the miners are motivated by the nSequence system to comply with the RBF rules.

What I mean is that you give Wu Jihan's wine, in addition to the commission that you can dig a specific version of the trade to the miners, what else can it be?

4. Satoshi Nakamoto will also make mistakes, and the original nSequence design is one of them. Today, we no longer use nSequence like this.

Improving the original version of Nakamoto was part of the development of Bitcoin, because as time went on, we learned something that Nakamoto would never know . Nakamoto is a milestone in this technology. But he will never be the last one, nor will he be the most important one. He will be remembered by history, but only as a pioneer.  

2

Spilman channel

The Spilman channel is an excitation-compatible, time-limited unidirectional channel that is actually an improved version of the Nakamoto channel.

Now, we know that if you want to cheat on the trading channel, the bartender will become a bear biting you. And we know that you are a good friend of Wu Jihan, and the bartender will no longer accept a payment channel solution that allows customers and miners to join forces to deceive.

The good news is coming, Jeremy Spilman has proposed a new program that allows customers to deceive the bartender again. First, you and the bartender perform a ceremony like this:

1. You take out some money and then create a capital injection transaction to pay a 2/2 multi-signature address between you and the bartender. You will not broadcast the deal now: you just signed it and got the deal ID.

2. You create another transaction to return the funds. The deal has an nLocktime whose value is the closing time of the bar plus a block height. You sign it and then give the bartender the deal (but not the capital injection mentioned above) to the bartender.

3. The bartender signs the refund transaction and returns it to you. It is now legal because you and the bartender are signed.

4. Now you broadcast the first transaction to the chain. You and the bartender wait for the depth of the transaction to be confirmed, and then you start spending again. The above steps may be somewhat familiar to Lightning Network users. This is the fund creation process for the payment channel! The first payment to the 2/2 multi-signature address is used to fund the channel.

Then you start to buy wine like this:

1. The first glass of wine, you create an output that costs the capital injection (that is, the first transaction), send the cost of the wine to the bartender, and then return the rest to you.

2. You sign the deal and hand it over to the bartender, and the bartender will give you the first drink.

3. In order to get another glass of wine, you have to create a similar transaction, first add the money of the new wine to the money given to the bartender, and then return the remaining money to you. You sign the deal and send it to the bartender, and the bartender will give you another cup.

4. To the end:

(1) If the time for the hotel to close is up, the bartender will sign the latest transaction, complete the required double signature and then broadcast the transaction to the Bitcoin network. Because the time for the refund transaction is the broadcast time is +1, it cannot be used until the door is closed.

(2) If your liver can't stand it, so you want to leave early, you just need to tell the bartender to close the channel (the bartender can broadcast the latest version of the transaction at any time to close the channel, the bartender does not do this because I hope you can After a while, drink two more cups).

(3) If you are just hanging out in the bar but never buying anything, then when the closing time is +1, you will broadcast your refund transaction and get back all your funds.

Now, even if you give Wu Jihan 50 cups of wine, you can't let him dig the first transaction (the transaction only pays for a cup of wine), because this is a 2/2 multi-signature address but It only has your own signature.

You need the signature of the bartender to make the deal legal, but of course he won't be so stupid, the bartender will not give his signature to make the old version of the transaction legal and get less money.

So the problem is solved, right? already settled? Let's try it. You got your money, put them into a capital injection transaction, made a refund transaction, confirmed the capital injection transaction…

Once the depth of the capital injection transaction is confirmed, the bartender has a deep smile. He called the security guard and stared at you with imposing manners.

"I refuse to serve you," said the bartender.

"Well, then I am going well." You smirked. "I will use the refund transaction to get my money back, and then give you a bad review on the public comment!"

"Don't worry," said the bartender. His voice makes your back chill, just like he remembers the things you played with him before, "I just confirmed the transaction ID of the capital injection transaction."

“Is it okay?” you asked without fear, saying that you opened your laptop and found a reliable blockchain browser.

The next thing I saw scared you.

"What's wrong? The transaction ID has changed?! You fucked my signature?? How? Maybe I hid my only private key in a sealed envelope and put it in a mysterious Gobi desert. In the safe, a group of brave nomads guarded it. They swear by the blood of their children and swear to defend this secret!"

"Don't you know?" The bartender smiled. "Signatures are just very large numbers. A tag in a signature can be changed from positive to negative, or from negative to positive, but the signature is still legal. Even if you don't know the private key, anyone can do this. But Bitcoin contains the signature in the transaction ID, so this small change also changes the transaction ID. Someone wants to separate the signature from the transaction subject, they say that signature malleability will no longer be It affects the transaction ID, but I bet I can let my good buddy Wu Jihan delay this 'Sepsig' (separate signature) plan for a long time.

Wu Jihan is a good person. As long as I give him 51 glasses of beer, he is willing to dig the changed transaction. "He laughs even happier." I am afraid that your refund transaction will not work because it wants to spend the same. The transaction ID does not exist at all.

Ok, let's talk about it. You give me 99% of the funds in your capital injection transaction. In exchange, I will sign your transaction on the chain. If you refuse, then you have nothing left. But I and all HODLers will have some cheers because of circulation. You can get 1% of the money to accept this deal. If you reject me, I will not lose it, so think about it! His eyes were greedy.

What have you learned?

(1) Retaliation is very bad.

(2) Trade scalability is even worse. This is why we have to fix this bug in the isolation testimony. MtGox claims that they have been attacked by this kind of vulnerability. Some people have been messing up the signatures of their transactions, causing them to go to the funds for repeated withdrawals, but the main reason for repairing the transaction is to support the payment channel.

(3) Including the signature into the hash, and finally determining the design of the transaction ID is an error. Nakamoto has made many such mistakes. We must reiterate that "Zhong Bencong is not a Tianlong person with infinite wisdom."

3

CLTV protected Spilman channel

Use CLTV to make a refund branch.

The difference between this and the Spilman channel is that the refund transaction is replaced by a refund branch. This scheme is only possible after OP_CHECKLOCKTIMEVERIFY (CLTV) is enabled in 2015.

As we discussed in the Spilman channel, transaction extensibility causes any transaction that is pre-registered under the chain to invalidate a pre-registered transaction by altering the signature of the capital injection transaction when the capital injection transaction is not confirmed.

This can be avoided by simply adding some special requirements to the specific branch in the Bitcoin script. Now, the refund branch can create a maximum lifecycle for the payment channel. Through our previous introduction to OP_CHECKLOCKTIMEVERIFY, we know that this is only possible when there is a pre-registered nLockTime.

With CLTV, we can add a lot of branch judgments to the scripts you want to pay to make it avoid the above problem.

In order to set up a capital injection transaction, you don't have to pay a 2/2 address anymore. You now have to pay for a script. This script is basically equivalent to a 2/2 at the beginning but after a while Single signed address. This eliminates the need for pre-registered transactions.

You can create your refund transaction later using the transaction ID of any confirmed capital injection transaction. Since the capital injection transaction has been confirmed, it is impossible to change the transaction ID.

4

Todd micro payment network

The most direct predecessor of Lightning Network is the hub-spoke mode introduced by Peter Todd.

In this mode, the payer and the payee are not directly connected, and both the payer and the payee are connected to the previous hub.

This allows any payer to pay to any payee using the same payment channel on the hub. Similarly, it also allows any payee to use the same channel to receive payments from any payer.

Remember the previous example of Spilman? When you open a channel to the bartender, you must wait for the capital injection transaction to confirm. This can take an hour. Imagine you need to open a channel with everyone you want to pay. This is not scalable.

So the hub-spoke model has a clearing house that transfers funds from the payer to the payee. The "Moonbeam" project has adopted this model. Of course, this mode hub will know who is the payer and the payee, so the hub has the ability to review the transaction. Of course, usually the way the hub is more efficient is to stop maintaining the channel of the payer and the payee it wants to review (because if the hub does not process the transaction, the funds in the channel can only be locked in it. Useless).

The ability to monitor payments means that hubs can sell private transaction data for profit. Today, this kind of damage to privacy is intolerable.

Another point worth noting is that if such a network is really being promoted on a large scale, it has only one-way channels available. But a person may be a payer or a payee, you need to create a separate payment channel and payment channel. To make matters worse, if you want to transfer money from the collection channel to the payment channel, you need to turn them off and then open them again on the chain.

5

Poon-Dryja Lightning Network

Poon-Dryja is a two-way, two-participating channel.

The mechanism of the Poon-Dryja channel has two important changes: two-way and no time limit.

The original Nakamoto version and the Spilman variant are one-way: there are two different parties, the payer and the payee, if the payee wants a refund, or the payee wants to buy a payer They can't use the same channel either.

The Poon-Dryjam mechanism can make the channel two-way. You are not just a payer or payee. As long as your opponent is online, you can collect and pay at will.

Furthermore, unlike the Spilman variant, there is no time limit for the channel. You can keep the channel until you want it.

These two characteristics, together, form a powerful expansion that most people don't realize. In a one-way payment channel, you need to open a separate channel for collecting and paying. You need to perform operations on the chain periodically to "reverse" the direction of the payment channel. Second, because the Spilman channel has a fixed life cycle, you must periodically close and reopen the channel.

With a two-way, infinite lifecycle channel, you may only need to trade two links in your life, once when you open the channel, once during your legacy. This is the power of this channel.

I won't be explaining the trading structure of the Poon-Dryja two-way channel, it's complicated, and you can find simple and easy-to-understand icons elsewhere to figure out its mechanics.

Let's talk about some of the shortcomings that the Poon-Dryja channel often overlooks (because these shortcomings are perfectly solved).

You must store all the revoke keys for this channel. You need to store a revocation key for every update of the channel, which means that for a single channel, you need to store millions of keys in your lifetime, up to several megabytes in size.

RustyReddit solves this problem, we can generate all the keys starting from a seed key. Each key is a SHA256 that is repeated for that seed key.

For example, I tell you that my first undo key is SHA256 (SHA256(seed)). You can store it in O(1). When the next revocation is made, I tell you that the revocation key is SHA256(seed). Starting with SHA256(seed), you can calculate SHA256(SHA256(seed)) (that is, the previous undo key). So you only need to remember the most recent revoke key, you can calculate each key before. When you open a channel, you will execute millions of SHA256 on your seed key, and then use the final result as the first use of the revoke key. You only need to remove it whenever you need a revoke key. One layer of SHA256. RustyReddit also proposed an efficient storage structure O(log n), shachain. If something happens, you can quickly find the original revocation key. People are no longer discussing this storage issue because it is perfectly solved.

Another thing I want to emphasize is that when Lightning Network's papers were developed from the old hub-spoke model, the modern lightning network learned the lesson and no longer distinguished between "hubs" and "spokes."

Any node in the lightning network can be used as a hub for other nodes. So, even if you only pay during the execution, or only forward the transaction, at least you are still part of the forwarding node ("hub"). This greatly reduces the privacy problem caused by only a few hub nodes: the forwarding node can only get very little information through them, because the distance between the payer and the payee is too large, the final payee and payment A person can be anyone on the lightning network.

It’s time for knowledge:

(1) As long as we work hard enough, we can achieve decentralization!

(2) As long as we are all hubs, hubs can also become a good thing.

(3) Smart people can solve problems, which is why they are smart.

6

future

Behind the Lightning Network, there is the Decker-Wattenhofer Duplex Micropayment Channel (DMC). It uses a wonderful "nSequence decrementing channel" that uses a new type of nSequence (not the one that Nakamoto is ruined) relative-timelock semantics. It uses multiple "decrementing nSequence" structures, terminating in a pair of Spilman channels, one in each direction.

The channel structure can actually contain more channel configurations (Decker-Wattenhofer puts a pair of Spilman channels into a series of "decrementing nSequence channels"), which leads us to further propose the Burchert-Decker-Wattenhofer channel factory.

Basically, you can hold multiple dual-participant channel structures that are contained in a larger multi-party "channel" (that is, multiple channels in a "factory").

Going a step further, we also have the Decker-Russell-Osuntokun or "eltoo" structure. This article is long enough, I am going to discuss it later.

The scalability of the Bitcoin chain is much more powerful than you think.

Author: almkglor

Translation: Empty Island Flight

Original address:

https://www.reddit.com/r/Bitcoin/comments/cc9psl/technical_a_brief_history_of_payment_channels/

We will continue to update Blocking; if you have any questions or suggestions, please contact us!