contractcourt: implement smarter "go to chain" heuristics in the channelArbitrator

[Roasbeef]

The channelArbitrator, amongst may other things is responsible for deciding when we should go to chain in order to sweep outputs on-chain from expired contracts. We use the shouldGoOnChain function currently to decide exactly when we should go on chain. Atm, the function is very basic, and will determine that we need to go on chain if the HTLC is about to expire. However, this doesn't capture the cost of going on chain. For example, if we have a 1000 satoshi HTLC that's about to expire, and it would take 20k satoshis to actually fully sweep the output, then the cost simply isn't worth it. The shouldGoOnChain function should be modified to capture such opportunity cost heuristics.

Steps To Completion

• Extend the shouldGoOnChain method to take into account (all or some of): the on chain fees to sweep an HTLC, the duration that an HTLC has been active, the fee revenue related to the channel we're examining (as if the channel is popular we shouldn't close it to sweep a single HTLC), the CSV value.

• A series of tests should be written to ensure that each of the heuristics are properly implemented and are adhered to by the channelArbitrator.

[34ro]

@Roasbeef I'd like to try this.

the on chain fees to sweep an HTLC, the duration that an HTLC has been active

I think this is not so difficult if it is implemented like estimatesmartfee in bitcoind.
It's the first task.

the fee revenue related to the channel we're examining (as if the channel is popular we shouldn't close it to sweep a single HTLC), the CSV value

It is difficult to define what is CSV for LN.

[carlaKC]

So in some cases (say high fees and a small htlc), we'd just not go on chain and take the hit of losing the htlc amount rather than losing more by going on chain non-economically?

For example, if we have a 1000 satoshi HTLC that's about to expire, and it would take 20k satoshis to actually fully sweep the output, then the cost simply isn't worth it.

If so, I think that we'd need some way to record that we deemed a htlc non-economical to sweep? Otherwise if they're swept by our peer we've got less funds than we'd expect and have to start following outputs on chain to figure out what happened.