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 ) 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 ; 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: <1334251458.43194.YahooMailNeo@web121005.mail.ne1.yahoo.com> From: Peter Vessenes Date: Thu, 12 Apr 2012 11:04:54 -0700 Message-ID: To: Amir Taaki 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" 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 > 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 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

=
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.

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 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.


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's be bet= ter if there was no state whatsoever.

________________________________
From: Jeff Garzik <jgarzik@exmult= i.com>
To: sirk390@gmail.com
Cc: bitcoin-de= velopment@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.c= om> wrote:
> Hi,
>
> I would like to discuss the following bitcoin protocol improvement pro= posal:
>
> =A0 =A0 =A0 =A0 =A0Adding request/reply id in all messages (in the mes= sage 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) &= quot;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 t= o detect and handle
> (e.g. ban the peer and switch to another). =A0This could cause some Do= S
> attacks by misbehaving peers.

If the peer is misbehaving, then disconnect.=A0 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" me= ssages to wait for
> after "getblocks"=A0and 2/ we don't know how to=A0distin= guish between result of
> "getblocks" and spontaneous "inv" notifications. > The same is true for =A0"addr" messages (it is both a notifi= cation and reply)
> 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 the
> following:


Stateless protocols have a lot of value.=A0 They are easiest to
implement, and easier to prove correct.=A0 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.=A0 One must add
code to help remain "synchronized" between local and remote state= s,
which your suggested change only hints at.=A0 NFSv4 and RPC have a long
history of dealing with stateful-ness issues.=A0 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.=A0 Handling
initial block download can be accomplished in a number of ways, and
peer(s) may crash or return odd results.=A0 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-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

---------------------------------------------------------------------------= ---
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-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment



--
=
Peter J. Vessenes
CEO, CoinLab
M: 206.595.9839=

--e89a8ff25350c4187304bd7f3250--