Supporting thin blocks is important, but even a one-in-a-million chance of an SPV client not hearing about a transaction is annoying. How about doing this:

    if ((!pfrom->nServices & NODE_NETWORK) || 
                !pfrom->filterInventoryKnown.contains(pair.second))
       pfrom->PushMessage(NetMsgType::TX, block.vtx[pair.first]);

... so SPV clients end up getting extra data, but full nodes don't.

I like the idea but the solution you propose will unfortunately not work for pruned nodes. Is there another way to signal that we want filtered merkleblocks?

Right, you can be NODE_NETWORK and pruned and still wanna do the thin block thing...

This morning I checked, and (at least) bitcoinj doesn't do the BIP130 'sendheaders' thing, so SPV clients don't have the fPreferHeaders flag set. But checking that feels like a hack.

The right way is a new service bit for thin-block-preferring nodes-- and I think the thin blocks patch does have a new service bit, yes?

Yes, there is a new service bit, but still the same problem.

Node supports bloom, but does it support filtered bloom or unfiltered bloom (or both)?
vs.
Node supports thin blocks, but is it bloom thin blocks or xthin blocks (or both)?

There should be sub-service bits :-)

The service bit is for the "extreme" protocol changes. I think we're back to the SPV node being prepared to notice a txid being sent without the full tx. All it really needs to do is process merkleblocks from multiple peers, which it should be doing anyway to catch peers that withhold.

If this is what you're thinking of @gavinandresen , then I'm happy with it. Not because it's a good solution but because it solves my problem :-)

 if ((!pfrom->nService & NODE_XTHIN) || !pfrom->filterInventoryKnown.contains(pair.second))
       pfrom->PushMessage(NetMsgType::TX, block.vtx[pair.first]);

@dagurval Ok, no remote clients currently available will benefit from this, but we are working on one.

Before this PR is updated, we have another question to answer -- how to best distinguish a classic peer (which has this fix) from peer which lacks it.

With the superior Xthin protocol supported, it will be used by the only client that supported XT-style thinblocks anyway. Closing.

Thanks dgenr8!