Well, if anything my question may bolster your use-case. If there's a heavier chain that is invalid, I kind of doubt it matters for timestamping reasons. /digression On Mon, Aug 28, 2017 at 12:25 PM, Riccardo Casatta < riccardo.casatta@gmail.com> wrote: > > 2017-08-28 18:13 GMT+02:00 Greg Sanders : > >> Is there any reason to believe that you need Bitcoin "full security" at >> all for timestamping? >> > > This is a little bit out of the main topic of the email which is the > savings in bandwidth in transmitting headers, any comment about that? > > > P.S. As a personal experience timestamping is nowadays used to prove date > and integrity of private databases containing a lot of value, so yes, in > that cases I will go with Bitcoin "full security" > > >> >> 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 >>> >>> >> > > > -- > Riccardo Casatta - @RCasatta >