Sybil attack to prevent blocksize increase (hardfork)

[Itoo]

I haven't seen this discussed but, isn't a possible attack vector a sybil attack implemented specifically to prevent a needed change such as the blocksize increase?

I'm thinking specifically of the ~2000 nodes that were spun up quickly and support classic, and are split between the 3 datacenters.

If that's an attack vector, do we wend up with basically sybil wars (no pun intended hehe) where interested large parties are spinning up nodes constantly in a time of stress for the network (where a hardfork is needed, such as legitimately full blocks AND an obvious need to fix it in order to maintain trust/value/younameit).

Look forward to any replies, thanks.

[1714745023]

1714745023

[1714745023]

1714745023

[Jet Cash]

We don't need an immediate blocksize increase. Half of the recent blocks generated are under 512k.

[yakuza699]

I'm thinking specifically of the ~2000 nodes that were spun up quickly and support classic, and are split between the 3 datacenters.

So what?If nobody connects to these nodes they are useless, and either way normal users has no influence, only miners vote.Or am I mistaking something?

[watashi-kokoto]

yes sibyl attack is very dangerous and it is often done by malicious actors such as governments and/or government controlled corporations. typically to corrupt or manipulate a voting or elections in the system.

Bitcoin has certain counter-measures again this type of attack built in. For example, users losing funds due to sybil attack is highly improbable(impossible).

[SebastianJu]

In fact that get's discussed on alot, way too many threads. Simply search for sybil on the forum and you will find numerous threads.

The probably are fake nodes though it's hard to prove.

[Itoo]

We don't need an immediate blocksize increase. Half of the recent blocks generated are under 512k.

I'm with you on that. It's counter-intuitive initially but I worry that the additional classic nodes (or another set of nodes run by someone else) will be used to interrupt a legitimate effort by the majority of the network to implement that hard fork when that time comes. As for the blocksize discussion, I'm of the opinion it needs to be implemented slowly and with lots of discussion beforehand, and with the right approach. I think that xt and classic have done one thing well, that's bring the discussion to the forefront. Hopefully it leads to a smoother ride when everyone's ready to increase.

[Itoo]

I'm thinking specifically of the ~2000 nodes that were spun up quickly and support classic, and are split between the 3 datacenters.

So what?If nobody connects to these nodes they are useless, and either way normal users has no influence, only miners vote.Or am I mistaking something?

You make a good point that full node operators can disallow connections from those nodes. I need to implement some rules on my node.

As for voting, my understanding is that the nodes are the ones validating blocks/transactions, so nodes are the ones that really have the power. That's the reason we need to keep block size reasonable, because we want as many people as possible to be able to vote by running a node (not to mention to decentralize that trust as far as possible). That's my understanding at least, though it's more complex than that

[exstasie]

For example, users losing funds due to sybil attack is highly improbable(impossible).

Unless the Sybil attacker controls hashpower. Then he can use Sybils to facilitate double spending.