path: root/1a/50264a737c9c7b1007eec78f5e573e45a2796f

Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <peter@coinlab.com>) id 1SIOOd-0007Yh-4V
	for bitcoin-development@lists.sourceforge.net;
	Thu, 12 Apr 2012 18:05:27 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of coinlab.com
	designates 209.85.160.175 as permitted sender)
	client-ip=209.85.160.175; envelope-from=peter@coinlab.com;
	helo=mail-gy0-f175.google.com; 
Received: from mail-gy0-f175.google.com ([209.85.160.175])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128)
	(Exim 4.76) id 1SIOOY-0006tT-S1
	for bitcoin-development@lists.sourceforge.net;
	Thu, 12 Apr 2012 18:05:27 +0000
Received: by ghbz2 with SMTP id z2so1508962ghb.34
	for <bitcoin-development@lists.sourceforge.net>;
	Thu, 12 Apr 2012 11:05:17 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:x-gm-message-state;
	bh=GO1csPNZHnsQFMSVpygjX/z1+3AH6EU6FZKhSsphot8=;
	b=nyXxgUSr/vDz/6lSQ6QiLG9BXqmsv3bvNnaIrLrEqWJ4/mPY+6BqQQL06U3Adie+mQ
	jmtB8/wkml+R7cUVph2sfLoHYdkXELKXhr/D9vMpmNihSmuADYBEjn/kvGXy8OKCP0AT
	OaQpHZfgL7Kr29QTrfzDGnfzFa5fwLRL3vuLERJCFz9sSeTXISBfiCczvOezOzyGd35P
	QM55xm9yRxwBXdvnEiEA9VVEehnYnpfWtkozBKHyKqmqZhRDsdYILzcPpb0YjfYse6t0
	nKx8TEkK49In3VlACAGxihUrhFhdIWqSw7KQk1RonGZDBzQmIy0/SD/TZ17TiCJpxll2
	ImHw==
Received: by 10.60.5.231 with SMTP id v7mr4136012oev.61.1334253917050; Thu, 12
	Apr 2012 11:05:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.56.226 with HTTP; Thu, 12 Apr 2012 11:04:54 -0700 (PDT)
In-Reply-To: <1334251458.43194.YahooMailNeo@web121005.mail.ne1.yahoo.com>
References: <CA+XhJbpNYUyPm2Ymcpg3grbfGnfERCsUJNJuByEJbJLsMMmMbQ@mail.gmail.com>
	<CA+8xBpco-yPYB+cjoi_+srG2BkC2ZQBh-3HGNA5EaSB3FWNgog@mail.gmail.com>
	<1334251458.43194.YahooMailNeo@web121005.mail.ne1.yahoo.com>
From: Peter Vessenes <peter@coinlab.com>
Date: Thu, 12 Apr 2012 11:04:54 -0700
Message-ID: <CAMGNxUvjUMYW-Bpr68d+jPQ33Y=2nOX8zPNuUwZ0uOdf9ZfJog@mail.gmail.com>
To: Amir Taaki <zgenjix@yahoo.com>
Content-Type: multipart/alternative; boundary=e89a8ff25350c4187304bd7f3250
X-Gm-Message-State: ALoCoQnaqznGrlVYyYmhryCEP5dUyZ0FaydFSj7m5cGHGucBfmoFX0ehiCjI6ASqAGMDXPqA8tQ1
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
X-Headers-End: 1SIOOY-0006tT-S1
Cc: "bitcoin-development@lists.sourceforge.net"
	<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 18:05:27 -0000

--e89a8ff25350c4187304bd7f3250
Content-Type: text/plain; charset=ISO-8859-1

I agree that it would be nice if the protocol stayed stateless.

I also think we should try and keep in our heads the aggregate
bitcoin-universe cost of implementing any protocol change; even a very
small change, something that truly only takes one hour of time from each
bitcoin node client developer to implement, test and bugfix (hah!) Has a
cost in the (tens?) of thousands of USD added up across those who need to
understand, implement, discuss, etc.

Peter

On Thu, Apr 12, 2012 at 10:24 AM, Amir Taaki <zgenjix@yahoo.com> wrote:

> Jeff elaborated the problems very well, but I just want to add this:
>
> Your change is essentially relying (trusting) the server to track a piece
> of information (your state). Anytime you start depending on another node in
> some way, it is opening yourself up to be exploited. Nodes should be doing
> their owning state maintainance, not relying on external parties.
>
>
> I am very much against the change. As someone who has implemented the
> complete bitcoin protocol, I had no problems implementing the blockchain
> download. In fact, I dislike that nodes have to store the last inventory
> they sent as part of a getblocks in order to trigger the next round. It's
> be better if there was no state whatsoever.
>
> ________________________________
> From: Jeff Garzik <jgarzik@exmulti.com>
> To: sirk390@gmail.com
> Cc: bitcoin-development@lists.sourceforge.net
> Sent: Thursday, April 12, 2012 6:12 PM
> Subject: Re: [Bitcoin-development] Adding request/reply id in messages
>
> 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
> proposal:
> >
> >          Adding request/reply id in all messages (in the message 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 doesn't send the "hashContinue" it is very hard to detect and handle
> > (e.g. ban the peer and switch to another).  This 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
> for
> > after "getblocks" and 2/ we don't know how to distinguish between result
> of
> > "getblocks" and spontaneous "inv" notifications.
> > The same is true for  "addr" messages (it is both a notification and
> reply)
> > but this is less of a problem as a lack of response to getaddr
> > doesn't constitute a DoS.
> >
> > The idea would be to add a new "requestid" field in messages and define
> the
> > 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.
>
> --
> Jeff Garzik
> exMULTI, Inc.
> jgarzik@exmulti.com
>
>
> ------------------------------------------------------------------------------
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> ------------------------------------------------------------------------------
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>



-- 

Peter J. Vessenes
CEO, CoinLab
M: 206.595.9839

--e89a8ff25350c4187304bd7f3250
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I agree that it would be nice if the protocol stayed stateless.=A0<div><br>=
</div><div>I also think we should try and keep in our heads the aggregate b=
itcoin-universe cost of implementing any protocol change; even a very small=
 change, something that truly only takes one hour of time from each bitcoin=
 node client developer to implement, test and bugfix (hah!) Has a cost in t=
he (tens?) of thousands of USD added up across those who need to understand=
, implement, discuss, etc.</div>

<div><br></div><div>Peter</div><div><br><div class=3D"gmail_quote">On Thu, =
Apr 12, 2012 at 10:24 AM, Amir Taaki <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:zgenjix@yahoo.com">zgenjix@yahoo.com</a>&gt;</span> wrote:<br><blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex">

Jeff elaborated the problems very well, but I just want to add this:<br>
<br>
Your change is essentially relying (trusting) the server to track a piece o=
f information (your state). Anytime you start depending on another node in =
some way, it is opening yourself up to be exploited. Nodes should be doing =
their owning state maintainance, not relying on external parties.<br>


<br>
<br>
I am very much against the change. As someone who has implemented the compl=
ete bitcoin protocol, I had no problems implementing the blockchain downloa=
d. In fact, I dislike that nodes have to store the last inventory they sent=
 as part of a getblocks in order to trigger the next round. It&#39;s be bet=
ter if there was no state whatsoever.<br>


<br>
________________________________<br>
From: Jeff Garzik &lt;<a href=3D"mailto:jgarzik@exmulti.com">jgarzik@exmult=
i.com</a>&gt;<br>
To: <a href=3D"mailto:sirk390@gmail.com">sirk390@gmail.com</a><br>
Cc: <a href=3D"mailto:bitcoin-development@lists.sourceforge.net">bitcoin-de=
velopment@lists.sourceforge.net</a><br>
Sent: Thursday, April 12, 2012 6:12 PM<br>
<div class=3D"im HOEnZb">Subject: Re: [Bitcoin-development] Adding request/=
reply id in messages<br>
<br>
</div><div class=3D"HOEnZb"><div class=3D"h5">On Wed, Apr 11, 2012 at 2:39 =
PM, Christian Bodt &lt;<a href=3D"mailto:sirk390@gmail.com">sirk390@gmail.c=
om</a>&gt; wrote:<br>
&gt; Hi,<br>
&gt;<br>
&gt; I would like to discuss the following bitcoin protocol improvement pro=
posal:<br>
&gt;<br>
&gt; =A0 =A0 =A0 =A0 =A0Adding request/reply id in all messages (in the mes=
sage header,<br>
&gt; based on what was done for the &quot;checksum&quot; field)<br>
&gt;<br>
&gt; The original reason is that I found it very hard to implement robust<b=
r>
&gt; blockchain downloading as we are missing context information:<br>
&gt; The download protocol relies on the other peer sending one (or more) &=
quot;inv&quot;<br>
&gt; reponse(s) to &quot;getblocks&quot; and sending the &quot;hashContinue=
&quot;.<br>
&gt; But if the other peer doesn&#39;t send a response to getblock, send a =
partial<br>
&gt; response to getblocks, mixes it with some unrelated blocks inventories=
<br>
&gt; or=A0doesn&#39;t send the &quot;hashContinue&quot;=A0it is very hard t=
o detect and handle<br>
&gt; (e.g. ban the peer and switch to another). =A0This could cause some Do=
S<br>
&gt; attacks by misbehaving peers.<br>
<br>
If the peer is misbehaving, then disconnect.=A0 Your protocol change<br>
does not offer any clear benefits in this area, as these sorts of<br>
attacks/misbehaviors/bugs are still just as possible, and just as<br>
damaging (or not).<br>
<br>
Just disconnect the strange peer!<br>
<br>
&gt; The problems are that 1/ we don&#39;t know how many &quot;inv&quot; me=
ssages to wait for<br>
&gt; after &quot;getblocks&quot;=A0and 2/ we don&#39;t know how to=A0distin=
guish between result of<br>
&gt; &quot;getblocks&quot; and spontaneous &quot;inv&quot; notifications.<b=
r>
&gt; The same is true for =A0&quot;addr&quot; messages (it is both a notifi=
cation and reply)<br>
&gt; but this is less of a problem as a lack of response to getaddr<br>
&gt; doesn&#39;t=A0constitute=A0a DoS.<br>
&gt;<br>
&gt; The idea would be to add a new &quot;requestid&quot; field in messages=
 and define the<br>
&gt; following:<br>
<br>
<br>
Stateless protocols have a lot of value.=A0 They are easiest to<br>
implement, and easier to prove correct.=A0 Existing clients like<br>
ArtForz&#39; half-a-node, variants of which are deployed all over the<br>
place in bitcoin-land, rely on the stateless-ness to one degree or<br>
another.<br>
<br>
Stateful protocols, too, have their problems as well.=A0 One must add<br>
code to help remain &quot;synchronized&quot; between local and remote state=
s,<br>
which your suggested change only hints at.=A0 NFSv4 and RPC have a long<br>
history of dealing with stateful-ness issues.=A0 Obviously bitcoin P2P<br>
is nowhere near as complex, but the history of NFS development offers<br>
several lessons applicable to your proposed change.<br>
<br>
Overall, IMO your listed reasons for needing this major change<br>
(stateless-&gt;stateful) do not really justify the change.=A0 Handling<br>
initial block download can be accomplished in a number of ways, and<br>
peer(s) may crash or return odd results.=A0 You must handle these cases<br>
properly, regardless of the presence of req/reply id&#39;s.<br>
<br>
--<br>
Jeff Garzik<br>
exMULTI, Inc.<br>
<a href=3D"mailto:jgarzik@exmulti.com">jgarzik@exmulti.com</a><br>
<br>
---------------------------------------------------------------------------=
---<br>
For Developers, A Lot Can Happen In A Second.<br>
Boundary is the first to Know...and Tell You.<br>
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!<br>
<a href=3D"http://p.sf.net/sfu/Boundary-d2dvs2" target=3D"_blank">http://p.=
sf.net/sfu/Boundary-d2dvs2</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br>
---------------------------------------------------------------------------=
---<br>
For Developers, A Lot Can Happen In A Second.<br>
Boundary is the first to Know...and Tell You.<br>
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!<br>
<a href=3D"http://p.sf.net/sfu/Boundary-d2dvs2" target=3D"_blank">http://p.=
sf.net/sfu/Boundary-d2dvs2</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>=
<br><div>Peter J. Vessenes</div><div>CEO, CoinLab</div><div>M: 206.595.9839=
</div><br>
</div>

--e89a8ff25350c4187304bd7f3250--