diff options
author | Riccardo Casatta <riccardo.casatta@gmail.com> | 2018-03-30 10:06:24 +0200 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2018-03-30 08:06:46 +0000 |
commit | b15fd3d58797b46105885e42ef386c7a435de774 (patch) | |
tree | dcf6c5b7a8e7f99a865dd89bb08e2ec2369ab43f | |
parent | 0f87a9aefb92236cb63043f4776278b108d2512d (diff) | |
download | pi-bitcoindev-b15fd3d58797b46105885e42ef386c7a435de774.tar.gz pi-bitcoindev-b15fd3d58797b46105885e42ef386c7a435de774.zip |
Re: [bitcoin-dev] Optimized Header Sync
-rw-r--r-- | 33/fc7a9395b5df7bede4f70c7b243dcd3fc4e4f8 | 173 |
1 files changed, 173 insertions, 0 deletions
diff --git a/33/fc7a9395b5df7bede4f70c7b243dcd3fc4e4f8 b/33/fc7a9395b5df7bede4f70c7b243dcd3fc4e4f8 new file mode 100644 index 000000000..368a5629b --- /dev/null +++ b/33/fc7a9395b5df7bede4f70c7b243dcd3fc4e4f8 @@ -0,0 +1,173 @@ +Return-Path: <riccardo.casatta@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 3794DBC5 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 30 Mar 2018 08:06:46 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-io0-f177.google.com (mail-io0-f177.google.com + [209.85.223.177]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 86F615F4 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 30 Mar 2018 08:06:45 +0000 (UTC) +Received: by mail-io0-f177.google.com with SMTP id b20so10375982iof.5 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 30 Mar 2018 01:06:45 -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 + :cc; bh=fZfnW+2HObHwVYtPkWki6fTNBbXEBNmg0IYRPJ2Fq9U=; + b=K/5qbvPCvX6zyEwnjRxN35kf3Uw9odUjqJExKd5ob2LFbLdz+bvVRqz8gL+TvPBGn9 + DRmT4Fo3sOJUqOWH/4vfo6ixzJdWLmrc191vcxOwILdscFaYJkju3qR9rzpGDrLWIekj + 5fSLZPtH5Wke0Z+B6Kbj8U5PkuGv3bX6ywYOtEyBQVS86eTl0q84JUL+WMgYsy8YJQ4C + cSmsjFzb7T9O9uAcGBxe9672zYbjrlMngHgMceNp5EHBvxnPe5XWuMknC8omMa33zkEn + LVN2bGd6r+PJWNkg9qSmULccJhUS2aEXh5QLAyX73x+jnhXI8zDK5ntVUYDvwN9zWE4b + C7Ig== +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:cc; + bh=fZfnW+2HObHwVYtPkWki6fTNBbXEBNmg0IYRPJ2Fq9U=; + b=Ar3YzCc4+4VqxrFRh8a+HbjkzPl6Bh0cSSibxeEATMLkVUhfHgTCG0Hivemv2D2v5N + 3pVtqlocrGZOma95rJWX+TeRpAsXwQbzC1ttFRdLr3KR3xpRExE5oMlRPc/S58/pP/0P + Pgb8BgGNMk4eRsaof2nn2ltrq+joqlUowI/IXYXFEprh+jJD4b/VF3HD1dDU2UwzgwRz + BQOtSH/vxTkK/jU5FfTCAIDDZEtcluEB1gpTCNEYRZ2KH/XK4NEwp/5kbMlvaZwTnhx5 + +qhOQ7502BLVq+iQzpkInxyenmcVQJc4b0P66L7ch3xmFS3/tWyZKNJkyaQHbk9F3FNe + 7TZw== +X-Gm-Message-State: AElRT7EJPcuBqrBkpsZ/V7oWvDFqM2WS7y6b8/qaT34YSUB5BpXGBpRs + uxL2H/q9B19vQmU48ueRYHrHYuqohbR2TPk+e/8= +X-Google-Smtp-Source: AG47ELsLktS/R/aU9LZXiONyWK9lTfejQx03AiiZw8Ft/a5zu713p9gBBSO/URA8gmqNTPGN/PB8e37ldB37Wg5vTWs= +X-Received: by 10.107.11.204 with SMTP id 73mr55020905iol.25.1522397204750; + Fri, 30 Mar 2018 01:06:44 -0700 (PDT) +MIME-Version: 1.0 +Received: by 10.2.46.32 with HTTP; Fri, 30 Mar 2018 01:06:24 -0700 (PDT) +In-Reply-To: <20180330061418.GA6017@erisian.com.au> +References: <CADZtCSg7+x-sg-ysgacXobRexOVwT+k9fr6a9S-6xU2w8f8m3A@mail.gmail.com> + <CADabwBAjTRdVqsL+V=YdQ+kr8+LtSPOeSXUJOzKoPNdKEbAOWQ@mail.gmail.com> + <CADZtCSjmQfBZoaO=MCyRoEn-AYe4A=1kDhxSVxVMw+O4k7YJfQ@mail.gmail.com> + <20180330061418.GA6017@erisian.com.au> +From: Riccardo Casatta <riccardo.casatta@gmail.com> +Date: Fri, 30 Mar 2018 10:06:24 +0200 +Message-ID: <CADabwBDiT2zNPHZ2=OyvCVrSY3Km2oyTnhRCHyMNsjW2vLMmOg@mail.gmail.com> +To: Anthony Towns <aj@erisian.com.au> +Content-Type: multipart/alternative; boundary="001a113de7a498a89f05689cb8c5" +X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, + RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +X-Mailman-Approved-At: Sun, 01 Apr 2018 14:27:14 +0000 +Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Subject: Re: [bitcoin-dev] Optimized Header Sync +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.12 +Precedence: list +List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Fri, 30 Mar 2018 08:06:46 -0000 + +--001a113de7a498a89f05689cb8c5 +Content-Type: text/plain; charset="UTF-8" + +Yes, I think the checkpoints and the compressed headers streams should be +handled in chunks of 2016 headers and queried by chunk number instead of +height, falling back to current method if the chunk is not full yet. + +This is cache friendly and allows to avoid bit 0 and bit 1 in the bitfield +(because they are always 1 after the first header in the chunk of 2016). + +2018-03-30 8:14 GMT+02:00 Anthony Towns <aj@erisian.com.au>: + +> On Thu, Mar 29, 2018 at 05:50:30PM -0700, Jim Posen via bitcoin-dev wrote: +> > Taken a step further though, I'm really interested in treating the +> checkpoints +> > as commitments to chain work [...] +> +> In that case, shouldn't the checkpoints just be every 2016 blocks and +> include the corresponding bits value for that set of blocks? +> +> That way every node commits to (approximately) how much work their entire +> chain has by sending something like 10kB of data (currently), and you +> could verify the deltas in each node's chain's target by downloading the +> 2016 headers between those checkpoints (~80kB with the proposed compact +> encoding?) and checking the timestamps and proof of work match both the +> old target and the new target from adjacent checkpoints. +> +> (That probably still works fine even if there's a hardfork that allows +> difficulty to adjust more frequently: a bits value at block n*2016 will +> still enforce *some* lower limit on how much work blocks n*2016+{1..2016} +> will have to contribute; so will still allow you to estimate how much work +> will have been done, it may just be less precise than the estimate you +> could +> generate now) +> +> Cheers, +> aj +> +> + + +-- +Riccardo Casatta - @RCasatta <https://twitter.com/RCasatta> + +--001a113de7a498a89f05689cb8c5 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div>Yes, I think the checkpoints and the compressed heade= +rs streams should be handled in chunks of 2016 headers and queried by chunk= + number instead of height, falling back to current method if the chunk is n= +ot full yet.</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_= +extra">This is cache friendly and allows to avoid bit 0 and bit 1 in the bi= +tfield (because they are always 1 after the first header in the chunk of 20= +16).</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><= +div class=3D"gmail_quote">2018-03-30 8:14 GMT+02:00 Anthony Towns <span dir= +=3D"ltr"><<a href=3D"mailto:aj@erisian.com.au" target=3D"_blank">aj@eris= +ian.com.au</a>></span>:<br><blockquote class=3D"gmail_quote" style=3D"ma= +rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D= +"">On Thu, Mar 29, 2018 at 05:50:30PM -0700, Jim Posen via bitcoin-dev wrot= +e:<br> +> Taken a step further though, I'm really interested in treating the= + checkpoints<br> +</span>> as commitments to chain work [...]<br> +<br> +In that case, shouldn't the checkpoints just be every 2016 blocks and<b= +r> +include the corresponding bits value for that set of blocks?<br> +<br> +That way every node commits to (approximately) how much work their entire<b= +r> +chain has by sending something like 10kB of data (currently), and you<br> +could verify the deltas in each node's chain's target by downloadin= +g the<br> +2016 headers between those checkpoints (~80kB with the proposed compact<br> +encoding?) and checking the timestamps and proof of work match both the<br> +old target and the new target from adjacent checkpoints.<br> +<br> +(That probably still works fine even if there's a hardfork that allows<= +br> +difficulty to adjust more frequently: a bits value at block n*2016 will<br> +still enforce *some* lower limit on how much work blocks n*2016+{1..2016}<b= +r> +will have to contribute; so will still allow you to estimate how much work<= +br> +will have been done, it may just be less precise than the estimate you coul= +d<br> +generate now)<br> +<br> +Cheers,<br> +aj<br> +<br> +</blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div class= +=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr">Ri= +ccardo Casatta - <a href=3D"https://twitter.com/RCasatta" target=3D"_blank"= +>@RCasatta</a></div></div> +</div></div> + +--001a113de7a498a89f05689cb8c5-- + |