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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jgarzik@exmulti.com>) id 1SINZC-0005dI-SX
for bitcoin-development@lists.sourceforge.net;
Thu, 12 Apr 2012 17:12:18 +0000
X-ACL-Warn:
Received: from mail-vb0-f47.google.com ([209.85.212.47])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1SINZ8-0004Ez-VM
for bitcoin-development@lists.sourceforge.net;
Thu, 12 Apr 2012 17:12:18 +0000
Received: by vbbfr13 with SMTP id fr13so2353461vbb.34
for <bitcoin-development@lists.sourceforge.net>;
Thu, 12 Apr 2012 10:12:09 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=google.com; s=20120113;
h=mime-version:x-originating-ip:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type
:content-transfer-encoding:x-gm-message-state;
bh=kkCdOrZ5PgawVaXcbKjsnNAJJCSViaGNgk2q/1caBNA=;
b=TuM/HWuppeB6IYIPqih8bWSJspvT9lQ8Lg3sMc9HPtiAuvPrIQc+zyPfmdDcBECEfx
ttU4kuWjRaik04mDtMkJR66acPaisVNJ9dUkMe+Rrn58l4Mo9qV2Iu0zgRUWi2+94lct
s3hEihpAt2EA27H3z5IkmZ7aNGov/kacRIMre5LgK39xYW1K2eta+slU3G2377hkhoVG
FR58MNqkvkhT2OtgCfJcYMk/uJnZbHLvleJbrQUgWDy2dosL9XRSYUyI5dDqcpX8rNxR
W990KPNMj/zz2uNREQdBta89Qa9W835Vup3iH/FX5N0AfWSCBZgguCQqMdnXb80RlX7v
Pk1g==
MIME-Version: 1.0
Received: by 10.220.232.68 with SMTP id jt4mr1710938vcb.11.1334250729259; Thu,
12 Apr 2012 10:12:09 -0700 (PDT)
Received: by 10.52.109.33 with HTTP; Thu, 12 Apr 2012 10:12:09 -0700 (PDT)
X-Originating-IP: [99.43.178.25]
In-Reply-To: <CA+XhJbpNYUyPm2Ymcpg3grbfGnfERCsUJNJuByEJbJLsMMmMbQ@mail.gmail.com>
References: <CA+XhJbpNYUyPm2Ymcpg3grbfGnfERCsUJNJuByEJbJLsMMmMbQ@mail.gmail.com>
Date: Thu, 12 Apr 2012 13:12:09 -0400
Message-ID: <CA+8xBpco-yPYB+cjoi_+srG2BkC2ZQBh-3HGNA5EaSB3FWNgog@mail.gmail.com>
From: Jeff Garzik <jgarzik@exmulti.com>
To: sirk390@gmail.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQkroyqEGXFvrfymY5m9MeX23zXgbClm/qqne0LBCKDjEkQ1PTM1HCVT7jonYhGdYRo6dE/i
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1SINZ8-0004Ez-VM
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Adding request/reply id in messages
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 12 Apr 2012 17:12:18 -0000
On Wed, Apr 11, 2012 at 2:39 PM, Christian Bodt <sirk390@gmail.com> wrote:
> Hi,
>
> I would like to discuss the following bitcoin protocol improvement propos=
al:
>
> =A0 =A0 =A0 =A0 =A0Adding request/reply id in all messages (in the messag=
e header,
> based on what was done for the "checksum" field)
>
> The original reason is that I found it very hard to implement robust
> blockchain downloading as we are missing context information:
> The download protocol relies on the other peer sending one (or more) "inv=
"
> reponse(s) to "getblocks" and sending the "hashContinue".
> But if the other peer doesn't send a response to getblock, send a partial
> response to getblocks, mixes it with some unrelated blocks inventories
> or=A0doesn't send the "hashContinue"=A0it is very hard to detect and hand=
le
> (e.g. ban the peer and switch to another). =A0This could cause some DoS
> attacks by misbehaving peers.
If the peer is misbehaving, then disconnect. Your protocol change
does not offer any clear benefits in this area, as these sorts of
attacks/misbehaviors/bugs are still just as possible, and just as
damaging (or not).
Just disconnect the strange peer!
> The problems are that 1/ we don't know how many "inv" messages to wait fo=
r
> after "getblocks"=A0and 2/ we don't know how to=A0distinguish between res=
ult of
> "getblocks" and spontaneous "inv" notifications.
> The same is true for =A0"addr" messages (it is both a notification and re=
ply)
> but this is less of a problem as a lack of response to getaddr
> doesn't=A0constitute=A0a DoS.
>
> The idea would be to add a new "requestid" field in messages and define t=
he
> following:
Stateless protocols have a lot of value. They are easiest to
implement, and easier to prove correct. Existing clients like
ArtForz' half-a-node, variants of which are deployed all over the
place in bitcoin-land, rely on the stateless-ness to one degree or
another.
Stateful protocols, too, have their problems as well. One must add
code to help remain "synchronized" between local and remote states,
which your suggested change only hints at. NFSv4 and RPC have a long
history of dealing with stateful-ness issues. Obviously bitcoin P2P
is nowhere near as complex, but the history of NFS development offers
several lessons applicable to your proposed change.
Overall, IMO your listed reasons for needing this major change
(stateless->stateful) do not really justify the change. Handling
initial block download can be accomplished in a number of ways, and
peer(s) may crash or return odd results. You must handle these cases
properly, regardless of the presence of req/reply id's.
--=20
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti.com
|
