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