<p>The htlcs are just an additional output in the commitment tx which spends the funding transaction (as you described) </p>

<p>So assume Alice and Bob have a channel of capacity 0.1 BTC in which alice owns 0.03 BTC. </p>

<p>On chain you have a multisig wallet that has 0.1 BTC and offchain you have a commitment tx with two outputs. </p>

<pre><code>0.03 to alice
0.07 to Bob
</code></pre>

<p>Let's assume Bob wants to pay Alice 0.015 BTC or wants to forward an htlc through Alice of the same amount a new commitment tx is negotiated (by which the old one is invalidated) that has 3 outputs</p>

<pre><code>0.03 to alice
0.055 to bob
0.015 htlc clsimable by Alice if she can show a preimage within a Timelock and afterwards by bob
</code></pre>

<p>Now if routing is successful alive provides the preimage and a new state is negotiated in which the htlc output is removed but added to slice balance resulting in</p>

<pre><code>0.045 to alice
0.055 to bob
</code></pre>

<p>Otherwise the htlc is removed but the amount is added to bobs output. </p>

<p>I omitted onchain fees for simplicity</p>

CC BY-SA 4.0
2019-05-25T09:31:12.177Z
So multiple unfinished HTLCs would just be added as extra outputs and you could have many outputs in that commitment tx (e.g. 20 outputs)?
Wapac
CC BY-SA 4.0
2019-05-25T10:07:44.173Z
Also, is it thus necessary to close the channel if single one out of all currently unfinished HTLCs fails?
Wapac
CC BY-SA 4.0
2019-05-25T19:45:20.113Z
You can have up to 483 concurrent htlcs. If an onion fails the htlc is removed no need to settle the channel on chain. But if the channels fails (for some other reason) and needs to be settled all htlcs will be resolved onchain
Rene Pickhardt
CC BY-SA 4.0
2019-05-26T09:34:46.403Z
Could you please elaborate on that? What do you mean by onion fails? When can channel fail? My question here was what happens if a single routed payment is not finished (i.e. times out), does this cause what you call channel fail?
Wapac
CC BY-SA 4.0
2019-05-27T11:52:08.097Z
No that causes that the routing process stops which means that the htlc is not forwarded and an error is send back so that the previous htlcs can also be cancled. The Channel fails usually off someone breaches the protocol. For example if wrongful data is sent over the transport layer (this would actually fail the connection which in turn will lead to failure of the channel). If a node fails the channel the most recent commitment tx is broadcast and a force close is initiated / executed
Rene Pickhardt
CC BY-SA 4.0
2019-05-25T08:41:15.383Z
2019-05-25T08:41:15.383Z
Rene Pickhardt
<p>I think I understand HTLCs, at least if they are on chain. I also have a basic understanding of how off chain channel looks like. </p>

<p>I understand it as follows. It is a 2-of-2 multisig transaction output, which is on chain and confirmed sufficiently. Before this transaction was put on chain, the parties created another transaction, which they haven't published yet. This second transaction is necessary in case either party would not be cooperative to provide its signature for the initial multisig.</p>

<p>This second transaction pays each party the agreed final balance as per current status of the channel. This transaction is ready to go on chain, it is fully signed, the parties just decided not to publish it yet because they may want to replace this second transaction with different finalising transaction.</p>

<p>Now the question is – When a payment is to be done through this channel using HTLC, what are the inputs to it? Is the output of the original multisig? If so, how would you do 2 or more HTLCs at the same time (i.e. you have enough liquidity on the channel to do multiple payments, but it takes time to finish current payment when someone wants to pay through you again)? </p>

<p>What would be the inputs for those other HTLCs? Exactly when is the finalising transaction spending the initial multisig updated in the database of the participants?</p>

<p>And would you need to close the channel and put a transaction on chain in case a single HTLC payment fails?</p>

<lightning-network><micropaymentchannels><hash-time-locked-contract>
How multiple unfinished payments in single LN channel work?
Wapac
# How multiple unfinished payments in single LN channel work?

(Asked by: username_0 on 2019-05-25)

I think I understand HTLCs, at least if they are on chain. I also have a basic understanding of how off chain channel looks like.

I understand it as follows. It is a 2-of-2 multisig transaction output, which is on chain and confirmed sufficiently. Before this transaction was put on chain, the parties created another transaction, which they haven't published yet. This second transaction is necessary in case either party would not be cooperative to provide its signature for the initial multisig.

This second transaction pays each party the agreed final balance as per current status of the channel. This transaction is ready to go on chain, it is fully signed, the parties just decided not to publish it yet because they may want to replace this second transaction with different finalising transaction.

Now the question is – When a payment is to be done through this channel using HTLC, what are the inputs to it? Is the output of the original multisig? If so, how would you do 2 or more HTLCs at the same time (i.e. you have enough liquidity on the channel to do multiple payments, but it takes time to finish current payment when someone wants to pay through you again)?

What would be the inputs for those other HTLCs? Exactly when is the finalising transaction spending the initial multisig updated in the database of the participants?

And would you need to close the channel and put a transaction on chain in case a single HTLC payment fails?

**Tags:** lightning-network, micropaymentchannels, hash-time-locked-contract


---

## 1 answers

### Answer by username_1 on 2019-05-25. Score: 1 | Accepted answer

The htlcs are just an additional output in the commitment tx which spends the funding transaction (as you described) 
So assume Alice and Bob have a channel of capacity 0.1 BTC in which alice owns 0.03 BTC. 
On chain you have a multisig wallet that has 0.1 BTC and offchain you have a commitment tx with two outputs. 
0.03 to alice
0.07 to Bob

Let's assume Bob wants to pay Alice 0.015 BTC or wants to forward an htlc through Alice of the same amount a new commitment tx is negotiated (by which the old one is invalidated) that has 3 outputs
0.03 to alice
0.055 to bob
0.015 htlc clsimable by Alice if she can show a preimage within a Timelock and afterwards by bob

Now if routing is successful alive provides the preimage and a new state is negotiated in which the htlc output is removed but added to slice balance resulting in
0.045 to alice
0.055 to bob

Otherwise the htlc is removed but the amount is added to bobs output. 
I omitted onchain fees for simplicity

> **Comments:**
> **username_0**: So multiple unfinished HTLCs would just be added as extra outputs and you could have many outputs in that commitment tx (e.g. 20 outputs)?  
> **username_0**: Also, is it thus necessary to close the channel if single one out of all currently unfinished HTLCs fails?  
> **username_1**: You can have up to 483 concurrent htlcs. If an onion fails the htlc is removed no need to settle the channel on chain. But if the channels fails (for some other reason) and needs to be settled all htlcs will be resolved onchain  
> **username_0**: Could you please elaborate on that? What do you mean by onion fails? When can channel fail? My question here was what happens if a single routed payment is not finished (i.e. times out), does this cause what you call channel fail?  
> **username_1**: No that causes that the routing process stops which means that the htlc is not forwarded and an error is send back so that the previous htlcs can also be cancled. The Channel fails usually off someone breaches the protocol. For example if wrongful data is sent over the transport layer (this would actually fail the connection which in turn will lead to failure of the channel). If a node fails the channel the most recent commitment tx is broadcast and a force close is initiated / executed  

---

