<blockquote>
<p>Can B now unilaterally close the channel given that to_remote output of A is 0 (this amount is below the dust limit) and to_local output is c or will this lead to failing of channel closure?</p>
</blockquote>
<p>It can. If the output of <code>A</code> ended up being 0, the closing transaction would simply not include that output. That won't be the case though, check the last answer for why.</p>
<blockquote>
<p>Is it so that channel closure is allowed only when A has balance more than the dust limit?</p>
</blockquote>
<p>No, a channel closure is always allowed. If an output of the closing transaction is below the dust limit, that output will simply not be created, so the balance corresponding to that output will be set as fees. You can check <a href="https://github.com/lightning/bolts/blob/master/03-transactions.md#dust-limits" rel="nofollow noreferrer">BOLT3</a> for more details on that.</p>
<blockquote>
<p>Also while doing a channel update, does A need to keep a channel_reserve that prevents him from transferring all the c coins to B? Or is this something checked only during open channel?</p>
</blockquote>
<p><code>A</code> does indeed need to keep a <code>channel_reserve</code>, as so does <code>B</code>, therefore, <code>A</code> balance will never be 0 (assuming she's the one unilaterally funding the channel), and <code>B</code>'s will never go below the limit once his balance is above it.</p>

CC BY-SA 4.0
2023-10-17T14:20:02.697Z
How is A enforced to not exhaust the channel_reserve while updating the channel? So suppose A wants to do 1 single channel update that sends all c coins to B. Then will B deny signing this off-chain transaction seeing that A has exhausted the channel reserve and fail the channel?
Subhra Mazumdar
CC BY-SA 4.0
2023-10-17T14:23:22.337Z
Yes. https://github.com/lightning/bolts/blob/master/02-peer-protocol.md#rationale
sr_gi
CC BY-SA 4.0
2023-10-17T14:28:08.780Z
Thanks for sharing. But this is where I am having the confusion. It mentions that this check holds true for the initial commitment transaction while accept channel (opening of channel phase) but what about channel updates done later? Suppose A does x number of transactions, each transferring c/x coins, so will B deny signing the i^th channel update if B finds that A will have a balance less than channel reserve after i^th update?
Subhra Mazumdar
CC BY-SA 4.0
2023-10-17T14:38:44.377Z
It actually says the opposite, given this is normally not held by one of the sides for the initial commitment (given channels are usually one-sided when funded): "Initially, this reserve may not be met, as only one side has funds; but the protocol ensures that there is always progress toward meeting this reserve, and once met, it is maintained."
sr_gi
CC BY-SA 4.0
2023-10-17T14:38:50.513Z
You can look down the same doc for "Adding an HTLC: update_add_htlc", under "A receiving node : receiving an amount_msat that the sending node cannot afford at the current feerate_per_kw (while maintaining its channel reserve and any to_local_anchor and to_remote_anchor costs):
SHOULD send a warning and close the connection, or send an error and fail the channel."
sr_gi
CC BY-SA 4.0
2023-10-17T14:54:30.120Z
Thanks for the clarification and pointing this out that for every update channel_reserve constraint is maintained.
Subhra Mazumdar
CC BY-SA 4.0
2023-10-17T15:23:25.177Z
Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/149163/discussion-between-subhra-mazumdar-and-sr-gi).
Subhra Mazumdar
CC BY-SA 4.0
2023-10-17T14:11:55.247Z
2023-10-17T14:11:55.247Z
sr_gi
<p>If there is a lightning channel A-B where A had a balance of c coins and B had 0 balance, it could be the case that A makes several off-chain payments and now the balance of A is 0 and balance of B is c.</p>
<p>Can B now unilaterally close the channel given that <code>to_remote</code> output of A is 0 (this amount is below the dust limit) and <code>to_local</code> output is c or will this lead to failing of channel closure? Is it so that channel closure is allowed only when A has balance more than the dust limit? Also while doing a channel update, does A need to keep a <code>channel_reserve</code> that prevents him from transferring all the c coins to B? Or is this something checked only during open channel?</p>

<lightning-network><ln-closing-channels>
to_remote output 0 during unilateral closing of lightning channel
Subhra Mazumdar
# to_remote output 0 during unilateral closing of lightning channel

(Asked by: username_0 on 2023-10-17)

If there is a lightning channel A-B where A had a balance of c coins and B had 0 balance, it could be the case that A makes several off-chain payments and now the balance of A is 0 and balance of B is c.

Can B now unilaterally close the channel given that `to_remote` output of A is 0 (this amount is below the dust limit) and `to_local` output is c or will this lead to failing of channel closure? Is it so that channel closure is allowed only when A has balance more than the dust limit? Also while doing a channel update, does A need to keep a `channel_reserve` that prevents him from transferring all the c coins to B? Or is this something checked only during open channel?

**Tags:** lightning-network, ln-closing-channels


---

## 1 answers

### Answer by username_1 on 2023-10-17. Score: 2 | Accepted answer

> Can B now unilaterally close the channel given that to\_remote output of A is 0 (this amount is below the dust limit) and to\_local output is c or will this lead to failing of channel closure?

It can. If the output of `A` ended up being 0, the closing transaction would simply not include that output. That won't be the case though, check the last answer for why.

> Is it so that channel closure is allowed only when A has balance more than the dust limit?

No, a channel closure is always allowed. If an output of the closing transaction is below the dust limit, that output will simply not be created, so the balance corresponding to that output will be set as fees. You can check [BOLT3](https://github.com/lightning/bolts/blob/master/03-transactions.md#dust-limits) for more details on that.

> Also while doing a channel update, does A need to keep a channel\_reserve that prevents him from transferring all the c coins to B? Or is this something checked only during open channel?

`A` does indeed need to keep a `channel_reserve`, as so does `B`, therefore, `A` balance will never be 0 (assuming she's the one unilaterally funding the channel), and `B`'s will never go below the limit once his balance is above it.

> **Comments:**
> **username_0**: How is A enforced to not exhaust the channel_reserve while updating the channel? So suppose A wants to do 1 single channel update that sends all c coins to B. Then will B deny signing this off-chain transaction seeing that A has exhausted the channel reserve and fail the channel?  
> **username_1**: Yes. https://github.com/lightning/bolts/blob/master/02-peer-protocol.md#rationale  
> **username_0**: Thanks for sharing. But this is where I am having the confusion. It mentions that this check holds true for the initial commitment transaction while accept channel (opening of channel phase) but what about channel updates done later? Suppose A does x number of transactions, each transferring c/x coins, so will B deny signing the i^th channel update if B finds that A will have a balance less than channel reserve after i^th update?  
> **username_1**: It actually says the opposite, given this is normally not held by one of the sides for the initial commitment (given channels are usually one-sided when funded): "Initially, this reserve may not be met, as only one side has funds; but the protocol ensures that there is always progress toward meeting this reserve, and once met, it is maintained."  
> **username_1**: You can look down the same doc for "Adding an HTLC: update_add_htlc", under "A receiving node : receiving an amount_msat that the sending node cannot afford at the current feerate_per_kw (while maintaining its channel reserve and any to_local_anchor and to_remote_anchor costs): SHOULD send a warning and close the connection, or send an error and fail the channel."  
> **username_0**: Thanks for the clarification and pointing this out that for every update channel_reserve constraint is maintained.  
> **username_0**: Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/149163/discussion-between-username_0-username_0-and-username_1).  

---

