Is there any reason to believe that you need Bitcoin "full security" at all for timestamping? On Mon, Aug 28, 2017 at 11:50 AM, Riccardo Casatta via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 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 > >