From: Riccardo Casatta <riccardo.casatta@gmail•com>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: [bitcoin-dev] "Compressed" headers stream
Date: Mon, 28 Aug 2017 17:50:23 +0200 [thread overview]
Message-ID: <CADabwBBrrPM2f9h_sgxY12tg=FUvKKCcnCC8ixnct93YL9uEFQ@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1586 bytes --]
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
<https://headers.electrum.org/blockchain_headers> ~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 <https://twitter.com/RCasatta>
[-- Attachment #2: Type: text/html, Size: 1935 bytes --]
next reply other threads:[~2017-08-28 15:50 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-28 15:50 Riccardo Casatta [this message]
2017-08-28 16:13 ` Greg Sanders
2017-08-28 16:25 ` Riccardo Casatta
2017-08-28 16:26 ` Greg Sanders
2017-09-04 14:10 ` Peter Todd
[not found] ` <CAAS2fgS3uG=4vgFuObPKA_5MstoGm4AabO=60fhV3EU_0dvejg@mail.gmail.com>
2017-08-28 17:12 ` [bitcoin-dev] Fwd: " Gregory Maxwell
2017-08-28 17:54 ` Kalle Rosenbaum
2017-09-04 14:06 ` Peter Todd
2017-12-11 20:40 [bitcoin-dev] " Jim Posen
2017-12-11 21:04 ` Gregory Maxwell
2017-12-11 21:56 ` Jim Posen
2017-12-11 22:41 ` Tier Nolan
2017-12-11 23:11 ` Gregory Maxwell
2017-12-12 21:07 ` Suhas Daftuar
2017-12-13 0:01 ` Gregory Maxwell
2017-12-13 0:12 ` Gregory Maxwell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CADabwBBrrPM2f9h_sgxY12tg=FUvKKCcnCC8ixnct93YL9uEFQ@mail.gmail.com' \
--to=riccardo.casatta@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox