Bitcoin Lightning Network: RSMC

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:

1. For two-way payment, both parties can transfer money to each other instead of a single channel.
2. One party withdraws halfway, and the other party must immediately get the money back, instead of waiting for nLockTime expire to get the money back. At the same time, punishment should be imposed on the active exit party.
3. 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.

• Blockchain trough, many institutions are far away, but they are busy with crazy mergers and acquisitions
• Market Analysis: Platform coins have bottomed out, and there are opportunities to get on the bus?
• The 63-year-old woman is not far away from the pyramid scheme to sell the bad IPFS mining machine game.

1. 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.
2. Alice constructs a promised transaction and a refund transaction: C1a/RD1a and 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 sequence prevent the current transaction from entering the block. Only when the forward transaction (ie C1a) has sequence confirmation can the block be entered. .
3. 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.
4. 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.
5. 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 C1a/RD1a and 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 C1b/Rd1b ?)

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.

Suppose Alice 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.

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