What are Bitcoin Core Devs cooking under radar? Disabling SPV completely!!!!

[meono]

While guys are busy fighting each other,

It seems nobody cares to look at that bitcoin core developers' vision:

https://github.com/bitcoin/bitcoin/pull/6579


The only reason i can think of disabling SPV is so larger blocks take longer time to propagate.

I want to see the pro Core shills here answer to that. This is "decentralization" we're wishing for?


For anyone who does not understand what SPV is:

SPV means simplified payment verification, which is a scheme described in the Satoshi whitepaper for a form of lightweight client. SPV clients store only the headers, and ask nodes for copies of the relevant transactions in their wallet, which the SPV wallet can verify against the merkle root in the block headers.

Bloom filters are a privacy precaution, whereby the SPV client asks a node it's connected to for a range of addresses, in order to obfuscate which ones the wallet actually cares about.

The alternative to a lightweight wallet acting like this is for the wallet to connect to a specialized server that is connected to a node that indexes the transactions in the blockchain. Electrum does this is a totally open source way where you can run your own server. Otherwise every other option connects you to a centralized 3rd party API that allows the company or group behind it perfect surveilance over your addresses and transactions.

Attacking SPV wallets that connect directly to nodes (breadwallet, schildbach, multibit, etc) is basically taking away an admittedly imperfect way of doing wallets really peer-to-peer, which may in my opinion be sour grapes over the fact that Mike Hearn wrote bitcoinj and/or the fact that there are devs with an interest in centralized wallets.


In summary, it looks like core developers' vision and commutity's are further apart.

[meono]

https://groups.google.com/forum/#!msg/bitcoin-xt/PBjK0BuB7s4/8LREpcaNBQAJ

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?

[achow101]

I would advise you read the discussion on that pr thread and read the actual bip here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010535.html

If you actually read any of those, it should be clear that this is simply giving operators the option of disabling bloom filters and thus disabling connections to spv wallets. It is just like the choice to choose Core or XT. Additionally, it is not only a change to Core, but a change to the protocol. It prevents SPV wallets from constantly sending requests to a node that does not support bloom filters (e.g. old nodes) thereby conserving resources ON BOTH ENDS so that they can be put to actual use instead of wasted.

Furthermore, Core is not by default disabling this feature. It is only giving node operators the option to turn it off, and for people who just start Bitcoin Core and leave it running (like me) then it doesn't matter.

[Carlton Banks]

https://github.com/bitcoin/bitcoin/pull/6579

Not too sure about your arguments, gentlemen; TheBlueMatt is the coder who introduced bloom filters in the first place. Troll harder.

[turvarya]

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?

[achow101]

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?

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.

[turvarya]

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?

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.

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?

[meono]

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?

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.

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 do core devs spend time on this while the blocksize limit is the urgent issue.


Only one agenda that would make sense, cause more time delay for bigger blocks to propagate. Thus put a lower soft limit on miners. This will make Blockstream even more attractive. Conflict of interest much?

[Carlton Banks]

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?

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.

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?

I'll keep it turned on, as I intend to continue maintaining a full node, at least for using Armory with. I'd encourage others to do the same.

[achow101]

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?

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.

Now you understand how it feel about the blacklist nonsense?

Nope. No idea what you are talking about

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.

There are other issues than just the blocksize limit. If every time some large issue prevented anything else from happening, than Bitcoin would stagnate and nothing would get done. Same thing with other software. You can't have everyone working on one issue and not doing anything else. It prevents any progress from happening.

There is a thing called multi tasking, which is what they are doing. They are working on multiple things at a time to be more efficient and get more done. While some people debate the block size issue, other people work on other stuff. Some people work on implementations of their proposals for the block size, and others do stuff to improve other aspects. This is what makes groups of people great. You can have a few guys on one thing, a few more on another, and so on.

If you actually read the developer mailing list, then you would see that they not only discuss blocksize stuff, but also other stuff. In fact, a large chunk of the discussions on the mailing list are not about the block size.

[Kazimir]

Chill out dude, Core devs are not disabling SPV at all.

[achow101]

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?

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.

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

[turvarya]

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?

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.

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

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?

[achow101]

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?

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.

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

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?

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.

[turvarya]

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?

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.

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

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?

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.

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?

[Carlton Banks]

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?

pre version 0.8.0, there's no bloom filter support. Those nodes can get spammed with requests from SPV mobile wallets, but it seems like a bit of a non-issue when most old clients are so small a minority.

There's another argument that miners might want the option to turn bloom filters off to improve marginal mining performance somehow. Maybe that's sensible, and there are still public nodes available on the network, I'd be surprised if serving SPV requests would be too much for them to deal with exclusively, as it seems like that's the only kind of node I tend to when using SPV myself.

[nutildah]

OP I think you got hacked bruv.

Can't remember the last time I saw somebody call themselves "Dickhead" on purpose.

[achow101]

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?

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.

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

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?

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.

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?

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.

[tvbcof]

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.

When Hearn gets his XT forked, and especially if he is constantly communicating 'checkpoints' to multibitch clients on his mindless drone minion's cell phones, he'll have a ready made botnet to DDOS any core nodes he chooses using legal bloom filter methods to do it.  My guess is that this is proactive defense against such an attack.