Hi everyone,

the Bitcoin headers are probably the most condensed and important piece of data in the world, their demand is expected to grow.

When sending a stream of continuous block headers, a common case in IBD and in disconnected clients, I think there is a possible optimization of the transmitted data:

The headers after the first could avoid transmitting the previous hash cause the receiver could compute it by double hashing the previous header (an operation he needs to do anyway to verify PoW).

In a long stream, for example 2016 headers, the savings in bandwidth are about 32/80 ~= 40%

without compressed headers 2016*80=161280 bytes

with compressed headers 80+2015*48=96800 bytes

What do you think?

In OpenTimestamps calendars we are going to use this compression to give lite-client a reasonable secure proofs (a full node give higher security but isn't feasible in all situations, for example for in-browser verification)

To speed up sync of a new client Electrum starts with the download of a file ~36MB containing the first 477637 headers. 

For this kind of clients could be useful a common http API with fixed position chunks to leverage http caching. For example /headers/2016/0 returns the headers from the genesis to the 2015 header included while /headers/2016/1 gives the headers from the 2016th to the 4031.

Other endpoints could have chunks of 20160 blocks or 201600 such that with about 10 http requests a client could fast sync the headers

--

Riccardo Casatta - @RCasatta

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev