1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
|
Return-Path: <sdaftuar@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 5ED1D1694
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 24 Sep 2015 18:37:41 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f54.google.com (mail-oi0-f54.google.com
[209.85.218.54])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F1D182F5
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 24 Sep 2015 18:37:40 +0000 (UTC)
Received: by oiww128 with SMTP id w128so46279419oiw.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 24 Sep 2015 11:37:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=huumAI2LWsHECxmsYL8Wx+aNO9DbNwtNGig8ajx7d8A=;
b=gXQuvnXSGMSQjHmWqsNLM5YnlbIUvr82v0eNOkIOIzVx2UF7BLPbAGx56ahc98xjOh
JEi8zV8F1FRr8vSwat+p1jFWUXQVmtxTiQZPFl8pBeaA2r1we5dkO3AFbf0+iERt82Gh
d/Gj5/6m94M3FGyYgduG8YmmYg7OS0J/hUNNfKguavImU4dQs8jofTn7sCC452e3H97h
gXKuiec55smksG1Cna/cp2uKhd8mma5XwlmyqmzHvgSeFOViunPXm0MVI6qNfiNuGKGS
fyknR6VWQx8od6YBxp2VPq8ilZxTJyCtwyX1HXr+lBJCLzLfqTQNP91pITPadmMO2Mue
B99Q==
MIME-Version: 1.0
X-Received: by 10.202.107.212 with SMTP id g203mr701276oic.36.1443119860399;
Thu, 24 Sep 2015 11:37:40 -0700 (PDT)
Received: by 10.202.197.83 with HTTP; Thu, 24 Sep 2015 11:37:40 -0700 (PDT)
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
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [BIP Proposal] New "sendheaders" p2p message
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Thu, 24 Sep 2015 18:37:41 -0000
--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>></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'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'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't implement block download=
ing in response to headers announcements should continue to receive inv'=
;s, I think -- hence this p2p message to opt-in to the new behavior.</div><=
/div></div></div>
--001a11407438a5da39052082860d--
|
