Topic: What are Bitcoin Core Devs cooking under radar? Disabling SPV completely!!!! (Read 818 times)

The official reason is the prevent SPV clients from spamming old nodes that don't support bloom filters with their bloom filter requests.

As for having the option to disable bloom filters, I couldn't tell ya.

So, the benefit would be, that we would theoretical get more full nodes from people with bad hardware or bandwidth?
Is that the official reason for implementing this?

So, you need bloom filters to run a SPV efficiently? (I don't understand much about bloom filters, but with my little knowledge, that actually makes more sense)
So, what exactly are the benefits of disabling bloom filters?

None for the SPV client. For the full node that supplies the client data, it reduces the amount of data it uses and prevents DoS attacks. Otherwise disabling bloom filters is pretty much pointless and not beneficial except for people running nodes on low end hardware and low bandwidth networks.

Seems like I got this wrong: So, you need bloom filters to run a SPV efficiently? (I don't understand much about bloom filters, but with my little knowledge, that actually makes more sense)
So, what exactly are the benefits of disabling bloom filters?

It can be both a problem and a benefit. Instead of wasting resources trying to get a node to respond to a service request it doesn't support, the SPV client can go look for nodes that actually respond to its request. On the other hand, if people disable bloom filters, you pretty much leave those SPV clients in the dark or using the old method which takes a lot of data.

You sound exactly like the people, who defended the evil "drop Tor-Nodes if you are DDOSed"-feature in BitcoinXT

But to get serious again:
Is that a problem for SPV-clients or not? Can they implement bloom-filters without a blockchain of their own?

Now you understand how it feel about the blacklist nonsense?

Yes ofcourse the client operator can choose to disable or enable this feature.

However, why does core devs spend time on this while the blocksize limit is the urgent issue.

You sound exactly like the people, who defended the evil "drop Tor-Nodes if you are DDOSed"-feature in BitcoinXT

But to get serious again:
Is that a problem for SPV-clients or not? Can they implement bloom-filters without a blockchain of their own?

It is NOT blacklisting all SPV clients. It is implementing an extra bit which indicates whether the node supports bloom filters or not. They are also adding an option in Bitcoin Core to disable bloom filters should the operator wish to do so. It has bloom filters enabled by default.

It is NOT blacklisting all SPV clients. It is implementing an extra bit which indicates whether the node supports bloom filters or not. They are also adding an option in Bitcoin Core to disable bloom filters should the operator wish to do so. It has bloom filters enabled by default.

And there I thought blacklisting is a bad thing, but hey just blacklist all SPV-clients.
Why is the "but you don't have to enable it"-argument valid in this case?

Fernando,

You're getting confused because you're looking at lists of people who:

    Have contributed code to Core (and because XT is Core, thus XT as well)
    Have contributed code that's in XT but not Core
    Have contributed code to XT that isn't yet accepted or merged

The pull request you linked to is marked open (see the green badge at the top left). If accepted it will change to say "closed" or "merged".

It's still open because, as you may have noticed, both Gavin and I have been away last week and didn't have much time for coding. So the work wasn't yet reviewed. In the case of this patch, I'd like Gavin to review it, as he worked on that region of code last and knows it best. If he doesn't have time, I'll do it.

Now, to your wider question. XT is about more than just the block size limit. If you look at Core, they have also decided they don't like unconfirmed transactions and P2P smartphone wallets. They blocked improvements for a long time already and are now preparing to delete support for P2P lightweight wallets entirely.

Obviously neither feature is required for some kind of rarely used settlement network, which is their vision. But they are rather important for the actual Bitcoin network we have today.

Their wildly different (incorrect) vision and the general way they treat volunteer developers, means lots of people who would have contributed to the Bitcoin project haven't done so, or did and then stopped. I'm one, Gavin is one, Thomas Zander is also one.

As you can see from the pull requests queue and chatter on this list, suddenly people are coming out of the woodwork with patches that aren't anything to do with bigger blocks, they're just stuff that was rejected for questionable or outright spurious reasons by the Bitcoin Core project. So now there's a chance for a re-review under a different development philosophy.

And all this is just after 7 days. So I am not too worried about number of developers.

With respect to "centralisation of developers": centralisation doesn't come from the size of a dev team or who pushes the commit button, it comes from inability to stop using what that team produces because they are a monopoly. Right now Bitcoin Core has a monopoly and are desperately trying to keep it, by telling everyone the sky will fall if they use XT. And monopolies suffer all sorts of problems, don't they?