public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Greg Sanders <gsanders87@gmail.com>
To: Riccardo Casatta <riccardo.casatta@gmail.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] "Compressed" headers stream
Date: Mon, 28 Aug 2017 12:26:48 -0400	[thread overview]
Message-ID: <CAB3F3DtX2+awy71YPhMRjFRr4tvcGyq3Pu4997Sw2Jn_yAX+=g@mail.gmail.com> (raw)
In-Reply-To: <CADabwBDQ=aJuW7fGcU2h-yYKxfj5A0Vx6DNHEM=_ppMrdA_mcw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2913 bytes --]

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 <gsanders87@gmail.com>:
>
>> 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 <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>
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>>
>>
>
>
> --
> Riccardo Casatta - @RCasatta <https://twitter.com/RCasatta>
>

[-- Attachment #2: Type: text/html, Size: 5004 bytes --]

  reply	other threads:[~2017-08-28 16:27 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-28 15:50 [bitcoin-dev] "Compressed" headers stream Riccardo Casatta
2017-08-28 16:13 ` Greg Sanders
2017-08-28 16:25   ` Riccardo Casatta
2017-08-28 16:26     ` Greg Sanders [this message]
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='CAB3F3DtX2+awy71YPhMRjFRr4tvcGyq3Pu4997Sw2Jn_yAX+=g@mail.gmail.com' \
    --to=gsanders87@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=riccardo.casatta@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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