<p>The question was originally referring to unilateral channel closes, I could have made that clearer.</p>

<p>Sighash single does not work since it can only sign in/outs at the same index.</p>

<p>An idea proposed by lightning developers has been to add output hooks (spendable by each counter-party) with no/low amounts which are spendable by child transactions which lift the fee-rate of the entire tx chain (CPFP).</p>

<p>This has the problem that a long (malicious) low fee-rate chain can max out the descendent limit and anchor the parent at the bottom of the mempool, thereby preventing any CPFP by the counterparty (This proposal would have 2 hooks per commitment transaction).</p>

<p>The solution for this is the <a href="https://github.com/bitcoin/bitcoin/pull/15681" rel="nofollow noreferrer">mempool carveout in core</a> (merged in July 2019), which applies when the (user-configurable) descendent limit has been reached. A single child can still be accepted to the tx package in this case, which is used by the non-malicious party to increase feerate of the tx package.</p>

CC BY-SA 4.0
2019-08-12T17:51:15.807Z
2019-08-13T21:13:40.817Z
2019-08-13T21:13:40.817Z
James C.
<p>Let's distinguish a couple cases:</p>

<h2>Cooperative close</h2>

<p>In the case of a cooperative close, the two channel partner can agree on any transaction they want. Thus, they can pick the fee rate on the spot. As the two outputs would likely not have any timelocks, either party could use child-pays-for-parent (CPFP) to bump the initial closing transaction. They could even issue an RBF transaction initially and update it later if it doesn't confirm quickly enough.</p>

<h2>Unilateral close</h2>

<p>The party that initiates the closing transaction has their funds locked to allow the counterparty to apply their breach-remedy if an old state was published. This means that traditionally only the counterparty can make use of CPFP to accelerate the closing transaction. This is inconvenient, because there wouldn't be a need for a unilateral close unless the counterparty were currently uncooperative.</p>

<p>The recent <a href="https://github.com/lightningnetwork/lnd/releases/tag/v0.7.0-beta" rel="nofollow noreferrer">lnd 0.7.0 release notes</a> mention that improvements were made to their transaction closing procedures to support both RBF and CPFP.</p>

CC BY-SA 4.0
2019-08-12T17:39:20.763Z
Thank you @Murch. Since I asked the question, my understanding has evolved a little. Firstly, output hooks for both parties can be added to commitment tx's so that CPFP can be applied during unilateral closing by any party. This has the problem that a long low fee-rate chain can max out the descendent limit and anchor the parent at bottom of mempool, and preventing any CPFP by counterparty. The solution for this is the mempool carveout in core (https://github.com/bitcoin/bitcoin/pull/15681), which allows for an additional child TX even if the descendent limit has been reached.
James C.
CC BY-SA 4.0
2019-08-11T19:40:53.100Z
2019-08-11T19:46:02.620Z
2019-08-11T19:46:02.620Z
Murch
<blockquote>
  <p>Are out-of-band fee payments to confirm a lightning closing transaction the only way to manage a situation where the sat/kw of a previously signed commitment tx are simply below market?</p>
</blockquote>

<p>Yes, you will have to do it out-of-band, as you would not be able to use fee rate that is higher than the last signed commitment transaction within the framework of the Lightning Network protocol. <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md" rel="nofollow noreferrer">BOLT #2</a> states that when the funder sends a <code>closing_signed</code> message, the <code>fee_satoshi</code> parameter should be less than or equal to the base fee of the final commitment transaction. The receiver should fail the connection if it doesn't meet this criteria.</p>

<p>However, the above rules can be circumvented. The first workaround was explained by @Murch through CPFP and RBF. The second one can be done within the Lightning Network protocol framework. The funder can send a <code>update_fee</code> message (before the <code>shutdown</code> message) updating its fee rate to a higher one. The funder must however, afford the new fee rate on the receiving node's current commitment transaction or the peer receiving the message will fail the channel. It can then send a dummy transaction (say 1 satoshi) across that channel to its peer. Now, send a <code>closing_signed</code> message with the same <code>fee_satoshi</code> as the last updated fee and your transaction can go through within the bounds of the Lightning Network protocol because it was this fee that was used for the last commitment transaction.</p>

<blockquote>
  <p>If additional inputs/outputs could be added, fees could be easily adjusted to the fee rate during channel closing and not at the time when the tx was signed</p>
</blockquote>

<p>It would be a double edged sword and could create the issue of transaction confirmation. Say one party signs with <code>SIGHASH_SINGLE</code>, and then waits for the other party to sign and broadcast the transaction. The other party can then add multiple addresses to which it wants the payout. Due to these added outputs, the <code>feerate_per_kw</code> will be lower than what the counterparty agreed to at the time of <code>open_channel</code> message and hence the time that can take to confirm this transaction will be higher than what the counterparty node expected. This can further be used for DoS attacks, where I open channel with participants, but then add as many outputs such that the fee rate dips below that miners would consider in including it in the block, thus locking nodes out of their funds.</p>

CC BY-SA 4.0
2019-08-12T17:43:38.040Z
Thanks Ugam Kamat. My understanding has improved on this since asking this question 7 months ago. Sure, the feerate can be updated collaboratively. I am interested in the unilateral close case. Please consider my comment (mempool carve-out) to the answer above regarding the anchoring of the commitment transaction to the bottom of mempool via low-fee-rate children.
James C.
CC BY-SA 4.0
2019-08-12T08:06:56.057Z
2019-08-12T08:06:56.057Z
Ugam Kamat
<p>Are out-of-band fee payments to confirm a lightning closing transaction the only way to manage a situation where the sat/kw of a previously signed commitment tx are simply below market?</p>

<p>If additional inputs/outputs could be added, fees could be easily adjusted to the fee rate during channel closing and not at the time when the tx was signed...</p>

CC BY-SA 4.0
2018-12-24T13:40:04.153Z
Hmm... I realize it wouldn't be possible to `single` sign multiple in/output pairs, which all share the same multisig input, given that the indices between input and output would differ with all pairs except for one.
James C.
<transactions><transaction-fees><unconfirmed-transactions><lightning-network>
Why can’t lightning tx’s be signed with sighash single to allow for fee updates?
James C.
# Why can’t lightning tx’s be signed with sighash single to allow for fee updates?

(Asked by: username_0 on 2018-12-23)

Are out-of-band fee payments to confirm a lightning closing transaction the only way to manage a situation where the sat/kw of a previously signed commitment tx are simply below market?

If additional inputs/outputs could be added, fees could be easily adjusted to the fee rate during channel closing and not at the time when the tx was signed...

**Tags:** transactions, transaction-fees, unconfirmed-transactions, lightning-network

> **Comments:**
> **username_0**: Hmm... I realize it wouldn't be possible to `single` sign multiple in/output pairs, which all share the same multisig input, given that the indices between input and output would differ with all pairs except for one.  

---

## 3 answers

### Answer by username_0 on 2019-08-12. Score: 1 | Accepted answer

The question was originally referring to unilateral channel closes, I could have made that clearer.

Sighash single does not work since it can only sign in/outs at the same index.

An idea proposed by lightning developers has been to add output hooks (spendable by each counter-party) with no/low amounts which are spendable by child transactions which lift the fee-rate of the entire tx chain (CPFP).

This has the problem that a long (malicious) low fee-rate chain can max out the descendent limit and anchor the parent at the bottom of the mempool, thereby preventing any CPFP by the counterparty (This proposal would have 2 hooks per commitment transaction).

The solution for this is the [mempool carveout in core](https://github.com/bitcoin/bitcoin/pull/15681) (merged in July 2019), which applies when the (user-configurable) descendent limit has been reached. A single child can still be accepted to the tx package in this case, which is used by the non-malicious party to increase feerate of the tx package.


---

### Answer by username_1 on 2019-08-11. Score: 2

Let's distinguish a couple cases:

## Cooperative close

In the case of a cooperative close, the two channel partner can agree on any transaction they want. Thus, they can pick the fee rate on the spot. As the two outputs would likely not have any timelocks, either party could use child-pays-for-parent (CPFP) to bump the initial closing transaction. They could even issue an RBF transaction initially and update it later if it doesn't confirm quickly enough.

## Unilateral close

The party that initiates the closing transaction has their funds locked to allow the counterparty to apply their breach-remedy if an old state was published. This means that traditionally only the counterparty can make use of CPFP to accelerate the closing transaction. This is inconvenient, because there wouldn't be a need for a unilateral close unless the counterparty were currently uncooperative.

The recent [lnd 0.7.0 release notes](https://github.com/lightningnetwork/lnd/releases/tag/v0.7.0-beta) mention that improvements were made to their transaction closing procedures to support both RBF and CPFP.

> **Comments:**
> **username_0**: Thank you @username_1. Since I asked the question, my understanding has evolved a little. Firstly, output hooks for both parties can be added to commitment tx's so that CPFP can be applied during unilateral closing by any party. This has the problem that a long low fee-rate chain can max out the descendent limit and anchor the parent at bottom of mempool, and preventing any CPFP by counterparty. The solution for this is the mempool carveout in core (https://github.com/bitcoin/bitcoin/pull/15681), which allows for an additional child TX even if the descendent limit has been reached.  

---

### Answer by username_2 on 2019-08-12. Score: 1

> Are out-of-band fee payments to confirm a lightning closing transaction the only way to manage a situation where the sat/kw of a previously signed commitment tx are simply below market?

Yes, you will have to do it out-of-band, as you would not be able to use fee rate that is higher than the last signed commitment transaction within the framework of the Lightning Network protocol. [BOLT #2](https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md) states that when the funder sends a `closing_signed` message, the `fee_satoshi` parameter should be less than or equal to the base fee of the final commitment transaction. The receiver should fail the connection if it doesn't meet this criteria.

However, the above rules can be circumvented. The first workaround was explained by @username_1 through CPFP and RBF. The second one can be done within the Lightning Network protocol framework. The funder can send a `update_fee` message (before the `shutdown` message) updating its fee rate to a higher one. The funder must however, afford the new fee rate on the receiving node's current commitment transaction or the peer receiving the message will fail the channel. It can then send a dummy transaction (say 1 satoshi) across that channel to its peer. Now, send a `closing_signed` message with the same `fee_satoshi` as the last updated fee and your transaction can go through within the bounds of the Lightning Network protocol because it was this fee that was used for the last commitment transaction.

> If additional inputs/outputs could be added, fees could be easily adjusted to the fee rate during channel closing and not at the time when the tx was signed

It would be a double edged sword and could create the issue of transaction confirmation. Say one party signs with `SIGHASH_SINGLE`, and then waits for the other party to sign and broadcast the transaction. The other party can then add multiple addresses to which it wants the payout. Due to these added outputs, the `feerate_per_kw` will be lower than what the counterparty agreed to at the time of `open_channel` message and hence the time that can take to confirm this transaction will be higher than what the counterparty node expected. This can further be used for DoS attacks, where I open channel with participants, but then add as many outputs such that the fee rate dips below that miners would consider in including it in the block, thus locking nodes out of their funds.

> **Comments:**
> **username_0**: Thanks username_2 username_2. My understanding has improved on this since asking this question 7 months ago. Sure, the feerate can be updated collaboratively. I am interested in the unilateral close case. Please consider my comment (mempool carve-out) to the answer above regarding the anchoring of the commitment transaction to the bottom of mempool via low-fee-rate children.  

---

