Topic: help with finding issues in a modifcation of Bitcoin core (Read 3357 times)

C'mon guys, no suggestions to check RFC3514?  I was hoping someone would cheer me up.

I'm saying it's stupid to expect privacy when using the public IP's, if people want privacy they should not be broadcasting a transaction from a full node directly from their real IP address.

What you seem to be saying is, because you feel that no-one should expect privacy, you have a right to attack the network and break any privacy others have.

I'm not saying I don't care, I think if someone does care about the privacy of a transaction they should take proper measures to protect their privacy and shouldn't expect privacy on a public Bitcoin node.

Most people care at least a little about privacy.
You are taking away from everyone else's network resources and centralising and decreasing privacy.  It's not a positive balance.

I see privacy as a somewhat separate issue....if someone wants privacy there are plenty of ways to go about that such as using tor. I don't think people should expect privacy when running a full node from a public IP address. Anyways if someone is running a node with unlimited inbound and outbound connections from a high speed connection they are themselves still providing network resources.

I think I've arguably done more to advance privacy in Bitcoin than the next two people combined, I've also done a lot of research towards reducing resource exhaustion attacks.   No one is advocating "just ignoring";  but the fact that we're not yet able to completely mitigate the risk of harm due to chimpanzees with firearms does not mean that it would be wise to start handing out uzis at the zoo or, especially, that we're somehow obligated to arm those primates who have failed find any firearms on their own.

If you are going to make a modification, maybe you could also add some sort of indicator to the node you are connecting to which alerts it that you already have a large amount of connections -- That way others could chose to refuse your connections.

So you think it's better to just ignore the issue and hope people don't modify the source?

The next flag you'd ask for is for a configurable option to override the low priority status...

So why not have low priority outbound connections or something like that(basically any outbound connections above 8 are marked as low priority)? These could be connections that nodes will drop if regular priority incoming connections are competing for space. That could be a way to implement this responsibly so that low priority connections only use excess slots and won't compete for space with regular priority connections.

I disagree. Most of the people who think doing this is okay are not technically competent enough to make the change, -- this is why making the change is hard for them. The result is that the software crashes for the (as we see in this thread), and they adopt a new approach-- sometimes one which is less uncivilized. To whatever extent that people do successfully do so, having more users of the software able to make modifications is a virtue. There are parts of the system where diversity is a hazard, but thats generally limited to the consensus parts.

Thats only true when you are on colocation subnets which are already saturated with nodes. A more common numbers is 80+ and we've had instances of widespread fullness in the past (resulting in problems with nodes getting online). If you would bother to do simple arithmetic you would conclude that even if only 20 were typically used (which isn't the case), it would only take about 100 parties total running "connect to everyone" settings to completely saturate it.  Moreover, what you "consider" or not is irrelevant. It's other people's resources you would be consuming, usually for reasons which are highly adverse to their interests (e.g. spying on them and other users of Bitcoin)... beyond the spying activity, the second most common reason for wanting to do this is also ill advised (some people erroneously believe more connections improves block propagation, when in fact it too many slows it down).  

I think this is a complete overreaction, overriding Bitcoin Core defaults like this is not something that is illegal.

Since there are people who are going to override this anyways I think its better for those users to use tested software than being forced to use their own fork.
This isn't a resource we are really all that close to using up, run a full node and see how close to 125 inbound connections you can get, you usually only get 20-30, these are available resources and using them is not something I consider to be wasting. I don't agree that using FUD is the right way to go about solving issue.

Yes, we refuse to help people who are objectively attacking the network, wasting other users resources and harming their privacy.  Beyond it being harmful to bitcoin and bitcoin's users, knowingly assisting in this activity might make a participant a target of torts from harmed parties or even subject to criminal prosecution in jurisdictions with expansive computer crime laws.

Why people think that its casually okay to attack the network, and think there is any chance that standard Bitcoin software would come with a user exposed switch to make a single node try to use a substantial fraction of the network's total capacity is beyond me. That isn't going to happen; and users should be highly wary of the competence or ethics anyone who ships software that does that (after all, if might makes right then why not also have the software backdoor your computer?-- if it's possible to do, it's okay, by the logic presented here, no?). The fact that someone don't have any ethical qualms about the resources of other people that they waste or the privacy harm most of these efforts are intended to create, nor do they have the most basic software engineering experience to understand the requirements and ramifications of a software change; doesn't create any obligation on my part to compromise my own integrity and aid in these activities.

And sure, sufficiently software-competent people can technically modify the software or write their own which behaves aggressively; but fewer people doing it is an improvement (less resources wasted) even if it is not possible to prevent it completely. This isn't the only thing that is done with respect to this kind of abuse, like in many things a layered response is important, the first is avoiding cases where thoughtful and ethical people do not accidentally abuse the network-- and making it clear what behavior is abusive--, then social, technical, and legal measures can be employed against those who remain. (All of which are continually being worked on by many people).

Yes, but as it is people use different config options when running Bitcoin Core and those are not considered to cause fragmentation, making this change via config would allow for people to use different outbound connection count options without having to maintain and test their own fork.

Having to maintain and compile a separate fork means they have to run code that is less well tested than it could be especially since the core developers actively refuse to provide any assistance and encourage others to not help people making these modifications.

But there is still a real difference there.  One is via a code & compile and the other is via a config.  Whichever way there is still difference there. 

If there are only a few who make this if not harmful, but if there are many of people (like >150) doing that all nodes would have more than 150 connections used for this and no more slot to serve the others (default settings is 125 peers max). With a bigger number maybe it wouldn't be possible to run a node with low hardware because there would be at least 500 guys who would try to connect to your node?

A config flag allows people to use different settings without using a different Bitcoin Core, so it would reduce forks(fragmentation). The point of config flags is to be able to run the same software with different settings.

Well if you had config flag more people would change it which means more people running with different settings which means more "fragmentation"...

It doesn't really make a difference for privacy if those who want to connect to a lot of nodes can modify their clients.
Even with a node not behind NAT its hard to get over 50 connections even when the connection limit is set much higher so I don't think we all that close to being up against the limit.

I understand their reason, I don't agree with it however.
The bitcoin core node is not good at handling certain amounts of connections, there are improvements there that could help.
The fragmentation is because of the need for certain users to override the limit, if it was a config flag it wouldn't be as bad.