MIME-Version: 1.0
In-Reply-To: <CAE-z3OUKTKh5-SHkiawr4R58Fdg9N6_1PLjW19YsF-K9OOjQow@mail.gmail.com>
References: <CAFp6fsHBbyVo21DnQKGBVJ7P=8NqOGJ-jv0-MH9WaBD6vauudA@mail.gmail.com>
	<CAE-z3OUKTKh5-SHkiawr4R58Fdg9N6_1PLjW19YsF-K9OOjQow@mail.gmail.com>
Date: Thu, 24 Sep 2015 14:37:40 -0400
Message-ID: <CAFp6fsEq0So3nUtRrn1G3Q-sEFUpK7myxfvT9-p9LNkxPGYoTw@mail.gmail.com>
From: Suhas Daftuar <sdaftuar@gmail.com>
To: Tier Nolan <tier.nolan@gmail.com>
Content-Type: multipart/alternative; boundary=001a11407438a5da39052082860d
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [BIP Proposal] New "sendheaders" p2p message
Precedence: list

--001a11407438a5da39052082860d
Content-Type: text/plain; charset=UTF-8

On Thu, Sep 24, 2015 at 2:17 PM, Tier Nolan via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> Is there actually a requirement for the new message?  New nodes could just
> unilaterally switch to sending headers and current nodes would be
> compatible.
>

I don't believe that unilaterally switching to headers announcements would
work for all network participants -- both for users running older Bitcoin
Core versions (anything before 0.10, which I believe all ignore headers
messages) and for non-Bitcoin Core software that participates on the
network (which may ignore headers messages too, I'm not sure what all is
out there).

Even for Bitcoin Core versions 0.10 and 0.11, which process headers and use
them to determine what blocks to download, the block fetching logic is not
optimized for new block announcements via headers messages.  Part of what
is implemented in the pull request is direct fetching of blocks upon
receiving a headers message; nodes that don't implement block downloading
in response to headers announcements should continue to receive inv's, I
think -- hence this p2p message to opt-in to the new behavior.

--001a11407438a5da39052082860d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Sep 24, 2015 at 2:17 PM, Tier Nolan via bitcoin-dev <span dir=3D"ltr">&=
lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blan=
k">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div clas=
s=3D"gmail_quote"><span><div><br></div></span><div>Is there actually a requ=
irement for the new message?=C2=A0 New nodes could just unilaterally switch=
 to sending headers and current nodes would be compatible.<br></div></div><=
/div></div></blockquote><div><br></div><div>I don&#39;t believe that unilat=
erally switching to headers announcements would work for all network partic=
ipants -- both for users running older Bitcoin Core versions (anything befo=
re 0.10, which I believe all ignore headers messages) and for non-Bitcoin C=
ore software that participates on the network (which may ignore headers mes=
sages too, I&#39;m not sure what all is out there).</div><div><br></div><di=
v>Even for Bitcoin Core versions 0.10 and 0.11, which process headers and u=
se them to determine what blocks to download, the block fetching logic is n=
ot optimized for new block announcements via headers messages.=C2=A0 Part o=
f what is implemented in the pull request is direct fetching of blocks upon=
 receiving a headers message; nodes that don&#39;t implement block download=
ing in response to headers announcements should continue to receive inv&#39=
;s, I think -- hence this p2p message to opt-in to the new behavior.</div><=
/div></div></div>

--001a11407438a5da39052082860d--