user52573: 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?

user81940: 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. 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:
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. [...] 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.


52573: <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>
 81940: <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>
