<html><body><div style="color:#000; background-color:#fff; font-family:times new roman, new york, times, serif;font-size:12pt"><div><span>This is a bad idea. The bitcoin protocol is (mostly) stateless. Stateless protocols are more secure.</span></div><div><br></div> <div style="font-family: times new roman, new york, times, serif; font-size: 12pt;"> <div style="font-family: times new roman, new york, times, serif; font-size: 12pt;"> <div dir="ltr"> <font face="Arial" size="2"> <hr size="1"> <b><span style="font-weight:bold;">From:</span></b> Pieter Wuille <pieter.wuille@gmail.com><br> <b><span style="font-weight: bold;">To:</span></b> Gavin Andresen <gavinandresen@gmail.com> <br><b><span style="font-weight: bold;">Cc:</span></b> bitcoin-development@lists.sourceforge.net <br> <b><span style="font-weight: bold;">Sent:</span></b> Thursday, April 12, 2012 5:01 PM<br> <b><span style="font-weight: bold;">Subject:</span></b> Re:
[Bitcoin-development] Adding request/reply id in messages<br> </font> </div> <br>
On Thu, Apr 12, 2012 at 11:41:05AM -0400, Gavin Andresen wrote:<br>> On Wed, Apr 11, 2012 at 2:39 PM, Christian Bodt <<a ymailto="mailto:sirk390@gmail.com" href="mailto:sirk390@gmail.com">sirk390@gmail.com</a>> wrote:<br>> > I would like to discuss the following bitcoin protocol improvement proposal:<br>> ><br>> > Adding request/reply id in all messages (in the message header,<br>> > based on what was done for the "checksum" field)<br>> <br>> That seems like a perfectly reasonable protocol improvement to me.<br>> Anybody else have an opinion?<br><br>If there is a reasonable use for it, I have no objections.<br><br>However: the bitcoin P2P protocol is not fully request-reply based, and trying to use<br>it that may be be less intuitive than how it looks. For example, doing a second<br>identical "getblocks" request will not result in more "inv" replies, as the client<br>prevents
retransmits. This is not a large problem, but maybe such an extension<br>should also include an extra "denied" message, which is sent if the client is<br>unwilling to answer (and may also be used to report transactions that are not<br>accepted into the memory pool, for example).<br><br>-- <br>Pieter<br><br>------------------------------------------------------------------------------<br>For Developers, A Lot Can Happen In A Second.<br>Boundary is the first to Know...and Tell You.<br>Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!<br>http://p.sf.net/sfu/Boundary-d2dvs2<br>_______________________________________________<br>Bitcoin-development mailing list<br><a ymailto="mailto:Bitcoin-development@lists.sourceforge.net" href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a><br><a href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development"
target="_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br><br><br> </div> </div> </div></body></html>