Date: Thu, 12 Apr 2012 18:01:54 +0200
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
Message-ID: <20120412160151.GA1100@vps7135.xlshosting.net>
References: <CA+XhJbpNYUyPm2Ymcpg3grbfGnfERCsUJNJuByEJbJLsMMmMbQ@mail.gmail.com>
	<CABsx9T029cY-OJfZ9n-rSZc7i36e+CkOZPZixdi8EFL7oN4jhQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: <CABsx9T029cY-OJfZ9n-rSZc7i36e+CkOZPZixdi8EFL7oN4jhQ@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Content-Transfer-Encoding: quoted-printable
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Adding request/reply id in messages
Precedence: list

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> wro=
te:
> > I would like to discuss the following bitcoin protocol improvement pr=
oposal:
> >
> > =A0 =A0 =A0 =A0 =A0Adding request/reply id in all messages (in the me=
ssage header,
> > based on what was done for the "checksum" field)
>=20
> 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 t=
rying 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 t=
he client
prevents retransmits. This is not a large problem, but maybe such an exte=
nsion
should also include an extra "denied" message, which is sent if the clien=
t is
unwilling to answer (and may also be used to report transactions that are=
 not
accepted into the memory pool, for example).

--=20
Pieter