Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.82.175 as permitted sender)
	client-ip=74.125.82.175; envelope-from=gavinandresen@gmail.com;
	helo=mail-we0-f175.google.com; 
MIME-Version: 1.0
In-Reply-To: <20121024171104.GA31766@vps7135.xlshosting.net>
References: <CANEZrP0XALwBFJyZTzYd5xBp4MRrjv0s_y2tOXbO7UgjWF2HzA@mail.gmail.com>
	<20121024162255.GA30290@vps7135.xlshosting.net>
	<CANEZrP1sxtOb+czMtBTkmzngEwMYRqD667WyKQkAOKLi+mGBGQ@mail.gmail.com>
	<20121024171104.GA31766@vps7135.xlshosting.net>
Date: Wed, 24 Oct 2012 14:54:15 -0400
Message-ID: <CABsx9T0JyFJKLWK09NEzDk6B9Z2Yz7T55kf8GJ2o3ViCnBpRAw@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Draft BIP for Bloom filtering
Precedence: list

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