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.
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. Dec 24 '18 at 13:40