The way bip157/158 works is there is a "filter header" chain, similar to the regular header chain, where each filter is hashed with the hash of the previous filter.
Full nodes and pruned nodes calculate the filter header hashes since they start indexing from genesis. However, fastsynced nodes only start indexing from the checkpoint and so the filter header hash they calculate for the checkpoint is incorrect... causing all subsequent filter header hashes to be incorrect as well.
If a neutrino node tried syncing from one they would detect that the node is serving up bad filter headers (since they don't link to the a hardcoded filter header checkpoint in the wallet) and ban the node.
I think a possible solution is to extend our checkpoint object with the hash of the filter header at the checkpoint, so that fast synced nodes can calculate the correct filter header chain.
zquestz
commented
4 years ago
The way bip157/158 works is there is a "filter header" chain, similar to the regular header chain, where each filter is hashed with the hash of the previous filter.
Full nodes and pruned nodes calculate the filter header hashes since they start indexing from genesis. However, fastsynced nodes only start indexing from the checkpoint and so the filter header hash they calculate for the checkpoint is incorrect... causing all subsequent filter header hashes to be incorrect as well.
If a neutrino node tried syncing from one they would detect that the node is serving up bad filter headers (since they don't link to the a hardcoded filter header checkpoint in the wallet) and ban the node.
I think a possible solution is to extend our checkpoint object with the hash of the filter header at the checkpoint, so that fast synced nodes can calculate the correct filter header chain.