<h2>If worried about the original closing transaction having too high of fees:</h2>

<p>The signed closing transaction that you're worried about (with too high of fees) has not yet been broadcast to the network, so no harm no foul (yet). </p>

<p><strong>If the two parties are cooperative</strong>, they can just agree to sign a new transaction with lower fees and broadcast that to close out the payment channel (this should be advantageous for both of them anyway).</p>

<p><strong>If the two parties are NOT cooperative</strong>, it might be best to just broadcast the original closing transaction and eat the fees.</p>

<blockquote>
  <p>Is replace-by-fee possible for LN's closing transaction?</p>
</blockquote>

<p>Replace-by-fee only applies to transactions that have already been broadcast to the network. Also, they only help if you're increasing fees, not decreasing them, so it doesn't apply to this situation.</p>

<h2>If worried about the original closing transaction having too low of fees:</h2>

<p><strong>If the two parties are cooperative</strong>, you can just sign a new closing transaction with higher fees and broadcast that.</p>

<p><strong>If the two parties are NOT cooperative</strong>, just broadcast the original closing transaction and hope that the transaction does not get stuck in the mempool. Also make sure that the original closing transaction has a high enough fee that there is little worry about it getting stuck in the mempool. Even somewhat non-cooperative parties should be willing to re-sign and lower the fees to close out the payment channel. Overall, this is the trickier scenario to predict.</p>

<blockquote>
  <p>Is replace-by-fee possible for LN's closing transaction?</p>
</blockquote>

<p>Again, replace-by-fee only applies to transactions that have already been broadcast to the network. Also, this would require a cooperative party.</p>

CC BY-SA 3.0
2017-12-28T06:46:27.690Z
No, I'm (most) worried about too low fee, and not cooperative party.
CoperNick
CC BY-SA 3.0
2017-12-28T16:00:59.500Z
@CoperNick I updated my answer with more conditional scenarios. It's still a tricky problem that you're bringing up.
Ryan McGeary
CC BY-SA 3.0
2017-12-28T18:59:43.560Z
Thanks. After your update I see potential attack scenario on channel with more than one balance updates with different transaction fees. Maybe see you in next question.
CoperNick
CC BY-SA 3.0
2018-01-26T18:26:02.300Z
Isn't "Child pays for parent" another way to resolve a closing transaction having too low fees? I.e. broadcast the closing transaction with small fees and broadcast a subsequent dependent transaction with high fees.
Marc-André Lafortune
CC BY-SA 3.0
2017-12-28T02:14:14.573Z
2017-12-28T16:00:25.853Z
2017-12-28T16:00:25.853Z
Ryan McGeary
<p>To be clear: Following is not about fees in Lightning Network. Following is about fees on blockchain for transaction which closes the channel in LN. </p>

<p>Channel closing transaction can be created months before broadcasting to blockchain network. How the fee for the blockchain transaction is calculated without knowing the (far) future situation in mempool?</p>

<p>Is replace-by-fee possible for LN's closing transaction? There are different types of closing transaction — maybe answer is different for each type of closing transaction.</p>

<p>Is the fee calculation related to current situation in mempool? I found some calculations <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#fees" rel="noreferrer">here</a>, but I didn't found any relation to dynamically changing situation in mempool.</p>

<transaction-fees><lightning-network><replace-by-fee>
When closing the channel for LN - how to calculate the fee for the blockchain transaction?
CoperNick
# When closing the channel for LN - how to calculate the fee for the blockchain transaction?

(Asked by: username_0 on 2017-12-28)

To be clear: Following is not about fees in Lightning Network. Following is about fees on blockchain for transaction which closes the channel in LN.

Channel closing transaction can be created months before broadcasting to blockchain network. How the fee for the blockchain transaction is calculated without knowing the (far) future situation in mempool?

Is replace-by-fee possible for LN's closing transaction? There are different types of closing transaction — maybe answer is different for each type of closing transaction.

Is the fee calculation related to current situation in mempool? I found some calculations [here](https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#fees), but I didn't found any relation to dynamically changing situation in mempool.

**Tags:** transaction-fees, lightning-network, replace-by-fee


---

## 1 answers

### Answer by username_1 on 2017-12-28. Score: 11 | Accepted answer

## If worried about the original closing transaction having too high of fees:

The signed closing transaction that you're worried about (with too high of fees) has not yet been broadcast to the network, so no harm no foul (yet).

**If the two parties are cooperative**, they can just agree to sign a new transaction with lower fees and broadcast that to close out the payment channel (this should be advantageous for both of them anyway).

**If the two parties are NOT cooperative**, it might be best to just broadcast the original closing transaction and eat the fees.

> Is replace-by-fee possible for LN's closing transaction?

Replace-by-fee only applies to transactions that have already been broadcast to the network. Also, they only help if you're increasing fees, not decreasing them, so it doesn't apply to this situation.

## If worried about the original closing transaction having too low of fees:

**If the two parties are cooperative**, you can just sign a new closing transaction with higher fees and broadcast that.

**If the two parties are NOT cooperative**, just broadcast the original closing transaction and hope that the transaction does not get stuck in the mempool. Also make sure that the original closing transaction has a high enough fee that there is little worry about it getting stuck in the mempool. Even somewhat non-cooperative parties should be willing to re-sign and lower the fees to close out the payment channel. Overall, this is the trickier scenario to predict.

> Is replace-by-fee possible for LN's closing transaction?

Again, replace-by-fee only applies to transactions that have already been broadcast to the network. Also, this would require a cooperative party.

> **Comments:**
> **username_0**: No, I'm (most) worried about too low fee, and not cooperative party.  
> **username_1**: @username_0 I updated my answer with more conditional scenarios. It's still a tricky problem that you're bringing up.  
> **username_0**: Thanks. After your update I see potential attack scenario on channel with more than one balance updates with different transaction fees. Maybe see you in next question.  
> **username_2**: Isn't "Child pays for parent" another way to resolve a closing transaction having too low fees? I.e. broadcast the closing transaction with small fees and broadcast a subsequent dependent transaction with high fees.  

---

