lnbook/channel-construction.asciidoc

Payment channels are the core and most fundamental building block of the Lightning Network.
Of course, every detail of a technology exists for a reason and is important.
However the Lightning Network is literally built around the idea and concept of payment channels.
In the previous chapters you have already learned that payment channels

* allow two peers who created it to send and receive Bitcoin up to the amount specified by the capacity of the channel as often as they want to.
* split the capacity of the channel into a balance between the two peers which - as long as the channel is open is only known by the owners of the channel and increases privacy.
* do not require peers to do any additional onchain transactions other than the one needed to open and - potentially at a later state - to close the channel.
* can stay open for an arbitrary time. Potentially in the best case forever.
* do not require peers to trust each other as any attempt by a peer to cheat would enable the other peer to receive all the funds in the channel as a panality.
* can be connected to a network and allow peers to send money a long a path of connected channels without the necessity to trust the intermediary nodes as they have no ability to steal the Bitcoin that are being forwarded.
*

In this chapter we will dig deeper into the protocol details that are needed to open and close payment channels.
Working through this rather technical chapter you will be able to understand how the protocol design achieves the properties of payment channels.
Where necessary some information from the first chapters of this book will be repeated.
If you are new to the topic we highly encourage you to start there first.
If you however already know a fair share about bitcoin script, OP_CODES and protocol design it might be sufficient to skip the previous chapter and start here with us.
This books follows the construction of payment channels as described in BOLT 02 which is titled `peer protocol` and describes how two peers communicate to open, maintain and close a channel.
There will be one big difference though.
We will only discuss opening and closing a channel.
The operation and maintainance of a channel which means either making or forwarding a payment is discussed in our chapter about routing.
Also other constructions of payment channels are known and being discussed by the developers.
Historically speaking these are the Duplex Micropayment channels introduced by Christian Decker during his time as a PhD student at ETH Zuric and the eltoo channels which where also introduced by Christian Decker.
The eltoo channels are certainly a more elgant and cleaner why of achieving payment channels with the afore mentioned properties.
However they require the activation of BIP 118 and a softfork and are - at the time of writing - a potential future protocol change.
Thus this chapter will only focus on the pentalty based channels as described in the Lightning Network Whitepaper and specified in BOLT 02 which are currently supported by the protocol and the implementations.

[NOTE]
====
The Lightning Network does not need consensus of features across it's participants.
If the Bitcoin Softfork related to BIP 118 activates and people implement eltoo channels nodes that support eltoo can create payment channels and the onion routing of payments a long a path of channels would work just fine even if some of the channels are the modern eltoo channels or some channels are the legacy channels.
Actually when Lightning network connections are established nodes signal feature bits of global and local features that they support.
Thus havning the ability to create eltoo channels would just be an additional feature bit.
In this sense upgrading the Lightnign Network is much easier than upgrading Bitcoin where consensus among all stakeholders is needed.
====

Let's quickly summarize what you should already know about payment channels on a technical level and for what you will learn the details in this chapter.
A payment channel is encoded as an unspent 2-of-2 multisignature transaction output.
The capacity of the channel relates to the amount that is bound to the unspent 2-of-2 multisignature transaction output.
It is opened with the help of a funding transaction that sends bitcoin to a 2-of-2 multisignature output together with a communication protocol that helps to initialize and maintain its state.
The balance of the channel encodes how the capacity is split between the two peers who maintain the channel.
Technically the balance is encoded by a the most recent pair of a sequence of pairs of similar (but not equal) presigned commitment transactions.

.Bitcoin, Lightning and "Ownership" of funds
****
When someone says they 'own' bitcoin they typically mean that they know the private key of a bitcoin address that has some unspent transaction outputs (UTXOs).
The private key allows the owner to produce a signature for a transaction that spends the bitcoin by sending it to a different address.
Thus 'ownership' of bitcoin can be defined as the ability to spend that bitcoin.

If you have an unpublished but signed transaction from a 2-of-2 multisignature address, where some outputs are sent to an address you own, and additionally you own one of the private keys of the multisignature address, then you effectively own the bitcoin of that output.
Without your help no other transaction from the 2-of-2 multisignature address can be produced.
However, without the help of anybody else you can transfer the funds to an address which you control.
On the Lightning Network ownership of your funds is almost always encoded with you having a pre-signed transaction spending from a 2-of-2 multisignature address.

****

These commitment transactions should never hit the blockchain and serve as a safty net for the participants in case the channel partner becomes unresponsive of disappears.
They are also the reason why the Lightning Network is called an offchain scaling solution.
Each channel partner has both signatures for one of the commitment transactions from the sequence of pairs.
The split of the capacity is realized by a `to_local` and a `to_remote` output that is part of every commitment transaction.
The `to_local` output goes to an address that is controlled by the peer that holds this fully signed commitment transaction.
`to_local` outputs, which also exist in the second stage HTLC transactions - which we discuss in the routing chapter - have two spending conditions.
The `to_local` output can be spent either at any time with the help of a revocation secrete or after a timelock with the secret key that is controled by the peer holding this commitment transaction.
The revocation secrete is necessary to economically disincentivice peers to publish previous commitment transactions.
Addresses and revokation secretes change with every new pair of commitment transactions that are being negotiated.
The Lightning Network as a protocol defines the communication protocols that are necessary to achieve this.

### Security of a Payment channel
While the BOLTs introduce payment channels directly with the opening protocol we have decided to talk about the security model first.
The security of payment channels come through a penalty based revocation system which help two parties to split the capacity of the payment channel into a balance sheet without the necessity to trust each other.
In this chapter we start from an insecure approach of creating a payment channel and explain why it is insecure.
We will then explain how time locks are being used to create revokable sequence maturity contracts that create the penality based revokation system which economically incentivizes people maintain the most recent state.
After you understood these concepts we will quickly walk you through the technical details of opening and closing a channel.

Any known payment channel constuction uses a 2-of-2 multisgnature output as the basis of the payment channel.
We call the amount that is attached to this output the capacity of the channel.
In every case, both channel partners hold 1 secret key of the multisignature address which means that they can only collaboratively control the funds.

#### An example for a highly insecure payment channel construction
Let us assume Alice does not know the details about the Lightning Network and naivly tries to open a payment channel in a way that will likely lead to the loss of her funds.
Alice has heard that payment channel are 2-of-2 multisignature outputs.
As she wants to have a channel with Bob and since she knows a public key from Bob she decides to open a channel by sending money to a 2-of-2 multisignature address that comes from Bob's and her key.
We call the transaction that Alices used a **funding transaction** as it is supposed to fund the payment channel.
However signing and broadcasting this funding transaction would be a huge mistake.
As we have discussed the Bitcoins from the resulting UTXO can only be spent if Alice and Bob work together and both provide a signature for a transaction spending those coins.
If Bob would not respond to Alice in future Alice would have lost her Bitcoins forever.
That is because the coins would be stuck in the 2-of-2 multisignature address to which she has just sent them.

Luckily Alice has previously read Mastering Bitcoin and she knows all the properties of Bitcoin script and is aware of the risks that are involved with sending Bitcoins to a 2-of-2 multisignature address to which she does not control both keys.
She is also aware of the "Don't trust. Verify" principle that Bitcoiners follow and doesn't want to trust Bob to help her moving or accessing her coins.
She would much more prefere to keep control over her coins even though they shall be stored in this 2-of-2 multisignature address.
While this seems like an impossible problem, Alice has an idea:

    What if she could already prepare a refund transaction (which we call commitment transaction in future) that sends all the bitcoin back to an address that she controls?

Before broadcasting her funding transaction she already prepared and finishes it so that she knows the transaction id.
She can now create the commitment transaction that spends the output of the funding transaction and ask Bob to provide a signature.
At that time Bob has nothing to loose by signing the commitment transaction.
He did not have Coins at the multisig address anyway.
Even if he did Alice intends to spend from an output which Bob never was involved in.
Thus at that point for Bob it is perfectly reasonable to sign the commitment transaction that spends the funding transaction.
On the other side you as a reader might think:

Why would Alice send money to a multisignature address just to prepare a transaction that sends the money back to her?

We really hope you have wondered about this because this is really the point where the innovation begins.
Just because in general people are expected to broadcast a transaction to the bitcoin network as soon as they have signed it noone forces you to do that.

As Alice would loose access of her Bitcoins once she sends it to a 2-of-2 multisignature output for which she only controls one key, she needs to make sure that she will be able to regain access of her coins in case Bob becomes unresponisive.
Thus before Alice publishes the funding transaction she will create another transaction that sends all the bitcoin from the 2-of-2 multisignature output back to an address which she controls.

.The situation can be seen in the following picture
image:channel-construction-opening-1.png[]
Of course for the commitment transaction Alice would need to get a signature from Bob before she can safely broadcast the funding transaction.
After publishing the funding transaction instead of braodcasting the commitment transaction she will keep it in a safe place.
For this to work Alice needs to be sure that the funding transaction could not be published with a different transaction id.
This malleability was possible before the Segwit upgrade of Bitcoin.
We will discuss the details later but didn't want to leave them out here.


[NOTE]
====
This entire process might be surprising (... comparison with HTTP server push and AJAX...)

====
Having Segwit and this first commitment transaction is actually secure for Alice.
We have seen the first of three main properties that commit transactions fulfill:

    Commitment Transactions refund channel participants in case the other side becomes irresponsive.

The second purpose was implicitely defined by the first purpose:

    Commitment Transactions split the capacity of the channel into a balance which is owned by each partner.

Initially this split means that all the capacity is naturally on the side of the partner who funded the channel.
Of course during the lifetime of the channel the balance could change.
For example Alice might want to send some funds to Bob.
This could happen because she wants to pay Bob or because she wants Bob to forward the funds through a path of channels to another merchant that she wants to pay.
Let us assume as an example that Alice wants to send 30k Satoshi to Bob.
For now we can assume that through some communication protocol Alice and Bob would negotiate a double spent of the funding transaction output of 100k satoshi.
The new commitment transaction for which Alice and Bob would exchange signatures would send 70k satoshi to Alice and 30k Satoshi to Bob.
The situation can be seen in the following picture
image:channel-construction-opening-2.png[]
Whenever Alice and Bob want to change the balance of the payment channel they will negotiate a new commitment transaction.
Effectively they double spend the funding transaction output.
But as the commitment transactions are not broadcasted - as long as the channel stays open - they will be able to do that.

At this point we want to emphasize that the section was labeled in a way that suggests that this construction is insecure.
So the main question reads:

    What can go wrong with the insecure payment channel?

The thing that goes and makes this construction insecure lies within the mechanics of Bitcoin.
The key innovation of Bitcoin was to prevent the double spending problem of electronic coins.
After Alice and Bob have exchanged signatures for the second commitment transaction Bob cannot rely on the fact that he really owns 30k satoshi.
Of course he could close the channel by publishing the second commitment transaction assigning 30k satoshi to an address that he controls.
But similarly Alice could broadcast the first commitment transaction and transfer the entire capacity of the channel back to an address that she controls.
As Bitcoin prevents double spending of the funding transaction miners will include only one of the two commitment transactions.
Thus we need to adapt the idea with the commitment transactions to create the ability to revoke an old commitment transaction.
Regarding the fact that Bob and Alice both have a copy of the transaction and that Bob cannot control the data that Alice has stored on her hardware, it seems pretty hopeless.
Luckily, the scripting language in Bitcoin allows at least for changing commitment transactions in a way that economically disincentivises channel partners from publish an outdated balances after they have negotated a new balance.

#### Secure Payment channels via Revokable Commitment transactions


[NOTE]
====
In summary we can conclude that commitment transactions fulfill three purposes:
1. Refund channel participants in case the other side becomes irresponsive
2. Split the capacity of the channel into the current balance that peers have agreed upon.
3. Allow revocation of old state through the means of a penality via a revocable sequence maturity contract.
====

We have not yet explained how channel partners actually communicate to negotiate a new balance.
Because it seems pretty amazing that we can make this swap revocation secret for signature atomic.
In order to understand this we first need to understand the general communication of how a channel is opened.
The actual negotiation of the new state is also done with HTLCs.
That is why we only explain this in the routing chapter and ask you to stay patient.

[NOTE]
====
*TODO: Move this note to routing chapter?*
HTLCS fullfill the following purposes:
1. Make a conditional payment.
2. Help to update a new balance in a channel
3. Make payments through a path of channel atomic, meaning that peers along the path cannot steal funds.
====

### Opening a payment channel
We call the process of creating a new payment channel "opening a payment channel".
Currently a payment channel can only exists between exactly two peers.
Therefore you might be surprised to learn that even though two users are owning and maintaining the channel the current construction requires only one user to open the channel.
This does not mean that only one peer is needed to open a channel.
It does however mean that the user who opens the channel also has to provide the bitcoins to fund the channel.

Let us stick to our example where Alice opens a channel with Bob with a capacity of 100k satoshi.
This means that Alice provides 100k satoshi.
Alice will do that by creating a so called funding transaction.
This transaction sends 100k satoshi from an address that she - or her lightning node software controls - to a 2-of-2 multisig address for which she and Bob know 1 secret key each.
The amount of Bitcoin that is sent to the multisig output by Alice is called the capacity of the payment channel.
Thus for the reminder of the chapter in all examples we assume the payment channels that we use as examples already magically exist and the two peers Alice and Bob already have all the necessary data at hand.

[NOTE]
====
Even though Alice and Bob both have a public node key to which they own the private secret opening a payment channel is not as easy as sending bitcoins to the 2 out of 2 multisignature output that belongs to the public keys of Alice and Bob.
Let us assume for a moment that Alice would send 100k Satoshi to the Multisig address resulting from hers and Bob's public node id.
In that case Alice will never be able to maintain her funds back without the help of Bob.
Of course we want our payment channels to work in a way that Alice does not need to trust Bob.
Bob could however refuse to sign a transaction that sends all those outputs back to an address that is controled by Alice.
He would be able to blackmail Alice to assign a significant amount of those Bitcoin to an output address that is controled by him.
Thus Bob can't steel the coins from Alice directly but he can threten Alice to have her coins lost forever.
This example shows that unfortunatelly opening a channel will be a little bit more complex than just sending Bitcoins to a multisignature address.
====



[NOTE]
====
The importance of the segwit upgrade.


====



In order to avoid the reuse of addresses Alice and Bob will generate a new set of keys for the multisig address that they use to open the channel.
Alice needs to inform Bob which key she intends to use for their channel and ask him which key he intends to use.
She will do that by sending Bob and `open_channel` message signaling her interest to open a channel.
This message contains a lot of additional data fields.
Most of them specify meta data which is necessary for the channel operation and can be be safely ignored for now.
We will only look at the following ones:

* [chain_hash:chain_hash]
* [32*byte:temporary_channel_id]
* [u64:funding_satoshis]
* [point:funding_pubkey]
* [point:revocation_basepoint], [point:payment_basepoint], [point:delayed_payment_basepoint], [point:htlc_basepoint], [point:first_per_commitment_point]

With the `chain_hash` Alice signals that she intends to open the channel on the Bitcoin blockchain.
While the Lightning Network was certainly invented to scale the amount of payments that can be conducted on the Bitcoin Network it is interesting to note that the network is designed in a way that allows to build channels over various currencies.
If a node has channels with more than one currency it is even possible to route payments through multi asset channels.
However this turns out to be a little bit tricky in reality as the exchange rate between currencies might change which might lead the forwarding node to wait for a better exchange rate to settle or to abort the payment process.
For the opening process the final channel id cannot be determined yet thus Alice needs to select a random channel id with Bob that she can use to identify the messages for this channel during the opening phase.
This design descision allows multiple channels to exist between two nodes - though currently only LND supports this feature.
Alice tells Bob for how many satoshis she wishes to open the channel.
This information is necessary to construct the commitment transaction ...


Once the channel is open Alice will be able to send 99k satoshi along this channel.
Bob on the other side will be able to receive 99k satoshi along that channel.
This means that initially Alice will not be able to recieve Bitcoins on this channel and that Bob initially will not be able to send Bitcoin along that channel.

=== Forwarding payments with HTLCs
In previous chapters we have seen that payment channels are maintained by two nodes by keeping two disjoint sequences of commitment transactions.
The pair of latest commitment transactions in both sequences encodes the current, agreed upon balance in the channel.
We have stated that two channel partners negotiate a new commitment transaction in order to change the balance and conduct a payment from one to another.
We are finally at the point to explain the communications protocol via Lightning messages and the usage of HTLCs that is executed within a payment channel to change the balance.
The same protocol will be executed along a path of channels if the network of channels is being utilized to make a payment between two participants without requiring them to have a dedicated payment channel connecting them directly.

Let us start with the payment channel with a capacity of 100 mBTC between Alice and Bob.
at its current state Alice and Bob have agreed that 20 mBTC belong to Bob and 80 mBTC belong to Alice.
As Alice bought a coffee flatrate for the week she has to pay 15 mBTC to Bob and wants to use this channel.
Just creating a new pair of commitment transactions and signing them is not so easy as the old ones have to be invalidated by sharing the revocation secret.
This process should be executed in a way that it is atomic meaning the nodes will either be able to negotiate a new state without giving the other side the chance to play tricks or it should fail.

[[routing-setup-htlc-0]]
.Let us look at the initial pair of most recent commitment transactions for Alice and Bob:
image:images/routing-setup-htlc-0.png[]

Alice sends the `update_add_HTLC` Lightning message to Bob.
The message type is 128 and has the following data fields:

* [`channel_id`:`channel_id`]
* [`u64`:`id`]
* [`u64`:`amount_msat`]
* [`sha256`:`payment_hash`]
* [`u32`:`cltv_expiry`]
* [`1366*byte`:`onion_routing_packet`]

As Bob and Alice might have more than one channel thus the `channel_id` is included to the message.
The `id` counter counts starts with 0 for the first HTLC that Alice offers to Bob and is increased by 1 with every subsequent offer.
The id of the HTLC is used to compute the derivation path of the bitcoin key that is used for the output of this particular HTLC.
In this way addresses changes with every payment and cannot be monitored by a third party.
Next the amount that Alice wants to send to Bob is entered to the `amount_msat` field.
As the name suggests the amount is depicted in millisatoshi even those cannot be enforced within the commitment transaction and within bitcoin.
Still Lightning nodes keep track of subsatoshi amounts to avoid rounding issues.
As in the offline example Alice includes the `payment_hash` in the next data field.
This was told to Alice by Bob in case she wants to just send money to him.
If Alice was to send Money to Gloria the Payment hash would have been given to Alice by Gloria.
We discussed the potential of time lock or deadline of the contract.
This is encoded in the `cltv_expiry`.
cltv stands for OP_CHECKTIMELOCKVERIFY and is the OP_CODE that will be used in the HTLC output and serve as the deadline in which the contract is valid.
Finally in the last data field there are 1336 Bytes of data included which is an `onion routing packet`.
The format of this packet will be discussed in the last section of this chapter.
For now it is important to note that it includes encrypted routing hints and information of the payment path that can only be partially decrypted by the recipient of the onion routing packet to extract information to whom to forward the payment or to learn that one as the final recipient.
In any case the onion roting packet is always of the same size preventing the possibility to guess the position of an intermediary node within a path.
In our particular case Bob will be able to decrypt the first couple bytes of the onion routing packet and learn that the payment is not to be forwarded but intended to be for him.

The received information is enough for Bob to create a new commitment transaction.
This commitment transaction now has not only 2 outputs encoding the balance between Alice and Bob but a third output which encodes the hashed time locked contract.

[[routing-setup-htlc-1]]
.Lets look at the newly created commitment transaction for Bob:
image:images/routing-setup-htlc-1.png[]

We can see that Bob Assumes that Alice will agree to lock 15 mBTC of her previous balance and assign it to the HTLC output.
Creating this HTLC output can be compared to giving Alice golden coins to the escrow service.
In our situation the bitcoin network can enforce the HTLC as Bob and Alice have agreed upon.
Bob's Balance has not changed yet.
In Bitcoin outputs are mainly described by scripts.
The received HTLC in Bob's commitment transaction will use the following bitcoin script to define the output:


   # To remote node with revocation key
    OP_DUP OP_HASH160 <RIPEMD160(SHA256(revocationpubkey))> OP_EQUAL
    OP_IF
        OP_CHECKSIG
    OP_ELSE
        <remote_HTLCpubkey> OP_SWAP OP_SIZE 32 OP_EQUAL
        OP_IF
            # To local node via HTLC-success transaction.
            OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
            2 OP_SWAP <local_HTLCpubkey> 2 OP_CHECKMULTISIG
        OP_ELSE
            # To remote node after timeout.
            OP_DROP <cltv_expiry> OP_CHECKLOCKTIMEVERIFY OP_DROP
            OP_CHECKSIG
        OP_ENDIF
    OP_ENDIF

We can see that there are basically three conditions to claim the output.

1. Directly if a revocation key is known. This would happen if at a later state Bob fraudulently publishes this particular commitment transaction. As a newer state could only be agreed upon if Alice has learnt Bob's half of the revocation secret she could directly claim the funds and keep them even if Bob was later able to provide a proof of payment. This is mainly described in this line `OP_DUP OP_HASH160 <RIPEMD160(SHA256(revocationpubkey))> OP_EQUAL` and can be down by using `<revocation_sig> <revocationpubkey> as a witness script.
2. If Bob has successfully delivered the payment and learnt the preimage he can spend the HTLC output with the help of the preimage and his `local_HTLC_secret`. This is to make sure that only Bob can spend this output if the commitment transaction hits the chain and not any other third party who might know the preimage because they had been included in the routing process. Claiming this output requires an HTLC-success transaction which we describe later.
3. Finally Alice can use her `remote_HTLC_secret` to spend the HTLC output after the timeout of `cltv_expiry` was passed by using the following witness script `<remoteHTLCsig> 0`

As the commitment transaction spends the 2 out of 2 multisig funding transaction Bob needs two signatures after he constructed this commitment transaction.
He can obviously compute his own signature but he needs also the signature from Alice.
As Alice initiated the payment and wanted the HTLC to be set up she will be reluctant to provide a signature.


[[routing-setup-htlc-2]]
.Alice sends the `commitment_signed` Lightning Message to Bob:
image:images/routing-setup-htlc-2.png[]

We can see in the diagram that Bob now has two valid commitment transactions.
Let us have a quick look at the `commitment_signed` Lightning message which has the type 132.
It has 4 data fields:

* [`channel_id`:`channel_id`]
* [`signature`:`signature`]
* [`u16`:`num_HTLCs`]
* [`num_HTLCs*signature`:`HTLC_signature`]

First it again states which for which of the channels between Alice and Bob this message is intended.
Then it has included a signature for the entire commitment transaction.
As commitment transactions can have several HTLCs and HTLC success transactions need signatures which might not be provided at the time when they are needed those signatures are all already send over to Bob.
If all signatures are valid Bob has a new commitment transaction.
At this time he would be able to publish either the old one or the new one without getting a penality as the old one is not yet revoked and invalidated.
However this is save for Alice as Bob has less money in this old state and is economically not incentivised to publish the old commitment transaction.
Alice on the other side has no problem if Bob publishes the new commitment transaction as she wanted to send him money.
If Bob can provide the preimage he is by their agreement and expectation entitled to claim the HTLC output.
Should Bob decide to sabotage to future steps of the protocol Alice can either publish her commitment transaction without Bob being able to punish her.
He will just not have received the funds from Alice.
This is important!
Despite the fact that Bob has a new commitment transaction with two valid signatures and an HTLC output inside he cannot seen his HTLC as being set up successfully.
He first needs to have Alice invalidate her old state.
That is why - in the case that he is not the final recipient of the funds - he should not forward the HTLC yet by setting up a new HTLC on the next channel with Wei.
Alice will not invalidate her commitment transaction yet as she has to first get her new commitment transaction and she wants Bob to invalidate his old commitment transaction which he can safely do at this time.

[[routing-setup-htlc-3]]
.Bob sends a `revoke_and_ack` Lighting message to Alice:
image:images/routing-setup-htlc-3.png[]

The `revoke_and_ack` Lightning message contains three data fields.
* [`channel_id`:`channel_id`]
* [`32*byte`:`per_commitment_secret`]
* [`point`:`next_per_commitment_point`]

While it is really simple and straight forward it is very crucial.
Bob shares the the `per_commitment_secret` of the old commitment transaction which serves as the revocation key and would allow Alice in future to penalize Bob if he publishes the old commitment transaction without the HTLC output.
As in a future Alice and Bob might want to negotiate additional commitment transactions he already shares back the `next_per_commitment_point` that he will use in his next commitment transaction.

Alice checks that the `per_commitment_secret` produces the last `per_commitment_point` and constructs her new commitment transaction with the HTLC output.
Alice's version of the HTLC output is slightly different to the one that Bob had.
The reason is the asymmetries of the penalty based payment channel construction protocol.
Alice is offering in her commitment transaction an HTLC to the `remote` partner of the channel while Bob as accepting and offered HTLC to himself the `local` partner of the channel.
Thus the Bitcoin script is adopted slightly.
It is a very good exercise to go through both scripts and see where they differ.
You could also try to use Bob's HTLC output script to come up with Alice's and vice versa and check your result with the following script.

    # To remote node with revocation key
    OP_DUP OP_HASH160 <RIPEMD160(SHA256(revocationpubkey))> OP_EQUAL
    OP_IF
        OP_CHECKSIG
    OP_ELSE
        <remote_HTLCpubkey> OP_SWAP OP_SIZE 32 OP_EQUAL
        OP_NOTIF
            # To local node via HTLC-timeout transaction (timelocked).
            OP_DROP 2 OP_SWAP <local_HTLCpubkey> 2 OP_CHECKMULTISIG
        OP_ELSE
            # To remote node with preimage.
            OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
            OP_CHECKSIG
        OP_ENDIF
    OP_ENDIF

Bob can redeem the HTLC with `<remoteHTLCsig> <payment_preimage>` as the witness script and in case the commitment transaction is revoked but published by Alice, Bob can trigger the penality by spending this output immediately with the following witness script `<revocation_sig> <revocationpubkey>`.

[[routing-setup-htlc-4]]
.Bob knows how Alice's commitment transaction will look like and sends over the necessary signatures.
image:images/routing-setup-htlc-4.png[]

This process is completely symmetrical to the one where Alice sent her signatures for Bob's new commitment transaction.
Now Alice is the one having two valid commitment transactions.
Technically she can still abort the payment by publishing her old commitment transaction to the bitcoin network.
No one would lose anything as Bob knows that the contract is still being set up and not fully set up yet.
This is a little bit different than how the situation would look like in a real world scenario.
Recall Alice and Bob both have set up a new commitment transaction and have exchanged signatures.
In the real world one would argue that this contract is now valid.

[[routing-setup-htlc-5]]
.However Bob knows that Alice has to invalidate her previous commitment transaction which she does
image:images/routing-setup-htlc-5.png[]

Now Bob and Alice both have a new commitment transaction with and additional HTLC output and we have achieved a major step towards updating a payment channel.
The new Balance of Alice and Bob does not reflect yet that Alice has successfully send 15 mBTC to Bob.
However the hashed time locked contracts are now set up in a way that secure settlement in exchange for the proof of payment will be possible.
This yields another round of communication with Lightning messages and setting up additional commitment transactions which in case of good cooperation remove the outstanding HTLCs.
Interestingly enough the `commitment_signed` and `revoke_and_ack` mechanism that we described to add an HTLC can be reused to update the commitment transaction.

If Bob was the recipient of the 15 mBTC and knows the preimage to the payment hash Bob can settle the HTLCs by sending and `update_fulfill_htlc` Lightning message to Alice.
This message has the type 130 and only 3 data fields:

* [`channel_id`:`channel_id`]
* [`u64`:`id`]
* [`32*byte`:`payment_preimage`]

As other messages Bob uses the `channel_id` field to indicates for which channel he returns the preimage.
The htlc that is being removed is identified by the same `id` that was used to set up the HTLC in the commitment transaction initially.
You might argue that Alice would not need to know the id of the HTLC for which Bob releases the preimage as the preimage and payment hash could be unique.
However with this design the protocol supports that a payment channel has several htlcs with the same preimage but only settles one.
One could argue that this does not make too much sense and it is good to be critical but this is how the protocol is designed and what it supports.
Finally in the last field Bob provides the `payment_preimage` which Alice can check hashes to the payment hash.

[WARNING]
====
When designing, implementing or studying a protocol one should ask: Is it safe to this or that in this moment of the protocol and can this be abused. We discussed for example the messages that where necessary for an HTLC to become valid. We pointed out that Bob should not see the received HTLC as valid even though he already has a new commitment transaction with signatures and invalidated his old commitment transaction before Alice also revoked her old commitment transaction. We also saw that no one is able to mess with the protocol of setting up a commitment transaction as in the worst case the protocol could be aborted and any dispute could be resolved by the Bitcoin Network. In the same way we should ask ourselves is it safe for Bob to just send out and release the preimage even though neither he nor alice have created the new pair of commitment transactions in which the HTLCs are removed. It is important to take a short break and ask yourself if Bob will in any case be able to claim the funds from the HTLC if the preimage is correct?
====

It is safe for Bob to tell Alice the preimage.
Imagine Alice decides that she would not want to pay Bob anymore and does not respond anymore to create a new pair of commitment transactions with the removed HTLC and the Balance on Bob's end.
In that case Bob could just force close the channel and publish his latest version of the commitment transaction.
As the time lock of the HTLC is not over yet with an onchain success transaction Bob would be able to claim and settle his 15 mBTC as he is the only person who is able to spend the HTLC output in the commitment transaction.
The other way around meaning Bob and Alice would negotiate a new commitment transaction with the removed HTLC would never be save for Alice.
If the signatures for the new commitment transaction are exchanged Bob has received the money and could decide not to release the preimage.

[NOTE]
====
Isn't it remarkable that even though the process of exchanging funds for an preimage seems to be happening concurrently at the same moment in time in reality it is actually happening one step after another but in the right order.
====


[NOTE]
====
The current construction could be generalized to multiparty channels and channel factories.
However the communication protocol would suffer from increased complexity.
====

Chapter overview:
  * describes how channels are put together at the script+transaction level
  * details how a channel if funded in the protocol
  ** including Key derrivation!
  * details how a channel is updated in the protocol (moved to routing!)
  * describes what needs to happen when a channel is force closed

Relevant questions to answer:
  * Channel construction:
      * What's the difference between a replace-by-revocation based and a replace-by-versioning commitment format?
      * What does the funding output script look like, what security guarantees does it give us?
      * What's the difference between CSV and CLTV? How do both of these use the existing fields of the transaction to enforce new behavior?
      * How do we implement revocation in our channel format?
      * What does the script on the commitment to the broadcaster look like?
      * What does the script on the commitment for the party that didn't broadcast look like?
      * How are HTLCs constructed? What are second-level HTLCs?
      * How has the commitment format in LN changed over time? What are some of the changes to the commitment format that've happened?
  * Funding flow and messages:
      * What are the messages exchanged to initiate a new channel with another peer?
      * What do the parameters such as the max in flight do?
      * How should the CSV values and the number of blocks until a channel is considered confirmed change with the size of the channel?
      * What are wumbo channels? How are they enabled?
      * What is an upfront shutdown address? What security does it offer?
      * Is it possible to open multiple channels in a single transaction?
  * Channel state machine:
      * What does Medium Access Control mean in the context of network protocols?
      * At a high level, how does the MAC protocol for 802.11 work?
      * What steps need to happen for a new commitment state to be proposed and irrevocably committed for both parties?
      * When is it safe for a party to forward a new HTLC to another peer? (may be out of scope for this chapter)
      * Is it possible to commit a
      * How does the current MAC protocol for the LN work?
        * What does an htlc_add message contain?
        * How are HTLCs cancelled or settled?
        * Can both parties propose updates at the same time?
        * Is it possible for a party to add a batch of HTLCs in a single go?
        * What constraints exist that both parties need to adhere to?
      * How are fees paid in a channel? Who pays which fees? Has this changed with newer commitment formats?
      * How would the MAC protocol need to change if we used channels with symmetric state?