Anchoring an SPV light client on another chain: checkpoint trust, retargeting and reorg handling

[ZmnSCPxj]

@sebas

Our first design was stateless: the caller supplied a run of headers with each proof. We dropped it because a verifier that only checks each header against the bits in the same header can be fed a cheaply mined chain with a low difficulty.

I think in practice you can check that the bits is above the lowest bits value of, say, the year 2022, which is hardcoded in your callee, and keep this simpler stateless design. Statelessness is next to godliness. Every four years, change this bits minimum value according to measured samples of the Bitcoin blockchain.

Alternately if you really really really do not want to have this simple heuristic solution, you just need to agree on some canonical header chain from genesis, without having to validate actual blocks.

@sebas

6. Reorgs. A heavier fork re-points the canonical chain up to a bounded number of blocks. How would you pick that bound?

I think it should depend on value of the amount in question. Your bounds should probably be something like: 100 if it is at or above the minimum coinbase amount, 6 if it is near to a typical Lightning channel, then just scale between those somehow, maybe logarithmically.