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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <zgenjix@yahoo.com>) id 1SINna-0004sV-QG
for bitcoin-development@lists.sourceforge.net;
Thu, 12 Apr 2012 17:27:10 +0000
X-ACL-Warn:
Received: from nm39-vm7.bullet.mail.ne1.yahoo.com ([98.138.229.167])
by sog-mx-2.v43.ch3.sourceforge.com with smtp (Exim 4.76)
id 1SINnW-0004eo-Hz for bitcoin-development@lists.sourceforge.net;
Thu, 12 Apr 2012 17:27:10 +0000
Received: from [98.138.90.50] by nm39.bullet.mail.ne1.yahoo.com with NNFMP;
12 Apr 2012 17:24:19 -0000
Received: from [98.138.88.235] by tm3.bullet.mail.ne1.yahoo.com with NNFMP;
12 Apr 2012 17:24:18 -0000
Received: from [127.0.0.1] by omp1035.mail.ne1.yahoo.com with NNFMP;
12 Apr 2012 17:24:18 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 953297.8515.bm@omp1035.mail.ne1.yahoo.com
Received: (qmail 64731 invoked by uid 60001); 12 Apr 2012 17:24:18 -0000
X-YMail-OSG: i3S72FMVM1lz.C.eCkvYqjxIDFz09nPvQ7B5C6hmHbXKqch
bOWQRjNB7cf294PEMCc3g9kNPt_xEE2_9ynxrMbZ16hEazTDBB8H4eoWd4qk
CjxBwazdvGVt1.kokZdUNoHN8mN4v2WOD_uqVl38RPWNUQYoKcylbUKv4eya
7SLNeTZSmtBzUb5jObYfAxV8pgEOz94FsdK2fi0q5a4cIITT4AEGRBCfD_Bd
EuY7utVnN6Ek213EM.jZUwOBuBVM2XFv8kfpvuEgOn1smwQ0f7Qkqo2Tff75
x308OONhGj2slKpsDpVmWYlEj.94J8kQXNkcjb40ON4kVAOfLKmZHeUgWtEC
EMlWne8wxxtt2Qt9XYznsUK0ZRDjsR8UjrEKyQf_XJr8B4RxFsQ6x219779k
x3G8cuC33BtIrLGGuVvgZUM8W8N8DU8UShGOmNZs5IpwTxRVPm6qBV45Rm_k
5lkXIt1nfJZ.I7rf0Ld1g82E6_QoPqpA-
Received: from [92.20.151.121] by web121005.mail.ne1.yahoo.com via HTTP;
Thu, 12 Apr 2012 10:24:18 PDT
X-Mailer: YahooMailWebService/0.8.117.340979
References: <CA+XhJbpNYUyPm2Ymcpg3grbfGnfERCsUJNJuByEJbJLsMMmMbQ@mail.gmail.com>
<CA+8xBpco-yPYB+cjoi_+srG2BkC2ZQBh-3HGNA5EaSB3FWNgog@mail.gmail.com>
Message-ID: <1334251458.43194.YahooMailNeo@web121005.mail.ne1.yahoo.com>
Date: Thu, 12 Apr 2012 10:24:18 -0700 (PDT)
From: Amir Taaki <zgenjix@yahoo.com>
To: "bitcoin-development@lists.sourceforge.net"
<bitcoin-development@lists.sourceforge.net>
In-Reply-To: <CA+8xBpco-yPYB+cjoi_+srG2BkC2ZQBh-3HGNA5EaSB3FWNgog@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.4 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [98.138.229.167 listed in list.dnswl.org]
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(zgenjix[at]yahoo.com)
-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
0.5 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1SINnW-0004eo-Hz
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
Reply-To: Amir Taaki <zgenjix@yahoo.com>
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:27:10 -0000
Jeff elaborated the problems very well, but I just want to add this:=0A=0AY=
our change is essentially relying (trusting) the server to track a piece of=
information (your state). Anytime you start depending on another node in s=
ome way, it is opening yourself up to be exploited. Nodes should be doing t=
heir owning state maintainance, not relying on external parties.=0A=0A=0AI =
am very much against the change. As someone who has implemented the complet=
e bitcoin protocol, I had no problems implementing the blockchain download.=
In fact, I dislike that nodes have to store the last inventory they sent a=
s part of a getblocks in order to trigger the next round. It's be better if=
there was no state whatsoever.=0A=0A________________________________=0AFro=
m: Jeff Garzik <jgarzik@exmulti.com>=0ATo: sirk390@gmail.com =0ACc: bitcoin=
-development@lists.sourceforge.net =0ASent: Thursday, April 12, 2012 6:12 P=
M=0ASubject: Re: [Bitcoin-development] Adding request/reply id in messages=
=0A=0AOn Wed, Apr 11, 2012 at 2:39 PM, Christian Bodt <sirk390@gmail.com> w=
rote:=0A> Hi,=0A>=0A> I would like to discuss the following bitcoin protoco=
l improvement proposal:=0A>=0A> =A0 =A0 =A0 =A0 =A0Adding request/reply id =
in all messages (in the message header,=0A> based on what was done for the =
"checksum" field)=0A>=0A> The original reason is that I found it very hard =
to implement robust=0A> blockchain downloading as we are missing context in=
formation:=0A> The download protocol relies on the other peer sending one (=
or more) "inv"=0A> reponse(s) to "getblocks" and sending the "hashContinue"=
.=0A> But if the other peer doesn't send a response to getblock, send a par=
tial=0A> response to getblocks, mixes it with some unrelated blocks invento=
ries=0A> or=A0doesn't send the "hashContinue"=A0it is very hard to detect a=
nd handle=0A> (e.g. ban the peer and switch to another). =A0This could caus=
e some DoS=0A> attacks by misbehaving peers.=0A=0AIf the peer is misbehavin=
g, then disconnect.=A0 Your protocol change=0Adoes not offer any clear bene=
fits in this area, as these sorts of=0Aattacks/misbehaviors/bugs are still =
just as possible, and just as=0Adamaging (or not).=0A=0AJust disconnect the=
strange peer!=0A=0A> The problems are that 1/ we don't know how many "inv"=
messages to wait for=0A> after "getblocks"=A0and 2/ we don't know how to=
=A0distinguish between result of=0A> "getblocks" and spontaneous "inv" noti=
fications.=0A> The same is true for =A0"addr" messages (it is both a notifi=
cation and reply)=0A> but this is less of a problem as a lack of response t=
o getaddr=0A> doesn't=A0constitute=A0a DoS.=0A>=0A> The idea would be to ad=
d a new "requestid" field in messages and define the=0A> following:=0A=0A=
=0AStateless protocols have a lot of value.=A0 They are easiest to=0Aimplem=
ent, and easier to prove correct.=A0 Existing clients like=0AArtForz' half-=
a-node, variants of which are deployed all over the=0Aplace in bitcoin-land=
, rely on the stateless-ness to one degree or=0Aanother.=0A=0AStateful prot=
ocols, too, have their problems as well.=A0 One must add=0Acode to help rem=
ain "synchronized" between local and remote states,=0Awhich your suggested =
change only hints at.=A0 NFSv4 and RPC have a long=0Ahistory of dealing wit=
h stateful-ness issues.=A0 Obviously bitcoin P2P=0Ais nowhere near as compl=
ex, but the history of NFS development offers=0Aseveral lessons applicable =
to your proposed change.=0A=0AOverall, IMO your listed reasons for needing =
this major change=0A(stateless->stateful) do not really justify the change.=
=A0 Handling=0Ainitial block download can be accomplished in a number of wa=
ys, and=0Apeer(s) may crash or return odd results.=A0 You must handle these=
cases=0Aproperly, regardless of the presence of req/reply id's.=0A=0A-- =
=0AJeff Garzik=0AexMULTI, Inc.=0Ajgarzik@exmulti.com=0A=0A-----------------=
-------------------------------------------------------------=0AFor Develop=
ers, A Lot Can Happen In A Second.=0ABoundary is the first to Know...and Te=
ll You.=0AMonitor Your Applications in Ultra-Fine Resolution. Try it FREE!=
=0Ahttp://p.sf.net/sfu/Boundary-d2dvs2=0A__________________________________=
_____________=0ABitcoin-development mailing list=0ABitcoin-development@list=
s.sourceforge.net=0Ahttps://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment
|
