OK cool thanks for the tip. Meanwhile I'm wondering about the model here: wouldn't it make sense to cache (as in, persist to disk) actual filters? The current codebase persists the filter headers to disk, but not the filters themselves. While it's true that for a constrained device, the filters would be a bit large, they're still like 3 orders of magnitude smaller than the full blockchain, and it seems like it'd make sense to have them stored then verified against headers or w/e, rather than a pretty slow start up (i mean clearly the idea is to have a long running daemon, but still, it seems wasteful. I know compact filters was optimizing privacy and disk space, not bandwidth, but tbh even a smartphone would probably prefer to use the disk than the bandwidth! .. perhaps).