From: <eric@voskuil.org>
To: "'Bitcoin Protocol Discussion'" <bitcoin-dev@lists.linuxfoundation.org>
References: <CALeFGL1WSSA69ARvJW3di-UC_gz7NV9q7=6zd7s=CHnmttdQFg@mail.gmail.com>
 <CAJx8jdz3uOCpwed3MZkf1ghkvaZMfy-+vvOCVZdvhz2KAn38DQ@mail.gmail.com>
 <b895f2e4-513f-0c0d-91ac-52af055f332c@LeoWandersleb.de>
 <CAPR5oBND9DS1Ea=RMqrhnMBjFqU6wpCpv-sMeX9mxqgyLJGYiQ@mail.gmail.com>
In-Reply-To: <CAPR5oBND9DS1Ea=RMqrhnMBjFqU6wpCpv-sMeX9mxqgyLJGYiQ@mail.gmail.com>
Date: Mon, 1 Mar 2021 01:37:06 -0800
Message-ID: <00b001d70e7e$7204e2f0$560ea8d0$@voskuil.org>
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="----=_NextPart_000_00B1_01D70E3B.63E350A0"
Content-Language: en-us
Thread-Index: AQC3ML5SL96bh4vDDY9y8HYjlqZLVgImxkDAAI7sjCMBipy/mayMlTug
Subject: Re: [bitcoin-dev] A design for Probabilistic Partial Pruning
Precedence: list

This is a multipart message in MIME format.

------=_NextPart_000_00B1_01D70E3B.63E350A0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

On Sun, Feb 28, 2021 at 10:18 AM Leo Wandersleb via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org =
<mailto:bitcoin-dev@lists.linuxfoundation.org> > wrote:

=20

> Only headers need to be downloaded sequentially so downloading =
relevant blocks from one node is totally possible with gaps in between.

=20

In fact this is exactly how libbitcoin v4 works. We download and store =
blocks in parallel. In the case of a restart block gaps are repopulated. =
Given that headers are validated, we go after the most responsive nodes. =
Based on standard deviation, we drop the slowest peers and rebalance =
load to new/empty channels. We make ordered but not necessarily =
sequential requests. There is no distinction between =
=E2=80=9Cinitial=E2=80=9D block download, a restart, or a single or few =
blocks at the top. So it=E2=80=99s referred to as continuous parallel =
block download.

=20

But we don=E2=80=99t prune. Personally I consider this =
counterproductive. Apart from the complexity, it=E2=80=99s not healthy. =
And the chain grows linearly with storage cost falling exponentially, =
leading to a straightforward conclusion.

=20

e


------=_NextPart_000_00B1_01D70E3B.63E350A0
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta =
http-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8"><meta =
name=3DGenerator content=3D"Microsoft Word 15 (filtered =
medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	font-size:11.0pt;
	font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri",sans-serif;
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri",sans-serif;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue =
vlink=3Dpurple style=3D'word-wrap:break-word'><div =
class=3DWordSection1><div><div><p class=3DMsoNormal>On Sun, Feb 28, 2021 =
at 10:18 AM Leo Wandersleb via bitcoin-dev &lt;<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.l=
inuxfoundation.org</a>&gt; wrote:<o:p></o:p></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>&gt; Only =
headers need to be downloaded sequentially so downloading relevant =
blocks from one node is totally possible with gaps in =
between.<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p =
class=3DMsoNormal>In fact this is exactly how libbitcoin v4 works. We =
download and store blocks in parallel. In the case of a restart block =
gaps are repopulated. Given that headers are validated, we go after the =
most responsive nodes. Based on standard deviation, we drop the slowest =
peers and rebalance load to new/empty channels. We make ordered but not =
necessarily sequential requests. There is no distinction between =
=E2=80=9Cinitial=E2=80=9D block download, a restart, or a single or few =
blocks at the top. So it=E2=80=99s referred to as continuous parallel =
block download.<o:p></o:p></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>But we =
don=E2=80=99t prune. Personally I consider this counterproductive. Apart =
from the complexity, it=E2=80=99s not healthy. And the chain grows =
linearly with storage cost falling exponentially, leading to a =
straightforward conclusion.<o:p></o:p></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p =
class=3DMsoNormal>e<o:p></o:p></p></div></div></div></body></html>
------=_NextPart_000_00B1_01D70E3B.63E350A0--