Matt Morehouse

> Mostly looking for an approach ACK on: > > * the choice of a moving median compared to a moving average ACK. I don't think the configurable percentile idea...

> > Perhaps we should set a minimum number of data points we want (e.g., 3?). If we can't get that many data points from outbound connections, we consider some...

> I don't think it's the same - it's more design hence more complicated. Plus when 8 peers all increase their `feefilter` in a short time, polling won't work as...

> This seems fine if we always have 8 data points and skip when we don't. We don't want to choose a really high max if we had one peer...

My thoughts: - Some sort of history to fall back on seems helpful, in case the data is temporarily sparse when doing on-demand querying. - Background polling seems the best...

On initial look, I'm not excited about this change. I find the event-driven pattern less readable, with code blocks like [this](https://github.com/lightningnetwork/lnd/pull/8405): ```go switch event.(type) { case *IncomingStfu: stfu := lnwire.Stfu{...

Concept ACK. I think this could remove a lot of boilerplate from the codebase.

Naively, the API looks okay to me. I agree with @Crypt-iQ though, we need to see how this is actually used at call sites to inform our API design.

IIUC, this PR does a few things: - moves fee estimator to an interface, allowing future alternative estimators - moves `InputSet` to an interface (I'm not sure why) - extracts...

For the RBF info, why load it from the DB when we can extract it directly from the spend tx in the mempool? I imagine this would be more resilient...