<p>As pointed out the funder of the channel is currently responsible for paying the fees and deciding them. <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#updating-fees-update_fee" rel="nofollow noreferrer">BOLT 02 specifies the <code>update_fee</code> message to be used to signal the fee rate</a>. There it says:</p>
<blockquote>
<p>The node responsible for paying the Bitcoin fee SHOULD send <code>update_fee</code> to ensure the current fee rate is sufficient (by a significant margin) for timely processing of the commitment transaction. The node not responsible for paying the Bitcoin fee: MUST NOT send <code>update_fee</code>. A receiving node: if the <code>update_fee</code> is too low for timely processing, OR is unreasonably large: SHOULD fail the channel.</p>
</blockquote>
<p>In the case of a collaborative close <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#closing-negotiation-closing_signed" rel="nofollow noreferrer">there is a an algorithm that is part of the closing negotiations</a>:</p>
<p>The <code>closing_signed</code> message contains the follwoing fields</p>
<pre><code>type: 39 (closing_signed)
data:
[channel_id:channel_id]
[u64:fee_satoshis]
[signature:signature]
</code></pre>
<p>I quote again:</p>
<blockquote>
<p>The sending node: MUST set <code>fee_satoshis</code> less than or equal to the base fee of the final commitment transaction, <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#fee-calculation" rel="nofollow noreferrer">as calculated in BOLT #3</a>. [...] if the receiver agrees with the fee: SHOULD reply with a closing_signed with the same <code>fee_satoshis</code> value. otherwise: MUST propose a value &quot;strictly between&quot; the received <code>fee_satoshis</code> and its previously-sent <code>fee_satoshis</code>. [...]
The &quot;strictly between&quot; requirement ensures that forward progress is made, even if only by a single satoshi at a time.</p>
</blockquote>

CC BY-SA 4.0
2021-05-22T21:49:22.337Z
After a bit more digging on this it seems that, at least in lnd's case, the update_fee messages are sent in response to fee estimates from the underlying bitcoin daemon. That would then seem to mean that the close fee cannot be controlled by the user and is pretty much a direct function of fee estimates?
sipsorcery
CC BY-SA 4.0
2021-05-22T23:27:32.453Z
The users can choose which software they use to communicate with the Bitcoin network and where they get fee estimates from. But I think it is not only lnd that uses automated fee estimation in the protocol
Rene Pickhardt
CC BY-SA 4.0
2021-05-16T16:02:04.417Z
2021-05-16T16:02:04.417Z
Rene Pickhardt
<p>How does a Lightning Network channel initiator set a limit on the fee rate they are willing to accept for the channel close?</p>
<p>And a second question is how can the close fee be negotiated during a collaborative close?</p>

<lightning-network>
Set fee limit for Lightning Close Channel
sipsorcery
# Set fee limit for Lightning Close Channel

(Asked by: username_0 on 2021-05-16)

How does a Lightning Network channel initiator set a limit on the fee rate they are willing to accept for the channel close?

And a second question is how can the close fee be negotiated during a collaborative close?

**Tags:** lightning-network


---

## 1 answers

### Answer by username_1 on 2021-05-16. Score: 3 | Accepted answer

As pointed out the funder of the channel is currently responsible for paying the fees and deciding them. [BOLT 02 specifies the `update_fee` message to be used to signal the fee rate](https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#updating-fees-update_fee). There it says:

> The node responsible for paying the Bitcoin fee SHOULD send `update_fee` to ensure the current fee rate is sufficient (by a significant margin) for timely processing of the commitment transaction. The node not responsible for paying the Bitcoin fee: MUST NOT send `update_fee`. A receiving node: if the `update_fee` is too low for timely processing, OR is unreasonably large: SHOULD fail the channel.

In the case of a collaborative close [there is a an algorithm that is part of the closing negotiations](https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#closing-negotiation-closing_signed):

The `closing_signed` message contains the follwoing fields

```
type: 39 (closing_signed)
data:
[channel_id:channel_id]
[u64:fee_satoshis]
[signature:signature]

```

I quote again:

> The sending node: MUST set `fee_satoshis` less than or equal to the base fee of the final commitment transaction, [as calculated in BOLT #3](https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#fee-calculation). [...] if the receiver agrees with the fee: SHOULD reply with a closing\_signed with the same `fee_satoshis` value. otherwise: MUST propose a value "strictly between" the received `fee_satoshis` and its previously-sent `fee_satoshis`. [...]
> The "strictly between" requirement ensures that forward progress is made, even if only by a single satoshi at a time.

> **Comments:**
> **username_0**: After a bit more digging on this it seems that, at least in lnd's case, the update_fee messages are sent in response to fee estimates from the underlying bitcoin daemon. That would then seem to mean that the close fee cannot be controlled by the user and is pretty much a direct function of fee estimates?  
> **username_1**: The users can choose which software they use to communicate with the Bitcoin network and where they get fee estimates from. But I think it is not only lnd that uses automated fee estimation in the protocol  

---

