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
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
|
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 8B78B49B
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 12 Dec 2017 21:07:14 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ua0-f179.google.com (mail-ua0-f179.google.com
[209.85.217.179])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CB9D6E7
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 12 Dec 2017 21:07:13 +0000 (UTC)
Received: by mail-ua0-f179.google.com with SMTP id h2so154922uae.12
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 12 Dec 2017 13:07:13 -0800 (PST)
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=//1Re6R81X5QQCMnOO9DcsIhwZRwiRgbv85eSybAFdI=;
b=ihX5q6WebLnF199wtxxIzcn+MmSnsstdBhag/an2ut5O0gwIByYA312sOKjMdCAyY8
6ZXGpa79IdMrIdjEi2JBIEtYpE4+eMvr+sqSx+dq39kd/V/OB+QyF/LL1iaQDs17neVL
hGJx6kgiY9brCyymbcVM9L/YTm5+BamvXJNRvnSRO9Pz6lNUFQpnMC4sNR+fTjUcE0hI
3XDsXaUM3aF6kTqCqizFM77gnklZAUgesefN7d6AqF29qDv8F7yl1jAUr6Iyk5wnPeQ0
LcPlNNzscMxkVfS8itxAlgnNSIsihCWglZuHs5PcmJ2Y/vaermX211nf951Eb+HHxrjQ
4bsg==
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=//1Re6R81X5QQCMnOO9DcsIhwZRwiRgbv85eSybAFdI=;
b=YXIzbkhq193DfDFT336cu2s2O29+006+XNxV8lfkvp+0Ih0SrCrw9yGTDx/IP9kuxO
8nk4XZ+ryPDWWAzvY4F7BIsfXS0CHsJBOrcbUWMrr8yA2LZ8zuA9m5XLLYe7MsL3pyxn
zTjqXqdg7GhIpLnLwTgnmrNfBre+N9/WPpHwyMb6gWmya7Ot2X8IWn7TUFmvQMmwH8kQ
aOsLYq7pUvfSAQ8CxOs5akwuFIpT79xDzONlpMPd64Ozy0GuynOVwEcFnwx1mzj1uPvS
xrs+VcFETm22Qb1nTMXgNYq53DuN2tDG2uL5Ey842ibQRRNgBwjckIBwe84RyHLMfLSt
jEog==
X-Gm-Message-State: AKGB3mK61knrE7j+5JU82vrmuBB8thcnY4C8i55hLHfuvOeY0kayh/6K
4aNT/9pCFDdS4AO2rYaLH+meFysSnRWxgvlWrDo=
X-Google-Smtp-Source: ACJfBovfK5dhAaAX+RbMMKlk5ZRtI79H338AgE+5z1Y/6AH0ycd140Iiwkw+swU+oHYpXqNMtXSM/Zb659TYP1v9UtU=
X-Received: by 10.176.80.107 with SMTP id z40mr5777789uaz.82.1513112832345;
Tue, 12 Dec 2017 13:07:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.103.73.80 with HTTP; Tue, 12 Dec 2017 13:07:11 -0800 (PST)
In-Reply-To: <CAAS2fgROykenGH43_FXun+q4u+=94tKqnRW=kQQ2AQFeXKdW=Q@mail.gmail.com>
References: <CADZtCShywq_s9ZK3oBBTUdCgjrTxbyeb-p7QrhJJ3mwRAECCMA@mail.gmail.com>
<CAAS2fgROykenGH43_FXun+q4u+=94tKqnRW=kQQ2AQFeXKdW=Q@mail.gmail.com>
From: Suhas Daftuar <sdaftuar@gmail.com>
Date: Tue, 12 Dec 2017 16:07:11 -0500
Message-ID: <CAFp6fsHwdAbcYVdPzuDdD1OV7ibCN-ebMBi113m5-JOoJtccPQ@mail.gmail.com>
To: Gregory Maxwell <greg@xiph.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="94eb2c1916c6e08d0705602b085a"
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
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 <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: Tue, 12 Dec 2017 21:07:14 -0000
--94eb2c1916c6e08d0705602b085a
Content-Type: text/plain; charset="UTF-8"
Hi,
First, thanks for resurrecting this, I agree this is worth pursuing.
On Mon, Dec 11, 2017 at 4:04 PM, Gregory Maxwell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Nbits _never_ needs to be sent even with other consensus rules because
> its more or less necessarily a strict function of the prior headers.
> This still holds in every clone of Bitcoin I'm aware of; sending it
> with the first header in a group probably makes sense so it can be
> checked independently.
>
I think it would be nice, though, to not require the consensus-correct
calculation of nBits in order to process p2p messages. For instance, I
think there's a use for nBits at the p2p layer for calculating the work on
a chain, which can be used as an anti-DoS measure, even without verifying
that the difficulty adjustments are following the consensus rules.
Moreover I think it's a bit messy if the p2p layer depends on intricate
consensus rules in order to reconstruct a message -- either we'd need to
interact with existing consensus logic in a potentially new way, or we'd
reimplement the same logic in the p2p layer, neither of which is very
desirable imo.
But I think we should be able to get nearly all the benefit just by
including nBits in any messages where the value is ambiguous; ie we include
it with the first header in a message, and whenever it changes from the
previous header's nBits.
I would rather not change the serialization of existing messages,
> nodes are going to have to support speaking both messages for a long
> time, and I think we already want a different protocol flow for
> headers fetching in any case.
>
I agree with this. Specifically the way I envisioned this working is that
we could introduce a new 'cmpctheaders'/'getcmpcthdrs' message pair for
syncing using this new message type, while leaving the existing
'headers'/'getheaders' messages unchanged. So when communicating with
upgraded peers, we'd never use 'getheaders' messages, and we'd only use
'headers' messages for potentially announcing new blocks.
Of course, we'll have to support the existing protocol for a long time.
But one downside I've discovered from deploying BIP 130, which introduced
block announcements via headers messages, is that overloading a 'headers'
message to be either a block announcement or a response to a 'getheaders'
message results in p2p-handling logic which is more complicated than it
needs to be. So splitting off the headers chain-sync functionality to a
new message pair seems like a nice side-effect benefit, in the long run.
--94eb2c1916c6e08d0705602b085a
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">Hi,<=
/div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">First,=
thanks for resurrecting this, I agree this is worth pursuing.<br></div><di=
v class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">On Mon, Dec 11=
, 2017 at 4:04 PM, Gregory Maxwell via bitcoin-dev <span dir=3D"ltr"><<a=
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bi=
tcoin-dev@lists.linuxfounda<wbr>tion.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"><br>
Nbits _never_ needs to be sent even with other consensus rules because<br>
its more or less necessarily a strict function of the prior headers.<br>
This still holds in every clone of Bitcoin I'm aware of; sending it<br>
with the first header in a group probably makes sense so it can be<br>
checked independently.<br></blockquote><div><br></div><div>I think it would=
be nice, though, to not require the consensus-correct calculation of nBits=
in order to process p2p messages.=C2=A0 For instance, I think there's =
a use for nBits at the p2p layer for calculating the work on a chain, which=
can be used as an anti-DoS measure, even without verifying that the diffic=
ulty adjustments are following the consensus rules.</div><div><br></div><di=
v>Moreover I think it's a bit messy if the p2p layer depends on intrica=
te consensus rules in order to reconstruct a message -- either we'd nee=
d to interact with existing consensus logic in a potentially new way, or we=
'd reimplement the same logic in the p2p layer, neither of which is ver=
y desirable imo.</div><div><br></div><div>But I think we should be able to =
get nearly all the benefit just by including nBits in any messages where th=
e value is ambiguous; ie we include it with the first header in a message, =
and whenever it changes from the previous header's nBits.</div><div><br=
></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex">I would rather not change the seriali=
zation of existing messages,<br>
nodes are going to have to support speaking both messages for a long<br>
time, and I think we already want a different protocol flow for<br>
headers fetching in any case.<br>
</blockquote><div><br></div><div>I agree with this.=C2=A0 Specifically the =
way I envisioned this working is that we could introduce a new 'cmpcthe=
aders'/'getcmpcthdrs' message pair for syncing using this new m=
essage type, while leaving the existing 'headers'/'getheaders&#=
39; messages unchanged.=C2=A0 So when communicating with upgraded peers, we=
'd never use 'getheaders' messages, and we'd only use '=
headers' messages for potentially announcing new blocks.</div><div><br>=
</div><div>Of course, we'll have to support the existing protocol for a=
long time.=C2=A0 But one downside I've discovered from deploying BIP 1=
30, which introduced block announcements via headers messages, is that over=
loading a 'headers' message to be either a block announcement or a =
response to a 'getheaders' message results in p2p-handling logic wh=
ich is more complicated than it needs to be.=C2=A0 So splitting off the hea=
ders chain-sync functionality to a new message pair seems like a nice side-=
effect benefit, in the long run.</div><div><br></div></div></div></div>
--94eb2c1916c6e08d0705602b085a--
|
