Closing

Check that all closing outputs are above bitcoin's dust limit for their script type, otherwise there is a risk that the closing transaction will not be relayed to miners' mempool and will not confirm. The various dust limits are detailed in https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#dust-limits

Claim all the outputs that we've received from our current commit tx. This will be done using 2nd stage HTLC transactions.

Claim all the outputs that we've received from their current commit tx.

Claims the output of an [HtlcSuccessTx] or [HtlcTimeoutTx] transaction using a revocation key.

Once we've fetched htlc information for a revoked commitment from the DB, we create penalty transactions to claim all htlc outputs.

When an unexpected transaction spending the funding tx is detected:

In CLOSING state, any time we see a new transaction, we try to extract a preimage from it in order to fulfill the corresponding incoming htlc in an upstream channel.

This helper function tells if the utxos consumed by the given transaction has already been irrevocably spent (possibly by this very transaction)

As soon as a local or remote commitment reaches min_depth, we know which htlcs will be settled on-chain (whether or not they actually have an output in the commitment tx).

If a commitment tx reaches min_depth, we need to fail the outgoing htlcs that will never reach the blockchain. It could be because only us had signed them, or because a revoked commitment got confirmed.

In CLOSING state, when we are notified that a transaction has been confirmed, we analyze it to find out if one or more htlcs have timed out and need to be failed in an upstream channel.