Bitcoin Txoko
76 lines
5.8 KiB
Markdown
76 lines
5.8 KiB
Markdown
# Title: LN Part 1: Creating a Channel
|
|
|
|
# Summary: In the first part of our series of explainers for the Lightning Network, we will see how Alice and Bob can create a Lightning channel between them using concepts like funding transactions and commitment transactions.
|
|
|
|
### What is a channel?
|
|
|
|
A Lightning channel is just a 2-of-2 multisig onchain. To open a channel, we just send funds to a 2-of-2 multisig transaction. This creates an UTXO and the channel is open until this UTXO is spent. During the lifetime of the channel, a bunch of transactions are created that double spend the funding tx but eventually one (and only one) of these will be published onchain to close the channel. So ideally, a Lightning channel effectively condenses a bunch of transactions into two onchain transactions: the one that opens it and the one that closes it. We could say that this is how Lightning "lifts" transactions offchain.
|
|
|
|
### Creating a channel
|
|
|
|
A **funding transaction** for a channel between Alice and Bob is simply a transaction that has an output as follows:
|
|
|
|
```
|
|
2 <pubkeyA> <pubkeyB> 2 OP_CHECKMULTISIG
|
|
```
|
|
|
|
Where `<pubkeyA>` is Alice's pubkey and `<pubkeyB>` is Bob's. So if Alice wants to open a channel with Bob, does she simply send funds to the script above?
|
|
|
|
The answer is no, it's a bit more complicated than that. There is a chance that Bob might disappear forever and never come back to sign any transaction that tries to spend from the funding transaction. This means that effectively Alice's funds would be stuck in this UTXO forever. Not ideal!
|
|
|
|
This is where a **commitment transaction** comes in. We will cover commitment transaction in more detail in the future, but for now the important thing to know is that once a funding transaction is confirmed, commitment transactions define the **state** of the channel (i.e. how the funds are distributed between the participants in the channel). So essentially each commitment transaction spends the funding tx as an input, and has outputs that define the distribution of funds between the channel participants.
|
|
|
|
To see how these two concepts are used to negotiate the opening of a channel, a series of messages will be exchanged between Alice's and Bob's nodes, as shown in the diagram below.
|
|
|
|
|
|
|
|
It's a bit like negotiating a contract; each party only signs when they are happy with the terms. Let's go through each of these messages in more detail.
|
|
|
|
#### open_channel
|
|
|
|
Alice sends this message to Bob to indicate that she wants to open a channel with him. This message contains various details about Alice's requirements for the channel. The most important one is `funding_pubkey`. This is the pubkey that Alice intends to use as her public key in the funding tx script.
|
|
|
|
|
|
|
|
#### accept_channel
|
|
|
|
If Bob is happy with the requirements that Alice has put forward in her channel offer, he can send back the `accept_channel` message, which also contains some of his requirements along with his `funding_pubkey`.
|
|
|
|
|
|
|
|
At this point, Alice has all she needs to construct the funding transaction. However, she still has no guarantee that Bob will not disappear, rendering her funds unspendable. Therefore she does not broadcast the funding transaction yet. Instead, what she needs is a commitment transaction signed by Bob that spends from the funding transaction and divides the channel balance accordingly. The funding transaction might allocate some funds to Bob too, so Bob would also want a valid commitment transaction signed by Alice, in case _she_ disappears.
|
|
|
|
So what Alice does now is construct the funding transaction and sends Bob the following message:
|
|
|
|
#### funding_created
|
|
|
|
|
|
|
|
This message contains the TXID of the funding transaction, the relevant output index of the funding transaction along with a a signature of Bob's commitment transaction. Alice can construct Bob's exact commitment transaction using information she already knows.
|
|
|
|
Note that Bob cannot do anything yet with his commitment transaction because it is spending from a transaction that is not on the blockchain yet.
|
|
|
|
#### funding_signed
|
|
|
|
|
|
|
|
If Bob is happy then he can send Alice a `funding_signed` message, which contains Bob's signature for Alice's commitment transaction.
|
|
|
|
Now, Alice has a valid commitment transaction signed by Bob which she can use to spend her funds back to herself in case Bob disappears. It is thus safe for her to broadcast the funding transaction.
|
|
|
|
#### channel_ready
|
|
|
|
Both Alice and Bob will now be watching the blockchain waiting for the funding transaction to reach the desired number of confirmations. Once they each see it, they will send each other the `channel_ready` message which contains the channel ID of the channel.
|
|
|
|
|
|
|
|
The channel is now open and ready for transactions!
|
|
|
|
### Review
|
|
|
|
We will wrap up with a short recap of the important concepts we have learned in this chapter. Feel free to jump back here in the future in case you need a reminder.
|
|
|
|
- **channel**: a 2-of-2 multisig contract onchain used to lift transactions offchain
|
|
- **funding transaction**: a 2-of-2 multisig transaction with a P2WSH output script containing the pubkeys of both participants of the channel
|
|
- **commitment transaction**: a transaction that defines the state of a channel, i.e. the distribution of funds between the participants of the channel
|