From: Peter Vessenes <peter@coinlab•com>
To: Amir Taaki <zgenjix@yahoo•com>
Cc: "bitcoin-development@lists•sourceforge.net"
<bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Adding request/reply id in messages
Date: Thu, 12 Apr 2012 11:04:54 -0700 [thread overview]
Message-ID: <CAMGNxUvjUMYW-Bpr68d+jPQ33Y=2nOX8zPNuUwZ0uOdf9ZfJog@mail.gmail.com> (raw)
In-Reply-To: <1334251458.43194.YahooMailNeo@web121005.mail.ne1.yahoo.com>
[-- Attachment #1: Type: text/plain, Size: 5324 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 6946 bytes --]
next prev parent reply other threads:[~2012-04-12 18:05 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-11 18:39 Christian Bodt
2012-04-12 15:41 ` Gavin Andresen
2012-04-12 16:01 ` Pieter Wuille
2012-04-12 16:33 ` Amir Taaki
[not found] ` <CA+XhJbq01knW4XizF3DjaaXnzChvixsxwgFMzWiPPehYuvVk1w@mail.gmail.com>
2012-04-12 16:54 ` Christian Bodt
2012-04-12 17:12 ` Jeff Garzik
2012-04-12 17:24 ` Amir Taaki
2012-04-12 18:04 ` Peter Vessenes [this message]
2012-04-12 20:53 ` Christian Bodt
2012-04-13 6:30 ` Wladimir
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAMGNxUvjUMYW-Bpr68d+jPQ33Y=2nOX8zPNuUwZ0uOdf9ZfJog@mail.gmail.com' \
--to=peter@coinlab$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=zgenjix@yahoo$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox