Matt Corallo

The motivation here is to retry invoice_requests. For non-mobile in a world where we can route onion messages, its probably not useful because we can route onion messages along many...

The alternative options here are basically (a) do it during message handling using std to detect time passing, (b) do it during message handling without time passing, (c) this (maybe...

ISTM if we want to avoid this we'll want a new method on `ChannelMessageHandler` indicating that we've received *any* message from any peer for any handler, which can then trigger...

> When retrying, should we be going through all the PaymentPending messages, or is there a way we would be prioritizing which ones to retry first? I don't see why...

For received HTLCs that haven't expired, the counterparty can't claim them so there's not much to talk about there (but indeed if they're getting close to expiry it may make...

> Asking so that I don't accidentally remove the tests If you do the move-only parts in a separate move-only commit it'll be pretty easy to see with `git show...

Looks like this needs rebase, sadly.

Please let us know when you want some rounds of review by leaving a comment!

I don't buy that we need a new counter. There's a lot of things that hang on the timer rate, but this is a great opportunity to redefine the constants...

Rather than pushing type info upstream, maybe we should have simpler (public) constructors for the `InteractiveTxConstructor` that are context-specific? ie `InteractiveTxConstructor::for_splicing` and `InteractiveTxConstructor::for_dual_funding` are kinda separate things, and could use...