[Bitcoin-development] Draft BIP for Bloom filtering

Matt Corallo bitcoin-list at bluematt.me
Wed Oct 24 19:00:33 UTC 2012

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).  


More information about the bitcoin-dev mailing list