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" <gavinandre...@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
>
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
