Elias Rohrer

> If we want to support this, IMO its pretty weird to require the cache be persisted by a downstream project, rather if we need it (we should check whether...

> I'm a bit confused, though, the cache should really only be relevant when we're reorging, which shouldn't be common? Why is it a material performance difference? Well, a persisted...

> Okay, but in this case we should probably persist a fixed-size cache of, let's say, 6 blocks (the depth that we assume no reorgs will happen), no? Well, maybe,...

Excuse the delay here. > In the "performance improvement" case, we shouldn't be relying on downstream-of-LDK applications to fix `lightning-block-sync`'s performance issues. We have a header cache in `synchronize_listeners` and...

> Mmm, this is news to me. But even if we aren't discarding previous entries, I'm still really unclear why we can't cache more? We're doing the same thing over...

> I believe now it should just be a matter of keeping locators instead of best-blocks now? Probably just updating the existing `BestBlock` struct we use to store more than...

> Just to make sure we have several recent blocks even if we're syncing with electrum (so we can switch to bitcoind without issue but also so we can handle...

> I think @TheBlueMatt meant recent block _hashes_ as per [#3600 (review)](https://github.com/lightningdevkit/rust-lightning/pull/3600#pullrequestreview-2940726083). Ah, so the idea would be to refactor `BestBlock` to be more like a `BestChainSuffix`, i.e., hold the...

Closing in favor of doing fn-level `rustfmt::skip` first.

> Actually the `estimatefee` is deprecated in ElectrumX: https://electrumx.readthedocs.io/en/latest/protocol-methods.html#blockchain.estimatefee (same with `relayfee`, also `get_fee_histogram`). > > So I don't think we should rely in `bdk_electrum` for anything fee related. I...