Assigned 'future' milestone accordingly.

@TheBlueMatt can this be re-based?

Yeah a rebase would make it clear that the base pull has been merged.

Rebased.

On 09/09/15 15:09, P. Kaufmann wrote:

Yeah a rebase would make it clear that the base pull has been merged.

—
Reply to this email directly or view it on GitHub
#6641 (comment).

Note for future: Don't forget to adjust https://github.com/bitcoin/bitcoin/blob/e59d2a80f9167031521d882394a08b02fa9d0343/doc/bips.md

Updated to include doc/bips.md update (needed to rebase to do so)

There was discussion about this in #bitcoin today: some prefer this to be an option that would already be present in 0.12 but default to off, then the option removed in 0.13.
(not necessarily saying this is a good idea, just thought I'd remark it)

some prefer this to be an option that would already be present in 0.12 but default to off

This would certainly be useful for mining pools and other high-availability services that can't afford to waste resources serving SPV clients. I don't see any significant usability issues with allowing this right away since SPV clients will just look for more nodes if they get disconnected(the percentage of nodes using this option is likely to be quite small due to most using default settings). This appears to be a better solution than the current method of white-listing nodes by subver(which is in use by pools such as f2pool).

Concept ACK.
Although there is one problem: Misbehaving(pfrom->GetId(), 100) results in a ban, fDisconnect=true allows a node to reconnect. My tests have shown that SPV clients tend to directly reconnect, call filter commands, get disconnected, a.s.o. Which happens in connect/disconnect loops multiple times per second.
Not sure what is best here, maybe it's reasonable to ban the node for serval minutes after not respecting the NODE_BLOOM bit.

Concept ACK

@jonasschnelli I think fDisconnect is the only reasonable behavior we can do (unless we implement a temporary ban, but that wouldnt add much given that either way it results in disconnect after only one or two roundtrips). We certainly cant completely ban given that we really want the "wait, why is my node not syncing? Oh, there's an update to my software" flow to work.

Rebased.

Moved milestone from 'future' to '0.13', we can always decide to postpone further if SPV client implementations aren't ready by then.

Needs rebase.

Still needs rebase

@laanwj #7708

Closing in favor of #7708