cip: Header Pruning for LNs

[Wondertan]

Overview

CIP for Header Pruning. As Header Pruning breaks users, particularly by preventing historical queries(to be fixed in subsequent CIP), it was decided to promote this change to a CIP.

This CIP start a series of DA targeted CIPs to optimize bandwidth and storage usage for LN, particularly targeting overhead brought by headers.

[jcstein]

is this R4R?

[Wondertan]

It is. This a question for reviewers. Whether its necessary link this somewhere.

Sidenote: there is still a bit of mess with those params. Some of them needs to be changed anr some needs to be defined in a cip

[jcstein]

where do the params live now?

[Wondertan]

In code 😂

[jcstein]

nits mostly

[rootulp]

LGTM after resolving the parameter question. Given the DA network parameters aren't already in CIPs (or specs) somewhere, I suggest keeping the source of truth in code and removing the parameter from this CIP.

The rationale is that it's way easier to update the parameter in code and there is no risk of the parameter in docs becoming stale with the implementation in code.

[Wondertan]

Given the DA network parameters aren't already in CIPs (or specs) somewhere, I suggest keeping the source of truth in code and removing the parameter from this CIP.

@rootulp, rhere is SamplingWindow param that is already in CIP-4. We can tie HeaderPruningWindow to it which is 30 days for simplicity. It should though be defined based of TrustingPeriod which is 14 days(basing on @nashqueue's findings), but that's gonna be a different CIP by someone else(like @cmwaters) that will define the TrustingPeriod and resolve issues in between all the params by adjusting them.

So given we have the linkable parameter in the old CIP, I believe it fine to define the new parameter in the CIP.