Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of bluematt.me
	designates 173.246.101.161 as permitted sender)
	client-ip=173.246.101.161;
	envelope-from=bitcoin-list@bluematt.me; helo=mail.bluematt.me; 
Message-ID: <1351105233.4731.3.camel@localhost.localdomain>
From: Matt Corallo <bitcoin-list@bluematt.me>
To: bitcoin-development@lists.sourceforge.net
Date: Wed, 24 Oct 2012 15:00:33 -0400
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>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [Bitcoin-development] Draft BIP for Bloom filtering
Precedence: list

On Wed, 2012-10-24 at 14:54 -0400, Gavin Andresen 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 believe you meant NOT complicating?
> 
> 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.
> 
Sadly that requires (potentially) more DoS potential because you require
nodes to store each transaction that could be requested instead of just
going ahead and forwarding them.  I agree the BIP should not specify
that the sending node is required to keep track of which transactions
have been announced/sent to clients, however since the reference client
does so currently, that implementation is significantly simpler (note
that it is a bounded set in the reference client, so even the reference
client doesn't really fully comply with the BIP as stated here).  

Matt