From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 026E6A85 for ; Mon, 28 Aug 2017 16:13:35 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm0-f48.google.com (mail-wm0-f48.google.com [74.125.82.48]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 06BE1F6 for ; Mon, 28 Aug 2017 16:13:32 +0000 (UTC) Received: by mail-wm0-f48.google.com with SMTP id y71so6232391wmd.0 for ; Mon, 28 Aug 2017 09:13:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=ezrit99F0ScZrwNtrAD0CKVRcL3JdrJH/1moi1rJ9aA=; b=i4VnhmmlUCcwOxvcOwtUB65qIYhYS+S5nsCixTdvknZuwDwXztjPkC81jczLSBaJxx sHBUYdIOICqIv+jkVPVqGvuHr+3izF764r8+upJeuZ4g+/b2J7bVDAIP0QjSkWw5AnBo p6lRifayUPSkNSnRw+O368oB/OAOn+V1Y3A5CftZmWnMPErcoJspudK/tuf6arlLUfJB +Wi0WuL7DrqTUS5W2tte6NCpzVEjbA5h2iJ3HwLver29uBMwhFdBVHFv+K1bEVXAgY9s Sgmn6MD0YjRGdm7lH5vSWS9qjpKsJ60Em/PefrdCS3Nhrb8VXSMnQQSluv4FbrLkaZok by+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=ezrit99F0ScZrwNtrAD0CKVRcL3JdrJH/1moi1rJ9aA=; b=hjETjCqxWoDix1cKZ2ebQ1uMtEQPdNqMRjkHsPzrg23Q071/zGN23tLkXlDhadDX7J 6aYZbDcy8kAmPAGMHthbFtDwTWtYU1mRCJ7rq/eTwgmKnS+lOZNfBudvCTDa9hFS27QQ VA/AKRbYyEWHpZGkZt9QZA3tQjnfqsJYKOl2z9/jCHDqv8A8NZikWUen6zxqmGlvdUV0 hlrTmg1liQyifhh9deJqTEBIfjVjzA1nPrvMnVR/VAksffxbDcvZQBeO5/o6z9zOOdbD kqUD3FDgHBlDD3Dkp6c+HgPDKrJOGv3tPORsilOmj0AVcZ4boivAYr87nEL/5Im6vB8N +oJQ== X-Gm-Message-State: AHYfb5gYyyuvOD/vGyCokf2FY/9mbwcw3Bf35CbCJjORpeKUc5+rJuA8 UlZOJ8yFuXhvYKHrSJSVqJWZb3N5cQ== X-Received: by 10.80.146.57 with SMTP id i54mr938929eda.170.1503936811635; Mon, 28 Aug 2017 09:13:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.129.163 with HTTP; Mon, 28 Aug 2017 09:13:11 -0700 (PDT) In-Reply-To: References: From: Greg Sanders Date: Mon, 28 Aug 2017 12:13:11 -0400 Message-ID: To: Riccardo Casatta , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="f403045c2a666c19d10557d293bf" X-Spam-Status: No, score=0.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=disabled version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] "Compressed" headers stream X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 16:13:35 -0000 --f403045c2a666c19d10557d293bf Content-Type: text/plain; charset="UTF-8" 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 > > --f403045c2a666c19d10557d293bf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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, Riccard= o Casatta via bitcoin-dev <bitcoin-dev@lists.linuxfoun= dation.org> wrote:
Hi everyone,

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

When sending a strea= m of continuous block headers, a common case in IBD and in disconnected cli= ents, I think there is a possible optimization of the transmitted data:
The headers after the first could avoid transmitting the previous ha= sh cause the receiver could compute it by double hashing the previous heade= r (an operation he needs to do anyway to verify PoW).
In a long s= tream, for example 2016 headers, the savings in bandwidth are about 32/80 ~= =3D 40%
without compressed headers 2016*80=3D161280 bytes
with compressed headers 80+2015*48=3D96800 bytes

What do you think?


In OpenTimesta= mps calendars we are going to use this compression to give lite-client a re= asonable secure proofs (a full node give higher security but isn't feas= ible 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=C2=A0~36MB containing the first 477637 headers.=C2=A0
Fo= r this kind of clients could be useful a common http API with fixed positio= n 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 co= uld have chunks of 20160 blocks or 201600 such that with about 10 http requ= ests 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


--f403045c2a666c19d10557d293bf--