Forum post to discuss lowering both the sampling and pruning window from 30 days to 14 days. The full CIP can be found here
The current light node syncing logic involves performing sequential verification from genesis. Outside from the time and storage costs from syncing from genesis, it’s also vulnerable to long range attacks as headers beyond the trusting period are based on validators with “nothing at stake”. While the header pruning CIP, addresses these concerns, the safety issue is only addressed so long as the sampling window is equal to the trusting period (currently defaults as 14 days). Having a sampling window or header pruning window greater than the trusting period will compromise the security of a long range attack unless the node uses something like backwards sync.
I don’t follow this. What do you mean by “compromise the security of a long range attack”?
I’m just referring to how the current syncing process from genesis is vulnerable to a long range attack and that until we support backwards sync the better approach is to have the samplingPeriod within the trustPeriod, so a node can initialise within the trustPeriod and using forward verification be able to sample everything in the window
Not sure I follow as it’s the head that needs to be trusted, not the tail, as if you sync from tail to head, and get a different head, you discard that chain. But not sure this is really important to this CIP anyway.