Why can’t lightning tx’s be signed with sighash single to allow for fee updates?

Question

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...

Answer 1

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 mention that improvements were made to their transaction closing procedures to support both RBF and CPFP.

Answer 2

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 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 @Murch 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.

Answer 3

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 (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.