Lightning Network is a decentralized system that enables real-time, massive trading networks without trusting each other and third parties.
The Lightning Network evolved based on the micropayment channel and creatively designed two types of trading contracts: the sequence expired revocable contract RSMC and the hash time lock contract HTLC. RSMC solves the problem of one-way flow in the channel, and HTLC solves the problem of currency cross-node transfer. These two types of transaction combinations constitute the lightning network.
Below we look at the problems in the micropayment channel, that is, the problems that RSMC needs to solve:
- Research: Bitcoin appears in 95% of digital currency crimes
- Babbitt column | Cai Kailong: Tesla is the next Bitcoin or Apple
- Is CSW penalized 550,000 BTCs, is this important?
- Schnorr upgrade makes Bitcoin "private"? In fact not the case
- Bitcoin plunges in "mine circle" ecological survey, more than 40 mainstream miners hit "shutdown price"
- Wall Street predators lose coins, crypto world "lost shares"
- For two-way payment, both parties can transfer money to each other instead of a single channel.
- One party withdraws halfway, and the other party must immediately get the money back, instead of waiting for
nLockTimeexpire to get the money back. At the same time, punishment should be imposed on the active exit party.
- To ensure that both parties to the transaction, no one can deny and repent.
1. RSMC transaction structure
The following figure shows the construction of RSMC transactions.
- The two sides each took out 0.5BTC and built a 2/2 multi-signature margin transaction. In order to prevent any party from doing evil, deliberately submitting the transaction causes the other party's funds to be locked. At the current time, only the margin transaction is constructed, but it is not signed or broadcast , so that no one can do evil.
- Alice constructs a promised transaction and a refund transaction:
C1a/RD1aand handed it to Bob for signature. The first output of C1a is the multi-signature address, Alice's other private key Alice 2 and the Bob's private key's 2/2 multi-signature, and the second output is Bob 0.5BTC. RD1a is the first output of C1a and is output to Alice 0.5BTC. However, this type of transaction has a
sequenceprevent the current transaction from entering the block. Only when the forward transaction (ie C1a) has
sequenceconfirmation can the block be entered. .
- Bob constructs a promised transaction and a refund transaction: C1b and RD1b, and handed it to Alice's signature. This structure is symmetric with C1a and RD1a.
- Bob signed Alice's promised transaction and refund transaction, and then handed it to Alice's signature; in the same way, Alice signed the promised transaction and refund transaction for Bob, and gave it to Bob.
- Alice checks the C1a, RD1a transaction and Bob's signature, and then signs it after verification. Similarly, Bob does a similar operation. When both parties complete the signature and exchange of the promised transaction and the refund transaction, they then sign and exchange the deposit. At this point, the margin is a complete transaction, broadcast.
C1a, C1b Two transactions cost the same output, so only one of their two transactions can enter the block.
- If Alice broadcasts C1a, Bob immediately gets 0.5BTC (the second output of C1a), and Alice needs to wait for C1a to get 1000 confirmations before she can get 0.5BTC through the output of RD1a.
- If Bob broadcasts C1b, Alice immediately gets 0.5BTC, and Bob waits for C1b to get 1000 confirmations before he can get 0.5BTC through RD1b. That is to say, the party that terminates the contract in the unilateral broadcast transaction will delay the receipt of the currency, while the other party will immediately receive the currency.
2. RSMC transaction update
Assuming that Alice is going to pay Bob 0.1 bitcoin, the allocation of funds in the public account will change from 0.5/0.5 to 0.4/0.6.
So create new commitment transactions and refund transactions, C2a and RD2a for Alice, C2b and RD2b for Bob, the process is similar to the above.
In the above figure, both states are valid. How can I completely discard the old transactions
C1b/RD1b ? That is how to ensure that Alice does not
C1a/Rd1a (doesn't Alice broadcast
C1a/Rd1a to the
C1a/Rd1a ?) Similarly, how to ensure that Bob does not
C1b/Rd1b (doesn't Bob broadcast
C1b/Rd1b to the
RSMC took a very clever approach. In the first output of C1a, Alice 2 and Bob's multi-signature were used. Alice handed Alice 2's private key to Bob, which means Alice gave up C1a. , recognize C2a. Alice gave the private key Alice 2 to Bob, who would create a penalty trade BR1a for C1a in case Alice repented.
C1a/RD1a , that is, broadcasts
C1a/RD1a , and Bob broadcasts BR1a. Since BR1a does not have a
Sequence , it will definitely execute before RD1a, so the result is that RD1a will not be executed and BR1a is executed. The result is that Alice can't get the money, Bob will transfer Alice's 0.5 bitcoin to his account, which is the punishment for Alice.
Vice versa, Bob surrendered Bob 2's private key to Alice, which means giving up C1b, but only C2b. The purpose of introducing the
sequence is to prevent subsequent transactions from entering the block (RD1a), giving an implementation penalty window. When the other party is found to be breaking the contract, there can be 1000 block confirmation time to implement the penalty transaction, that is, broadcast BR1a instead of RD1a. If you miss 1000 block time windows, you can no longer implement the penalty (RD1a is in the block).
3. RSMC transaction is closed
Close the RSMC and construct a promise directly according to the final balance. For example, the output is Alice 0.1BTC, Bob 0.9BTC, no need to set multiple signatures, construct penalty transactions, etc.