SYBILing nodes! 😱 Exploiting IC Network... Community Attention Required!

[tina23]

Following George’s post, I also want to add that I have fully self funded all my nodes and have not received any funding from George.

[Lorimer]

I would like to clarify that I am not responsible for the recent motion proposals either.

---

My intention has always been for this discussion to be productive. I’m glad to see the conversation finally moving along, after more than a month of unwillingness from certain individuals to comment on key points (and some very dismissive comments along the way). I hope my frustration has not come across as unproductive. This is an important topic, and I think it needs pushing forward.

I haven’t got much time to catch up on everything tonight, but I would like to pick up on a few things.

@sat

It’s only possible to prove an existing link in some cases, and have suspicion otherwise. In this thread there is a lot of suspicion and little proofs, but even suspicion is actionable IMHO

I completely agree - I don’t really think proof is possible (or realistically obtainable) in most cases. We need suspicions to be able to be broached and explored in the open, and for that to be normal and acceptable, as a means of combating complacency (we currently have too much of the latter, not the other way around).

I’m very much a fan of your suggestions @Sat (it’s along the lines of what I was originally suggesting when I started this thread).

---

Thanks for your post @GAbassad. If the community is going to establish a means of homing in on potential threats of this sort, it would be helpful to gain an understanding of some of the legitimate reasons for peculiar commonalities. Your answers might help serve as context for evaluating other suspicious cases now or in the future. Some of these questions may seem pointless, and/or the answers obvious, but I’d appreciate you entertaining them if you would.

• Could you explain the reason for the naming convention used in the forum accounts discussed above? In Geeta’s case a prior account was created on the same day using her full name, but then abandoned in favour of the “{name}23” format. Can I ask why there was a need to go out of the way to establish consistency in this respect? What’s the meaning of the 23 suffix?
• Would you also be able to comment on the motivation for posting practically identical onboarding statements? Most other statements have significantly more uniqueness to them.
• Have you ever taken responsibility over managing the affairs of any of Geeta’s nodes for her?
• Could you provide some specifics regarding your motivations for creating the GeoNodes node provider? What was stopping you from onboarding more nodes under your existing Node Provider entity? If you could provide the concrete reasons and specifics (rather than generalities) that would be very helpful. Please note that I’m asking about the decision (and reasoning) to onboard that company as a distinct Node Provider (not the decision to found the company). It has always been clear that Node Providers are meant to represent independent entities.

@GAbassad

Even if all our nodes were consolidated under Tina and myself, we would still be well below the 42-node threshold (and the 42-node threshold wasn’t even in place yet when we onboarded). The suggestion that we are over represented is factually incorrect.

You only need 13 sybiling nodes to control a subnet, and fewer to attack a subnet. In any case I gather that the limit has been a matter of interest to you?

@katiep

we have told him that we—DFINITY—would not vote in support of him running more than 42 nodes no matter how many businesses it is or people that he’s assisting

---

Similarly, @roald-av8, are you able to respond regarding the non-disclosure agreement you have with the node provider that gave you your nodes? Why do the terms of your node transfer need to be kept secret?

This question, and others, have gone unanswered for quite some time now (and nobody seems to mind).

[marcio]

Just catching up, what a mess.

I’d strongly recommend increasing the number of DFINITY nodes to the maximum possible and transitioning to something like proof of stake asap.

(Although, given the lack of urgency, it appears that all the nodes are among friends.)

[wpb]

There was another thread started today by the proposer for motion proposal 135636 that is related to this topic. That thread is mostly unproductive due to other contributors, but @GAbassad did provide a comment that has additional relevant information. A cross reference is provided below.

Drain the Swamp

I am truly in shock at the claims made in this post, though I respond not with outrage, but with a commitment to setting the record straight. It is one thing to raise concerns about the decentralization of the network, but it is quite another to make unfounded accusations that distort reality and misrepresent my role in the ecosystem. Let me be absolutely clear: I have no relationship with the individuals mentioned: Artem Horodyskyi, Bohatyrov Volodymyr, Ivanov Oleksandr, Maksym Ishchenko, or V…

[marcio]

KYC and similar methods can only prove the existence of collusion, not its absence. Since there’s no definitive solution to this problem, we should move on by adopting staking mechanisms and increasing the number of nodes in a subnet. However, this essentially breaks everything.

[ysyms]

I just hope DFINITY doesn’t anchor its security on KYC or similar mechanisms—they’re far from foolproof. If laws alone could protect blockchain, Kim Jong-un wouldn’t have successfully confiscated funds from Bybit.

Another critical issue is that NPs -rewards are pegged to fiat currency valuations. Since they’re consistently profitable, NPs employ every possible method to maximize scale expansion. Even if Sybil NPs don’t intend to directly attack the ICP network, this risk-free profit mechanism fuels aggressive scaling among all NPs. Worse still, it fosters corrupt practices like collusion and resource monopolization, embedding latent systemic risks into the ICP ecosystem.

[Sormarler]

I think employing a hybrid approach of staking and KYC is worth considering. I’m not so certain anymore that hardware costs alone provide enough stake to prevent malicious behavior in the network.

[LaCosta]

Proposal 135626 – LaCosta | CodeGov

Vote: REJECT

Node Provider GeoNodes LLC has active nodes and the intent of the proposal was purely to raise attention to an issue discussed in this thread.

It was a lot to catch up but I do understand the issues raised. Even if in past proposals, specially in the wave of node handovers from NPs to other NPs, I have voted to adopt them, it has been purely out of own judgement, not enough proof for any speculation, and to comply with current standards imposed by the community after long discussions that should not be tossed aside.

As for a path toward trying to mitigate speculation, I do think that a Proof of Stake model might make sense. Even if the Node Providers are off boarded after having been discovered to have colluded, it’s impossible to know the profit that was made until then, to say that the loss of having to see through the dc contracts would discourage this behavior.

Although introducing clusters, that can link “possibly” colluding nodes and make them part of the dre tool, in order to separate them from same subnets, might be a good idea as to encourage a discussion with the NPs that might in same way have been abstract in their answers previously, I don’t think enough proof from this discussions would ever satisfy people who think two NPs have colluded. It would create a big mess of discussions and theories, and I believe that it could create marketing campaign against people or businesses who don’t like each other.

Regarding out to “catch” such situations, I think Periodic Physical Audits are a great solution, but discussions such as who would do them would need to be had. As a suggestion I wouldn’t probably want DFINITY to make them but a third party voted by the community. Probably some time would need to be allocated so that everyone can make a recommendation and reach a consensus. Another situation is how would such audits be payed; would DFINITY take that cost?

I think this discussion was due to be had and I have to praise @Lorimer in that regard. This discussion should be about how the IC should move forward regarding node onboarding, creation of NPs and handovers, instead of pointing fingers.

About CodeGov

CodeGov has a team of developers who review and vote independently on the following proposal topics: IC-OS Version Election, Protocol Canister Management, Subnet Management, Node Admin, and Participant Management. The CodeGov NNS known neuron is configured to follow our reviewers on these technical topics. We also have a group of Followees who vote independently on the Governance and the SNS & Neuron’s Fund topics. We strive to be a credible and reliable Followee option that votes on every proposal and every proposal topic in the NNS. We also support decentralization of SNS projects such as WaterNeuron, KongSwap, and Alice with a known neuron and credible Followees.

Learn more about CodeGov and its mission at codegov.org.

[Quyho3]

Ideas to Counter Sybil Attacks & Centralization Risks in ICP

1. Stronger Node Verification

• Implement stricter KYC & business relationship tracking for Node Providers.
• Require on-chain proof of node location to prevent fake geographic distribution.

2. Staking & Slashing Mechanism

• Introduce mandatory staking for Node Providers.
• Slashing penalties for fraudulent activities (e.g., fake identities, collusion).

3. Decentralized Onboarding & Auditing

• Establish community-driven validation for new NPs.
• Use randomized audits & reputation scoring to detect Sybil behavior.

4. Subnet Distribution Rules

• Limit the number of nodes controlled by related entities in critical subnets.
• Ensure geographic and ownership diversity in node allocation.

5. Transparency & Open Discussion

• Maintain real-time dashboards tracking node ownership concentration.
• Encourage regular community reports on decentralization risks.

Goal: Make Sybil attacks costly and ineffective, while strengthening ICP’s decentralization and security.

[marcio]

I don’t think we can run the IC based on “Proof of Lack of Suspicion.” Perhaps that’s why our TVL remains low.

By the way, where are the researchers who mathematically proved this was nearly impossible?

[GAbassad]

Would you also be able to comment on the motivation for posting practically identical onboarding statements? Most other statements have significantly more uniqueness to them.

These are basically boiler plate statements, there is even a template from Dfinity for it. We simply copied previous statements that were attached to successful proposals. It is not a creativity exercise.

Have you ever taken responsibility over managing the affairs of any of Geeta’s nodes for her?

No. Also, Geeta manages her own financial affairs and invested in her 4 nodes with her own money.

Could you provide some specifics regarding your motivations for creating the GeoNodes node provider? What was stopping you from onboarding more nodes under your existing Node Provider entity? If you could provide the concrete reasons and specifics (rather than generalities) that would be very helpful. Please note that I’m asking about the decision (and reasoning) to onboard that company as a distinct Node Provider (not the decision to found the company). It has always been clear that Node Providers are meant to represent independent entities.

I think we already stated why. I onboarded initially under my own name. Subsequent to that, Tina and I saw an opportunity to work together to add additional nodes and other countries. Upon speaking to data centres, we found out that they only accepted a legal entity as a customer. Having a legal entity fulfilled that requirement, and the ownership structure ensured clear transparency between Tina and myself. For what it’s worth, if we had onboarded these nodes under our individual names we could have actually earned higher rewards due to the way Gen 2 node rewards work.

You only need 13 sybiling nodes to control a subnet, and fewer to attack a subnet. In any case I gather that the limit has been a matter of interest to you?

This limit didn’t even exist when we onboarded, so no, it was of no interest to us as it didn’t exist. In any case, we are still far away from that limit. This limit mainly affected Gen 1 node providers, no Gen 2 node providers even have that many nodes. Also, we have no influence over which subnet our nodes are in.

[bjoernek]

Regarding the discussions on potential node provider collusion in this forum thread and the motion proposal, we would like to provide the following input from the perspective of DFINITY:

We recognize that community scrutiny on this issue is valuable, and we appreciate the transparency provided by the responses from some node providers in this thread. In our view, there is no substantial evidence to justify the offboarding of any node provider.

Furthermore, as a sample analysis, we looked into the set-up of nodes located in Lithuania looking for potential similarities in the infrastructure of these nodes across different node providers. We confirmed that the nodes were indeed located in Lithuania and that they had different data centers with distinctly different uplink patterns: George’s nodes in Lithuania were using IP ranges belonging to an ISP in Georgia, while nodes on the local ISP Baltineta provided very good connectivity to neighbouring countries.

In the short term, to address the concerns raised, we encourage all relevant node providers to provide explanations on relationships to other node providers, as some have already done. In the meantime, in order to allow further time for the discussion we are considering submitting subnet management proposals to the NNS to temporarily reduce the number of concerned nodes in critical subnets. This approach would not adversely affect these node providers, as they would continue to receive rewards, and it would allow more time for information sharing and community review.

In the mid-term, we agree with suggestions in this thread to continue discussions on enhancements for node provider governance, including the possibility of node audits.

[geeta23]

To add to the above, I chose my original user name, but the confirmation email to activate my account didn’t come through until much later. I assumed in the meantime maybe I did something wrong, and created another forum account. Why did I choose Geeta23? I onboarded in 2023 and I think that just made sense to me at the time.

[Alex43342]

Good day, my name is Ivanov Oleksandr. I am a validator, miner, and crypto enthusiast. I feel very upset to hear misunderstandings directed at me, as well as being called a fake person, and so on. I was thinking about what kind of proof I could provide to show that I am a real person and someone who is connected to the crypto industry and servers.

I will provide you with a video from my phone. Here is my Trustee bank account — you can use Google to see what it is. It’s a crypto bank card. In this video, you can see my first and last name, as well as the fact that I am paying a significant bill to Hetzner. You can also look up what that is on Google, but those who are familiar with servers know that it is a data center operator.

I believe that this evidence is sufficient to prove that I am a real person, and I kindly ask you to clear me of all suspicions.

What other proof do you need?

IMG_7052.MP4

[Volodymyr]

Hello everyone, i hope you are all doing well. I am Volodymyr Bohatyrov and I am also joining this discussion. I was also present at the conference in Istanbul where I came across the ICP booth. I have been interested in cryptocurrencies since 2020, but I havent learned how to make money through trading, so I chose to focus on validators instead. I know some people from this list, but I am an independent validator and participate in Solana and some projects within the Cosmos network. For me. ICP is very important since I am a holder of coins that I bought at $11 and am currently at a loss. Thank you to everyone who supports the project and believes in a decentralized future.

[alexu]

The DFINITY Foundation intends to vote against proposal 135626 because removing a Node Provider record while the nodes remain in active subnets would result in an inconsistent system state.

UPD: Please note that there is also a motion proposal 135636 up for a vote.

[MaksT6]

Hi all, I hope you are all doing well. I was very surprised to see this post on the forum and want to state that everything mentioned in it is false. Someone is trying to portray me in a bad light.

I am just a regular DevOps who honestly does his job by helping and supporting the ICP project through node management. I hope the DFINITY team will pay attention to this situation and help resolve this misunderstanding.

I am also attaching video evidence from my personal Binance account to prove that I am a real person:

Screen recording.mov

I’m always available and ready to cooperate. Thank you all for your support!

Maksym Ishchenko - Node provider

[sat]

We submitted a few proposals related to this discussion:

Subnet Management - tdb26 (NNS)

A new proposal with ID 135664 has been submitted, please take a look. Click here to open proposal details

Subnet Management - pzp6e (Fiduciary)

A new proposal with ID 135665 has been submitted, please take a look. Click here to open proposal details

Subnet Management - uzr34 (II)

A new proposal with ID 135666 has been submitted, please take a look. Click here to open proposal details

Note that in NONE of these subnets these providers (or provider clusters) were close to the dangerous thresholds in any way.
Still, to be on the safe side we submitted these proposals as a tactical measure. There will be a separate analysis and discussion to agree how to handle and if possible prevent similar cases in the future.

[JunQ]

Hello, my name is Artem Horodyskyi, and I am a validator on Solana and ICP. I am a real user and pay for the servers with my own card. I recently purchased another server for Solana and other projects. To confirm my words, I am attaching screenshots of the server payments and my passport.

[timk11]

Proposals 135664, 135665 & 135666 | Tim - CodeGov

Vote: Reject

These proposals are intended to replace some of the nodes in 3 selected subnets. I appreciate what the @DRE-Team are trying to do here in providing a option to split up allegedly colluding node providers so as to reduce the chance of a successful attack on one of these subnets. I also think the “cluster” approach is worth considering. However, I’d first like to see more community discussion on this approach and an NNS vote on whether this is the way that we’d like to move forward. While the uncertainty remains, I’d also prefer to keep the Nakamoto coefficients high. The Nakamoto coefficient is the minimum number of entities (such as countries, node providers or data centres) who would need to collude in order to launch a successful attack. In each of these proposals the regional and country Nakamoto coefficients decrease, and the number of countries containing 3 nodes for each subnet increases, thereby leaving the network more susceptible to attack than before.

All that being said, however, I won’t argue against anybody else’s decision to adopt or reject these proposals. Although I’ve voted to reject them, I’m glad to see these proposals submitted. The big thing about this is that it provides the NNS community with a option to change the network or not to change it based on which perceived threat is thought to be the greatest, and to do it in a way that doesn’t render the network unstable. What I’d most like to see here is for a high proportion of voters to weigh this up and cast a manual vote rather than leaving it to the major followee neurons to make the choice.

About CodeGov

CodeGov has a team of developers who review and vote independently on the following proposal topics: IC-OS Version Election, Protocol Canister Management, Subnet Management, Node Admin, and Participant Management. The CodeGov NNS known neuron is configured to follow our reviewers on these technical topics. We also have a group of Followees who vote independently on the Governance and the SNS & Neurons’ Fund topics. We strive to be a credible and reliable Followee option that votes on every proposal and every proposal topic in the NNS. We also support decentralisation of SNS projects such as WaterNeuron, KongSwap, and Alice with a known neuron and credible Followees.

Learn more about CodeGov and its mission at codegov.org.