Bitcoin Txoko
59 lines
5.1 KiB
Markdown
59 lines
5.1 KiB
Markdown
- Title: LN chapter 8 - Closing a channel cooperatively
|
||
- Summary:
|
||
|
||
---
|
||
|
||
### Closing a channel cooperatively
|
||
|
||
Alice and Bob sure had some good times together but all good things must come to an end. Closing a channel in a cooperative way requires the two peers to decide on a final closing transaction that will spend from the funding transaction and will pay each of them their final channel balance immediately.
|
||
|
||
##### Step 22: Bob -> Alice: shutdown
|
||
|
||
Bob has decided that it is time to cut ties and sends Alice the shutdown message.
|
||
|
||
|
||
|
||
The shutdown message contains the scriptpubkey that Bob would like his final channel balance to be sent to in the closing transaction. Once Bob has sent this final message, he may no longer send any new `update_add_htlc` messages. He may only send HTLC removal and `update_fee` messages. When Alice receives this message from Bob, she must responde with her own shutdown message and may also no longer send any new `update_add_htlc` messages. Alice and Bob now need to wait until all remaining HTLCs have been cleared from both commitment transactions. Since the closing transaction will spend from the funding transaction and explicitly looks different from the commitment transactions, I'll re-introduce some of the details into the state diagram:
|
||
|
||
|
||
|
||
Once all the HTLCs have been cleared, which in our example is already the case, they can start negotiating a fee to use for the final closing transaction. The funder of the channel must start this negotiation. Let's assume that the channel funder is Alice.
|
||
|
||
##### Step 23: Alice -> Bob: closing_signed
|
||
|
||
Alice will first choose a fee-rate that she thinks is appropriate for the closing transaction. She will then use that fee-rate to complete the construction of the closing transaction and sign it. She then sends the `closing_signed` message to Bob:
|
||
|
||
|
||
|
||
The `fee_satoshis` field tells Bob the fee in satoshis that Alice used to construct the first closing transaction proposal. The signature contains Alice's signature for this proposal. She may optionally also include the `min_fee_satoshis` and max_fee_satoshis fields in order to let Bob know that if he disagrees with her proposed `fee_satoshis`, then he may send a counterproposal as long as his counterproposal lies between the provided minimum and maximum range.
|
||
|
||
At this point, the channel state looks like this:
|
||
|
||
|
||
|
||
There are two valid commitment transactions that can be signed at any time by each party to perform a force close, and there is one closing transaction proposal using a fee-rate of `x` sats-per-byte. This closing transaction currently only has Alice's signature and so is not yet valid.
|
||
|
||
If at this point, Bob is happy with Alice's proposal, he could go ahead and sign the closing transaction using the fee-rate proposed by Alice and could broadcast it and that would be the end of it. But for the sake of the example, let's say that Bob isn't quite happy just yet.
|
||
|
||
##### Step 24: Bob -> Alice: closing_signed
|
||
|
||
Bob may decide that the fee-rate that Alice used is too low. So he sends a counterproposal with a new fee rate, `y` sats-per-byte, along with his signature for this counterproposal.
|
||
|
||
|
||
|
||
##### Step 25: Alice -> Bob: closing_signed
|
||
|
||
If Alice is happy with Bob's counterproposal, then she signs the closing transaction using the fee-rate suggested by Bob. She may then broadcast the transaction and call it a day. However, it is recommended in the spec that Alice send one more `closing_signed` message to Bob but this time with the `fee_satoshis` field set to `y` sat-per-byte along with her signature for the transaction. Both parties will now have both signatures required in order to broadcast the final closing transaction that uses the `y` sats-per-byte fee-rate.
|
||
|
||
|
||
|
||
Either or both parties may now broadcast the closing transaction to the Bitcoin network. Eventually it will be confirmed and the channel will officially be closed.
|
||
|
||
|
||
|
||
If this channel was a public channel, then any node in the network that had this channel in their routing graph will be able to see that the channel's funding output has been spent and so will remove the channel from their graph at this point.
|
||
|
||
The beauty of the channel is that Alice and Bob could have sent millions of HTLCs back and forth throughout the lifetime of the channel and in the end, all that showed up on-chain was the opening and closing transaction.
|
||
|
||
Alice and Bob lived happily ever after.
|