Eugene
Eugene
> Every time we create transactions, when estimating fees, we already call EstimateFeePerKW to get the latest min relay fee. If we instantaneously query for feefilters rather than poll, we...
> If we have 8 outbound peers all the time, then either approach behaves the same. But we should think about corner cases too. What do we do if there's...
> Instead of a moving average, how about a max-of-medians in the lookback window? That would mean that the latest data point is used in a rising fee environment, while...
> This is a simplified model as it only accounts for 1 case and a depth of 2 (I created [this](https://gist.github.com/yyforyongyu/1cc7ad2ec9f4ecb5c1ede57ba9ab4912) to help with the calculation) and can go deep...
It seems like the last point of contention here is on-demand querying vs background polling. My reservations with on-demand querying are that: - we may not have enough data points...
I've addressed the main contention of the moving median by removing that logic and just tracking a median without any history. I'll address the other comments later. There are two...
Latest change is that the median feefilter is now capped when used in `RelayFeePerKW` by the 1-conf block target feerate. This prevents an adversary with the majority of outbound connections...
> list the set of active aliases, remove an active alias, and also add a new alias. The spec says that if we have ever sent over an alias in...
I think we should try to adhere to RBF as closely as possible so we can ensure that we can get our sweep transactions in the mempool. There are some...