From: Amir Taaki <zgenjix@yahoo•com>
To: "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 09:33:07 -0700 (PDT) [thread overview]
Message-ID: <1334248387.65842.YahooMailNeo@web121004.mail.ne1.yahoo.com> (raw)
In-Reply-To: <20120412160151.GA1100@vps7135.xlshosting.net>
[-- Attachment #1: Type: text/plain, Size: 1953 bytes --]
This is a bad idea. The bitcoin protocol is (mostly) stateless. Stateless protocols are more secure.
________________________________
From: Pieter Wuille <pieter.wuille@gmail•com>
To: Gavin Andresen <gavinandresen@gmail•com>
Cc: bitcoin-development@lists•sourceforge.net
Sent: Thursday, April 12, 2012 5:01 PM
Subject: Re: [Bitcoin-development] Adding request/reply id in messages
On Thu, Apr 12, 2012 at 11:41:05AM -0400, Gavin Andresen wrote:
> On Wed, Apr 11, 2012 at 2:39 PM, Christian Bodt <sirk390@gmail•com> wrote:
> > 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)
>
> That seems like a perfectly reasonable protocol improvement to me.
> Anybody else have an opinion?
If there is a reasonable use for it, I have no objections.
However: the bitcoin P2P protocol is not fully request-reply based, and trying to use
it that may be be less intuitive than how it looks. For example, doing a second
identical "getblocks" request will not result in more "inv" replies, as the client
prevents retransmits. This is not a large problem, but maybe such an extension
should also include an extra "denied" message, which is sent if the client is
unwilling to answer (and may also be used to report transactions that are not
accepted into the memory pool, for example).
--
Pieter
------------------------------------------------------------------------------
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
[-- Attachment #2: Type: text/html, Size: 3060 bytes --]
next prev parent reply other threads:[~2012-04-12 16:33 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 [this message]
[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
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=1334248387.65842.YahooMailNeo@web121004.mail.ne1.yahoo.com \
--to=zgenjix@yahoo$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/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