Bitcoin Txoko
52 lines
5.6 KiB
Markdown
52 lines
5.6 KiB
Markdown
- Title: LN Chapter 2: Updating state
|
|
- Summary: Today's chapter will describe the basics of how the update layer works under LN-Penalty, covering commitment transactions in more detail and serving as a set up for more detailed picture for how HTLCs fit into the picture in future chapters.
|
|
|
|
---
|
|
|
|
In the previous chapter, we learned how Alice and Bob opened a channel, using commitment transactions that can be published on the blockchain at any time to reclaim their funds. But of course, the initial commitment transactions become invalid as soon as the channel state changes, in other words, when a payment is made and the channel balance becomes distributed differently between the channel participants. In this chapter, we will start learning about how Alice and Bob can agree on a new division of funds, i.e. how to split the channel balance differently and invalidate the older commitment transactions that they have.
|
|
|
|
💡 We will be covering how this works under the current paradigm of how channels are updated, called "LN-Penalty", named for the penalty mechanism used to secure funds against malicious adversaries. There is a newer proposal called "LN-Symmetry" (formerly eltoo) that doesn't require the penalty mechanism to be secure and simplifies this process, but requires modifications to Bitcoin's consensus rules to work.
|
|
|
|
|
|
### Asymmetric commitment transactions
|
|
|
|
In LN-Penalty, each participant in a channel holds a commitment transaction representing the state of the channel. The commitment transactions held by each party vary slightly. The reason for this is to assign blame. Why is it necessary to assign blame? Because we need to make it clear which party broadcasted their commitment transaction and identify the correct party to punish if they have published an invalid state.
|
|
|
|
### Setting up state
|
|
|
|
In the last chapter, we showed how Alice and Bob exchanged their pubkeys to create their initial commitment transactions. Let's take a closer look at what these commitment transactions look like. For simplicity's sake, let's assume that the total channel balance is 10 BTC and Alice and Bob each holds 5 BTC on their sides of the channel. To set up their initial commitment transactions, each party first creates a temporary private key, for Alice, let's call this `dA1`, for Bob, `dB1`. They also calculate the associated public keys, `PA1` for Alice and `PB1` for Bob. At this point, each party can construct their own commitment transactions. Alice's will look like this:
|
|
|
|
1. It will spend the funding transaction.
|
|
2. It will have two outputs (or more, when there are HTLCs. We will cover those in the future).
|
|
3. The `to_remote` output will send Bob his 5 BTC immediately.
|
|
4. The `to_local` output will be fancier. Two things can happen here. Alice can send herself the 5 BTC after an OP_CSV `to_self_delay` or it can be spend by Bob if he can prove that he has Alice's temporary private key `dA1`.
|
|
|
|
In a similar manner, Bob can construct Alice's commitment transaction too and provide her his signature for it. Alice can sign this valid transaction herself at any time and broadcast it to the network, giving her the assurance she needs to reclaim her funds in case Bob disappears.
|
|
|
|
|
|
|
|
At this point, either party can broadcast their commitment transactions to close the channel. Let's say Alice broadcasts hers. Bob will get his 5 BTC immediately. Alice will have to wait the `to_self_delay` number of blocks before being able to use her 5 BTC. She doesn't need to worry about Bob spending her output though because she knows she never shared her private key with him.
|
|
|
|
### Invalidating old state
|
|
|
|
Now Alice wants to send Bob 1 BTC using their channel. So just like the previous step, each party generates new private keys (`dA2` for Alice, `dB2` for Bob), calculates the associated public keys (`PA2` for Alice, `PB2` for Bob), and shares the public keys with each other. And again, they both create commitment transactions to reflect the new state of the channel (Alice now has 4 BTC since she transferred 1 BTC to Bob; Bob now has 6 BTC).
|
|
|
|
The problem though, is that Alice still has her commitment transaction from the previous step, where she had 5 BTC, which is more profitable to her. To show Bob that she is invalidating the old state and committing to the new state, she needs to send Bob her initial temporary private key (`dA1`). Now, since Bob now has this key, he is able to spend Alice's `to_self` output if she ever publishes an old, invalid state, before she is able to claim it (remember that the `to_local` output has a `to_self_delay`).
|
|
|
|
Bob also sends Alice his old key (`dB1`) to invalidate his old state. He has no reason not to do this since his new state is more profitable to him.
|
|
|
|
|
|
|
|
That's it! We have now learned how Alice and Bob can securely transact by setting up new states and invalidating old states.
|
|
|
|
### Review
|
|
|
|
- To **update state**, each channel participant generates new keypairs and sends each other the public key.
|
|
- To **invalidate state**, for example when a transaction is made, each channel participant updates state and sends each other the private key of the old state.
|
|
|
|
### References
|
|
|
|
- [BOLT3](https://github.com/lightning/bolts/blob/master/03-transactions.md)
|
|
- [LN Things Part 2: Updating state](https://ellemouton.com/posts/updating-state/) by nostr:nprofile1qqswrt9pnxatlplu49h6meld8svmwqt87wwvk256rqk07n6eu4qeh5gpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dszpfjtz
|
|
- [eltoo](https://bitcoinops.org/en/topics/eltoo/)
|