Amir Taaki [ARCHIVE] on Nostr: 📅 Original date posted:2012-04-12 📝 Original message:This is a bad idea. The ...
📅 Original date posted:2012-04-12
📝 Original message:This is a bad idea. The bitcoin protocol is (mostly) stateless. Stateless protocols are more secure.
________________________________
From: Pieter Wuille <pieter.wuille at gmail.com>
To: Gavin Andresen <gavinandresen at gmail.com>
Cc: bitcoin-development at 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 at 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 at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120412/b046c13c/attachment.html>;
📝 Original message:This is a bad idea. The bitcoin protocol is (mostly) stateless. Stateless protocols are more secure.
________________________________
From: Pieter Wuille <pieter.wuille at gmail.com>
To: Gavin Andresen <gavinandresen at gmail.com>
Cc: bitcoin-development at 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 at 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 at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120412/b046c13c/attachment.html>;