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
Subject: Re: [Bitcoin-development] Adding request/reply id in messages
Precedence: list
Reply-To: Amir Taaki <zgenjix@yahoo.com>

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