Use hard-coded hash as trusted hash.

[adlerjohn]

Implementation ideas

Idea from @walldiss

Problem

Currently, the trusted hash is optionally provided by the user with --headers.trusted-hash. There are two problem with this:

1. It's a hassle for end users to determine this trusted hash. Who specifically should they request it from, for example.
2. Getting the trusted hash from a single (or a handful of) source that could be corrupted is relatively insecure.

Proposal

Based on the notion of checkpoints from Bitcoin Core, hard-code one checkpoint (block header hash) from which syncing starts from, rather than the genesis block hash. This checkpoint should be updated periodically in celestia-node releases.

The existing flag can remain for users that explicitly want more control.

Example checkpoints in Bitcoin Core: https://github.com/bitcoin/bitcoin/blob/9d1a286f20b8a602ffe72928bcd79be09fdbf9d0/src/kernel/chainparams.cpp#L157-L173

[liamsi]

This checkpoint should be updated periodically in celestia-node releases.

Is the idea to release a new hardcoded header every 3 weeks (unbonding period)? Otherwise, won't make this long range attacks cheaper?

[Wondertan]

I find requesting trusted peers a.k.a bootstrappers managed by us similar as us hardcoding the hash.

But, relying on bootstrappers is less error prone and more secure:

• we dont have to burden ourselves with updating the hash all the time and dont need to implement bots to do this for us
• bootstrappers send messages over encrypted connections with fixed publicly known identities already hardcoded in the code

[renaynay]

Please turn this into a discussion @adlerjohn

[walldiss]

On Long Range Attacks @liamsi :
I'm wondering why using a trusted hash at a height greater than 1 is seen as riskier than using the genesis hash. Since both methods use the same syncing initialisation process, and the genesis block is much older, shouldn't the risks be the same or less?

Reliance on Bootstrappers @Wondertan :
Using bootstrappers to provide the trusted hash introduces a dependency on our controlled infrastructure. This could be risky, especially if nodes need to rely on community-run bootstrappers during our infrastructure's downtime or other issues. It might be worth exploring how to mitigate such risks to maintain a balance between security and operational reliability.

Historical Headers Accessibility:
There's an additional concern about updating the trusted hash for the entire network potentially limiting access to historical headers. Could we consider making such updates exclusive to light nodes? They stand to benefit most from reduced storage requirements without significantly impacting overall network integrity.

Reducing Storage for Light Nodes:
The primary motivation behind my proposal is to significantly reduce the header storage requirements for light nodes—from roughly 27GB to just 4-9GB. I believe we can implement sample pruning quite quickly, which would help light nodes to drastically cut down the storage needs for from ~64GB to just ~16GB.

[liamsi]

I'm wondering why using a trusted hash at a height greater than 1 is seen as riskier than using the genesis hash. Since both methods use the same syncing initialisation process, and the genesis block is much older, shouldn't the risks be the same or less?

Long range attacks are easier the older the checkpoint header is. Syncing from genesis would be really bad if there wasn't a subjective head inside of the unbonding period to sync towards. That header (within the unbonding period) can be user supplied or as Hlib argues come from the bootstrappers instead for better UX. If we add checkpoints, ideally there would be a new release with a recent header every 3 weeks.

[liamsi]

https://blog.positive.com/rewriting-history-a-brief-introduction-to-long-range-attacks-54e473acdba9