Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1SIMxT-0004Gg-NN for bitcoin-development@lists.sourceforge.net; Thu, 12 Apr 2012 16:33:19 +0000 X-ACL-Warn: Received: from nm31-vm7.bullet.mail.ne1.yahoo.com ([98.138.229.47]) by sog-mx-3.v43.ch3.sourceforge.com with smtp (Exim 4.76) id 1SIMxO-0003wv-4Y for bitcoin-development@lists.sourceforge.net; Thu, 12 Apr 2012 16:33:19 +0000 Received: from [98.138.90.51] by nm31.bullet.mail.ne1.yahoo.com with NNFMP; 12 Apr 2012 16:33:08 -0000 Received: from [98.138.89.250] by tm4.bullet.mail.ne1.yahoo.com with NNFMP; 12 Apr 2012 16:33:08 -0000 Received: from [127.0.0.1] by omp1042.mail.ne1.yahoo.com with NNFMP; 12 Apr 2012 16:33:08 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 402780.33554.bm@omp1042.mail.ne1.yahoo.com Received: (qmail 81745 invoked by uid 60001); 12 Apr 2012 16:33:08 -0000 X-YMail-OSG: UkdHo0wVM1nK32wGXJJo5JH8iev4FCMiBoa339dyPcl2vnM 4G2CK0A22M4PEFokl6dc1428_w0.57eedwBNwmGm_upi3irfgwWB7OSXI.hL EME66Dsk1_UbESmK4juvayAvp_hh_AT8m3UxfgCgs1pGCEhqGFYUc3_oC5bB LcW1Gq24aJh0uonY6iLkIEfuERsSImoBG12_XHeqDOymrpJw_MNtM.Dhzs66 G2l9vLfTRkDY2lektaNDmLaLo3bdL.flTs6XOKFN7R5YKK31KtLN83LCeP6m I7Ix4iNTmsnKFoD5c1eDqkOokgTZg2sgkBnrzexJS0bUZpmCo3XYQpIbrVPp ZwuMTJLEplBYIK3WQNCtwZOCD8iBJABzNjVzKed_OcXvq.zWSRbu9SH.6VJG RwmxepS9ZRtBy4IP0ihMMLd.EkmpKB91nBob2kg7qG4befTYgnRzf49omHQp t3fOu4W1kC9iprtQZhWo_HAJYizjOFUI- Received: from [92.20.151.121] by web121004.mail.ne1.yahoo.com via HTTP; Thu, 12 Apr 2012 09:33:07 PDT X-Mailer: YahooMailWebService/0.8.117.340979 References: <20120412160151.GA1100@vps7135.xlshosting.net> Message-ID: <1334248387.65842.YahooMailNeo@web121004.mail.ne1.yahoo.com> Date: Thu, 12 Apr 2012 09:33:07 -0700 (PDT) From: Amir Taaki To: "bitcoin-development@lists.sourceforge.net" In-Reply-To: <20120412160151.GA1100@vps7135.xlshosting.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1562933420-1933066806-1334248387=:65842" X-Spam-Score: 0.9 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [98.138.229.47 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (zgenjix[at]yahoo.com) -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1SIMxO-0003wv-4Y Subject: Re: [Bitcoin-development] Adding request/reply id in messages X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Amir Taaki List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 16:33:19 -0000 ---1562933420-1933066806-1334248387=:65842 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable This is a bad idea. The bitcoin protocol is (mostly) stateless. Stateless p= rotocols are more secure.=0A=0A=0A=0A________________________________=0A Fr= om: Pieter Wuille =0ATo: Gavin Andresen =0ACc: bitcoin-development@lists.sourceforge.net =0ASent: T= hursday, April 12, 2012 5:01 PM=0ASubject: Re: [Bitcoin-development] Adding= request/reply id in messages=0A =0AOn Thu, Apr 12, 2012 at 11:41:05AM -040= 0, Gavin Andresen wrote:=0A> On Wed, Apr 11, 2012 at 2:39 PM, Christian Bod= t wrote:=0A> > I would like to discuss the following bi= tcoin protocol improvement proposal:=0A> >=0A> > =A0 =A0 =A0 =A0 =A0Adding = request/reply id in all messages (in the message header,=0A> > based on wha= t was done for the "checksum" field)=0A> =0A> That seems like a perfectly r= easonable protocol improvement to me.=0A> Anybody else have an opinion?=0A= =0AIf there is a reasonable use for it, I have no objections.=0A=0AHowever:= the bitcoin P2P protocol is not fully request-reply based, and trying to u= se=0Ait that may be be less intuitive than how it looks. For example, doing= a second=0Aidentical "getblocks" request will not result in more "inv" rep= lies, as the client=0Aprevents retransmits. This is not a large problem, bu= t maybe such an extension=0Ashould also include an extra "denied" message, = which is sent if the client is=0Aunwilling to answer (and may also be used = to report transactions that are not=0Aaccepted into the memory pool, for ex= ample).=0A=0A-- =0APieter=0A=0A--------------------------------------------= ----------------------------------=0AFor Developers, A Lot Can Happen In A = Second.=0ABoundary is the first to Know...and Tell You.=0AMonitor Your Appl= ications in Ultra-Fine Resolution. Try it FREE!=0Ahttp://p.sf.net/sfu/Bound= ary-d2dvs2=0A_______________________________________________=0ABitcoin-deve= lopment mailing list=0ABitcoin-development@lists.sourceforge.net=0Ahttps://= lists.sourceforge.net/lists/listinfo/bitcoin-development ---1562933420-1933066806-1334248387=:65842 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
This is a = bad idea. The bitcoin protocol is (mostly) stateless. Stateless protocols a= re more secure.

From: Pieter Wuille <pieter.wuille@gm= ail.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
=0AOn 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:
> >
> >     &nbs= p;    Adding request/reply id in all messages (in the message hea= der,
> > 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 n= ot fully request-reply based, and trying to use
it that may be be less i= ntuitive than how it looks. For example, doing a second
identical "getbl= ocks" request will not result in more "inv" replies, as the client
preve= nts retransmits. This is not a large problem, but maybe such an extension
s= hould also include an extra "denied" message, which is sent if the client i= s
unwilling to answer (and may also be used to report transactions that = are not
accepted into the memory pool, for example).

--
Piete= r

------------------------------------------------------------------= ------------
For Developers, A Lot Can Happen In A Second.
Boundary i= s the first to Know...and Tell You.
Monitor Your Applications in Ultra-F= ine 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-dev= elopment


---1562933420-1933066806-1334248387=:65842--