Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.82.53 as permitted sender)
	client-ip=74.125.82.53; envelope-from=mh.in.england@gmail.com;
	helo=mail-wg0-f53.google.com; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
In-Reply-To: <CABsx9T0JyFJKLWK09NEzDk6B9Z2Yz7T55kf8GJ2o3ViCnBpRAw@mail.gmail.com>
References: <CANEZrP0XALwBFJyZTzYd5xBp4MRrjv0s_y2tOXbO7UgjWF2HzA@mail.gmail.com>
	<20121024162255.GA30290@vps7135.xlshosting.net>
	<CANEZrP1sxtOb+czMtBTkmzngEwMYRqD667WyKQkAOKLi+mGBGQ@mail.gmail.com>
	<20121024171104.GA31766@vps7135.xlshosting.net>
	<CABsx9T0JyFJKLWK09NEzDk6B9Z2Yz7T55kf8GJ2o3ViCnBpRAw@mail.gmail.com>
Date: Wed, 24 Oct 2012 21:10:49 +0200
Message-ID: <CANEZrP1AFL6ZbV7Njr1s8ggsZkQA1dv_3LYT3z+y83UKqn7Kgg@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=f46d0438eba939fac504ccd2d875
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Draft BIP for Bloom filtering
Precedence: list

--f46d0438eba939fac504ccd2d875
Content-Type: text/plain; charset=UTF-8

Bitcoin already keeps track of which nodes have seen what to avoid
redundant inv announcements.

I think if you are approaching most transactions in a block matching the
filter then you would just request full blocks and do all the filtering
client side
On Oct 24, 2012 8:54 PM, "Gavin Andresen" <gavinandresen@gmail.com> wrote:

> RE: sharing parts of the merkle branches when returning a 'merkleblock' :
>
> I think I agree that complicating the BIP for what should be a very
> rare case (more than a handful of transactions in a block match the
> transactions in your wallet) is the right decision.
>
> I want to make sure I'm understanding this bit correctly:
>
> "In addition, because a merkleblock message contains only a list of
> transaction hashes, any transactions that the requesting node hasn't
> either received or announced with an inv will be automatically sent as
> well. This avoids a slow roundtrip that would otherwise be required
> (receive hashes, didn't see some of these transactions yet, ask for
> them)."
>
> Requiring serving/relaying nodes to keep track of which transactions
> they have or have not sent to their peers makes me nervous. I think
> requiring an extra 'inv' round-trip would be simpler to implement and
> less likely to lead to some kind of DoS attack.
>
> --
> --
> Gavin Andresen
>

--f46d0438eba939fac504ccd2d875
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p>Bitcoin already keeps track of which nodes have seen what to avoid redun=
dant inv announcements. </p>
<p>I think if you are approaching most transactions in a block matching the=
 filter then you would just request full blocks and do all the filtering cl=
ient side </p>
<div class=3D"gmail_quote">On Oct 24, 2012 8:54 PM, &quot;Gavin Andresen&qu=
ot; &lt;<a href=3D"mailto:gavinandresen@gmail.com">gavinandresen@gmail.com<=
/a>&gt; wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
RE: sharing parts of the merkle branches when returning a &#39;merkleblock&=
#39; :<br>
<br>
I think I agree that complicating the BIP for what should be a very<br>
rare case (more than a handful of transactions in a block match the<br>
transactions in your wallet) is the right decision.<br>
<br>
I want to make sure I&#39;m understanding this bit correctly:<br>
<br>
&quot;In addition, because a merkleblock message contains only a list of<br=
>
transaction hashes, any transactions that the requesting node hasn&#39;t<br=
>
either received or announced with an inv will be automatically sent as<br>
well. This avoids a slow roundtrip that would otherwise be required<br>
(receive hashes, didn&#39;t see some of these transactions yet, ask for<br>
them).&quot;<br>
<br>
Requiring serving/relaying nodes to keep track of which transactions<br>
they have or have not sent to their peers makes me nervous. I think<br>
requiring an extra &#39;inv&#39; round-trip would be simpler to implement a=
nd<br>
less likely to lead to some kind of DoS attack.<br>
<br>
--<br>
--<br>
Gavin Andresen<br>
</blockquote></div>

--f46d0438eba939fac504ccd2d875--