guides/en/ln-06.md

- Title: LN Chapter 6: Opening and announcing a pre-taproot channel
- Summary: This chapter will serve as a recap of channel opening and announcement whilst adding some technical details to the process. 

---

In this chapter, we will review the process of opening and announcing a pre-taproot channel whilst adding some technical details. In the next chapters, we will apply the same treatment to normal operation and closure of a channel. These chapters will give us the foundation to build on as we learn about taproot channels in the future. 

We will assume that you are already familiar with the structure of a commitment transaction and understand why they are asymmetric.
If you need a reminder, please check out the previous chapters!

Table of Contents
- The end goal
- Opening the channel
    - The `open_channel` message
    - The `accept_channel` message
    - The `funding_created` message
- Announcing the channel

### The end goal

Let's establish what our old friends, Alice and Bob, are trying to achieve. 

Alice and Bob are both Lightning Network nodes. Alice is known on the network by her *node ID*, or the public key used to identify her node, this is `alice_node_id`. Likewise, Bob's node ID is `bob_node_id`. 

Their two main goals are: 
1. They want to open a channel between themselves in a trustless way. 
2. They want to be able to advertise their new channel so that the rest of the network can use it for routing. 

### Opening the Channel

First things first: throughout this chapter, we will use diagrams and colours to illustrate the process of channel opening. Here's the colour code guide: 

- A *white* background means the field of the transaction is not yet known.
- A *coloured* field means that the field value is known. 
    - *Green* indicates Alice's public keys.
    - *Blue* indicates Bob's public keys.

A channel is opened once both parties have the ability to fully sign their respective commitment transactions and once the funding transaction is on chain. Three transactions are in play for the opening of a channel. The first is the funding transaction, which needs to be confirmed onchain. The other two are the commitment transactions held by Alice and Bob describing the initial state of the channel. 

At the moment, we still don't know anything about the parameters of the channel so all fields have a white background:

![fntx_1]()

![1a_1]()

![1b_1]()

#### The open_channel message

The first step of the process is Alice deciding she wants to open a channel to Bob, i.e. she will become the funder of the channel (and Bob will be the fundee). Let's say Alice decides that she wants to open a 1 BTC channel to Bob and immediately give Bob half of the channel capacity (0.5 BTC). Alice will now put together a `open_channel` message that she will send to Bob. As a reference, in the table below you can see the relevant parameters. 

| Field Name | Field Description |
|___|___|
| chain_hash | The blockchain to open the channel on. |
| temp_chan_ID | Identify the channel before the funding tx outpoint is known. |
| funding_sats | The funding tx output amount, i.e. the channel capacity. |
| push_msat | The amount that the funder unconditionally sends to the fundee at the time of opening. |
| dust_limit_sats | Threshold below which outputs should not be generated for. |
| feerate_per_kw | The initial fee rate to use for commitment transactions. Can be updated later via `update_fee`. |
| revocation_basepoint | Used, along with the remote node's first_per_commitment_point, to derive the first revocation pubkey to be used on Bob's commitment transaction. |
| payment_basepoint | Used, along with the first_per_commitment_point, to derive the first payment pubkey - the to_remote pubkey on Bob's commitment transaction. |
| delayed_payment_basepoint | Used, along with the first_per_commitment_point, to derive the first delayed pubkey - the local_delayed_pubkey on Alice's commitment transaction. |
| first_per_commitment_point | The first point to use along the above basepoints (excluding the revocation_basepoint) to derive the corresponding pubkeys. |
| channel_flags | The only flag currently defined is the "announce_channel" flag which determines if the channel should be announced to the network or not. |
| tlv: channel_type | So that the commitment transaction structure can be determined. |

Let's now fill in Alice's values for these fields: 

![open_chan]()

Alice sends this message to Bob. 

Since Alice has decided on the the type of channel she wants to open (legacy as opposed to anchors, taproot etc) as well as the channel capacity, she can already piece together quite a large part of the funding transaction:

![fntx_2]()

Alice can already choose some of her UTXOs to be inputs to the funding transaction since she knows the capacity of the channel she wants to open. However she does not yet know which pubkey Bob would want to use for the channel, so she cannot finalise the channel funding output just yet, and therefore cannot yet produce signatures for the inputs. 

As Alice has decided on the channel type (and thus the commitment transaction structure), she can also start assembling the pieces of the commitment transactions. If we assume Bob is happy with this channel opening proposal from Alice, he can also start putting together the pieces using the information in the `open_channel` message. Remember that both peers need to construct their own commitment transactions and they will both need to sign their peer's transactions. 

Let's see what pieces they are already able to fill in: 

![1a_2]()

Alice's commitment transaction has the structure of a default, non-anchor channel transaction. All her public keys have been filled in (`alice_local_delayed_pk_1` is derived using her `delayed_payment_basepoint` and her `first_commitment_point`). Since she hasn't received any messages from Bob yet, she cannot fill in any of his pubkeys. And since the funding transaction is still incomplete, she also can't know the TXID to point the input of this commitment transaction to. 

Bob's commitment transaction is looking slightly more complete:

![1b_2]()

Like Alice, he also cannot yet fill in the funding transaction's TXID, but he can fill in a few other things: 
- The `alice_pubkey_1`, `alice_to_self_delay`, `push_amt` and `local_amt` values are taken as is from the `open_channel` message. 
- `alice_payment_key_1` is derived using Alice's payment_basepoint and `first_commitment_point`. 
- `revoke_pubkey_1b` is derived using Alice's `revocation_basepoint` and Bob's `first_per_commitment point` (Alice cannot derive this point yet since she hasn't received Bob's `first_per_commitment_point`)

Cool! Time for Bob to indicate to Alice his acceptance of the proposal by sending the next message: `accept_channel`. 

#### The accept_channel message

The message shares many of the fields from `open_channel`. Here's the message that Bob will put together. 

![accept_channel]()

When Alice gets this message from Bob, she can now complete the funding transaction's output and can create the signatures for the inputs. Since everything is now filled in, the TXID of the funding transaction is also known. 

![fntx_3]()

Alice can now fill in some more of her own commitment transaction:
- she can now use the values sent by Bob to fill in `bob_pubkey_1`, `bob_payment_key_1`, `bob_to_self_delay` and `revoke_pubkey_1a`
- since the TXID for the funding tx is now known, she can complete the input too

She now knows everything she needs to know in order to sign this transaction herself _but_ remember she is still missing Bob's signature for this transaction. 

![1a_3]()

Bob's commitment transaction is still the same as before since he learned no new information after sending the `accept_channel` message.

Now that Alice knows the TXID of the funding transacation, she is also able to complete her view of Bob's commitment transaction and so she can produce her signature for his transaction. She will send the next message to Bob: `funding_created`.

#### The funding_created message

Alice will now use the `funding_created` message to tell Bob the TXID and the index of the funding transaction along with her signature for Bob's commitment transaction. Note that Bob still won't be able to broadcast his commitment transaction because the funding transaction hasn't been broadcasted yet. 

![funding_created]()

Once Bob receives the `funding_created` message, he can fill in the rest of his commitment transaction: 

![1b_3]()

#### The funding_signed message

Alice won't broadcast the funding transaction until she has a valid signature from Bob for her commitment transaction, enter `funding_signed`:

![funding_signed]()

Notice that this is the first message to use the real channel ID instead of the temporary one. 

This was the last piece of the puzzle for Alice. She now has all the info she needs to be able to sign her commitment transaction if ever needed. 

![1a_4]()

#### The channel_ready message

Alice can now safely broadcast the funding transaction. Both Alice and Bob will watch the chain for the confirmation of the funding transaction. Once it has reached `minimum_depth` specified by Bob in his `accept_channel` message, both sides will exchange the `channel_ready` message. This message serves two purposes. First, it serves as a signal to the peer to indicate that the channel is ready to use (and they can start the channel announcement process if they opened a public, announced channel). Second, it also tells the peer to send across their `second_per_commitment_point` that they should use in their second commitment transaction. 

![channel_ready]()

### Announcing the channel

This part is fairly easy. Alice and Bob just need to construct one message, `channel_announcement`, together and once it is complete, then they can broadcast it to the network. Other nodes will use this message to prove a few things:
- That the channe funding tx is actually an existing, unspent UTXO with an acceptable number of confirmations.
- That the funding transaction output actually looks like a Lightning channel funding transaction.
- That the channel is actually owned by the keys that Alice and Bob say they used to construct the channel. 
- That Alice and Bob both agree on the message being broadcast. 

A partial version of the `channel_announcement` message looks like this:

![channel_announcement]()

`h` is the hash of all the data that will be covered by the signatures. In order to complete this message, both Alice and Bob need to compute a signature over `h` using the private keys associated with their node IDs and the pubkeys they used in the funding transaction. They then both exchange the `announcement_signatures` message in order to communicate these signatures to each other. 

![announcement_sig]()

Now both nodes can put together the complete `channel_announcement` message:

![channel_announcement_2]()

Let's say Charlie is a node that received this message. Let's go over the steps that he will go through in order to verify the new channel that Alice and Bob have announced:

1. First, Charlie will use the `short_channel_id` included in the message to make sure that the funding transaction actually exists on-chain, that it has a sufficient number of confirmations and that it is in fact unspent. 
2. Then, Charlie will check that the unspent output actually looks like a Lightning channel owned by `alice_pubkey_1` and `bob_pubkey_1`. He will do this by using the advertised pubkeys to reconstruct the P2WSH and ensure that it is the same as the one found on-chain. 
3. Now, Charlie will want to verify that the nodes ownning the pubkeys used in the funding output to in fact correspond to the nodes owning the node ID pubkeys. He can do this by verifying the signatures `alice_pubkey_1_sig` and `bob_pubkey_1_sig`. If these signatures are valid, then it is clear that the owners of `alice_pubkey_1` and `bob_pubkey_1` agree to be associated with `alice_node_ID` and `bob_node_ID` since the message signed contains these pubkeys. 
4. Finally, Charlie will also want to ensure that the owners of the node ID pubkeys agree to being associated with the new channel. He can do this by verifying the signatures `alice_node_ID_sig` and `bob_node_ID_sig`. If these signatures are valid, then it is clear that the owners of `alice_node_ID` and `bob_node_ID` agree to be associated with `alice_pubkey_1` and `bob_pubkey_1` since the message signed contains these pubkeys. 

Alice and Bob are finished! Their channel is now open and other nodes on the network, like Charlie, will happily use the new channel.