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

[Lorimer]

@katiep

This is neither, just an observation that most law-making entities, when they write those laws, include the funding/means/plan to enforce it.

Web 3 doesn’t work the same as traditional systems. Governance entity independence is fundamentally unverifiable, just as the existence of a deity is fundamentally unfalsifiable… While you cannot prove independence, you can disprove it (if someone slips up).

@katiep

I don’t know much about how miners and stakers on other blockchains operate, but how have those blockchains ensure that server owners haven’t given access to other people, who might also have access to other mining servers?

By having thousands of nodes participating in consensus (significantly reducing the chances and means of a single entity gaining control)… The IC has as few as 13 nodes - it doesn’t work without strict KYC and clear rules about independence (and the threat of offbording if caught out).

In this context, I personally think the following is a very confusing statement for a person in your position at DFINITY to make →

@katiep

To be frank, it would have been remarkably easy for Gwodja to have two separate forum accounts for the two posts. It wouldn’t be breaking any rules to do that either

You’re guiding node providers (as well as proposal reviewers) to disregard restrictions that are supposed to be levied against independent node providers.

@katiep

I am not expert in this area.

Given this, can I ask why you’re the one guiding this operation (steering the node providers that are being onboarded, and steering the voting community)? Please forgive my bluntness, but I’m quite baffled by some of your statements, and I’m concerned.

---

On a related note, if I were to stop chasing @tina23 / @geeta23 / @paul23 for an explanation of their circumstances, would you be chasing this at all? Do you know what the relationship is between these three entities? Do you consider it your business to know, or at least to do your best know, or at least to ask?

Again… I’m sorry for how I must be coming across. I’m a nice person (I promise)

[katiep]

Before I sign off for a long weekend.
I am making no attempt to steer the voting community. I’ve merely been having a conversation with you.

My job is not to steer anything, but merely to track information about rewards and nodes onboarding. I have been involved with this since Genesis. Thus, I have answers and relevant information to a small amount of the questions that you’ve asked. This position has also led me to have many of the same concerns you have, but I have (I think) a bit more experience about “real world” logistics that are relevant to any solution being successful, which I have simply sought to share for consideration. Not at all to discount your concerns (because in reality, I share them), but because these subjects appear, to me, to be very complex with many sides that must be considered in order for a successful solution to be found.

Perhaps I have spoken too much in this thread and given the impression that I am trying to steer things. I am not, so for that, please forgive me. I only seek to provide information and context.

DFINITY is trying to hand over more and more of the steering to the community, which is why the Technical Working Groups are taking a leading role in solving some of these things. Again, you are certainly welcome to join!

[000]

Thank you for your work, I share your concerns and hope that the Foundation will improve so that ICP does not suffer losses.

[alexu]

Hello @Lorimer and all!
As @maria pointed out, I’ve taken over Sven’s responsibilities within DFINITY Foundation.

Today I’d like to share with you the work we did on geolocation of the nodes in question.

TL;DR: we were able to confirm the locations for the nodes of Geeta Kalwani, Bianca-Martina Rohner, and GeoNodes LLC (San Jose DC) using RIPE Atlas infrastructure.

Methodology

The investigation will use the methods available via the RIPE Atlas network, such as ping and traceroute tools, as well as IP geolocation databases from IPinfo.io

RIPE Atlas Network

RIPE Atlas is a global Internet measurement platform operated by the RIPE NCC (Réseaux IP Européens Network Coordination Centre). RIPE Atlas consists of thirteen thousands of small measurement devices—called probes and anchors—that are distributed all around the world. These devices allows basic connectivity checks, such as ping, traceroute, TLS, DNS, NTP. The locations of all the probes and anchors within the system are known and publicly available.

Global Ping Tests

Randomly selected list of 300 probes that are pinging the specified location and reporting the results. The graphs are showing red for high ping, yellow for ok’ish ping, and green and dark green for extremely low ping (signifying geographical proximity)

Local Ping Tests

Once server locations are determined with ping, a random selection of probes in that country plus random selection of probes in the node-reported country is selected for the localized ping test.

Traceroute Tests

Traceroute tests are showing the connectivity path between probe and the tested IP, including AS number, as well as ping delay for each hop. We don’t count on the probes to be successful, but hoping to see the path the packets take in order to reach the destination.

IP Info Geolocation Lookups

Lookups via ipinfo.io. The geolocation of IP addresses reported via this site are not always accurate, especially for the IPv6 space, but it can serve as a confirmation of the findings.

Binding the Ping Delay to the Geopositioning

We assume the speed of light in fiber to be about 2×10^8 m/s (assuming uninterrupted piece of fiber not traversing any routing equipment, so in reality the speed is going to be slower). This roughly means that a ping delay of 1ms is equal to 100km round trip in the best scenario.

Transparency of the Measurements

Each measurement we reference in this document are public, each one contains a link to the Atlas website, so interested parties can inspect these measurements for themselves.

Targeted Node Providers

The investigation will focus on the following node providers:

Node Provider	Rationale for Selection
Geeta Kalwani	Accusation of unfair play
Bianca-Martina Rohner	Accusation of unfair play
GeoNodes LLC (San Jose DC)	Accusation of unfair play

Geeta Kalwani

Self-reported server location: Bogota, Colombia

Global Ping Tests

Node: 7pvxh-37ula-relu7-uim72-jvx46-dcnvm-52zsf-vkqzm-xsjoy-4xf4l-hqe

IP: 2606:f180:2:0:6801:c4ff:fe6a:32c3

URL: RIPE Atlas - RIPE Network Coordination Centre

Quick analysis: the lowest ping is from Colombia.

Node: aajth-ndp7x-ro5ok-yikyd-4i7xn-5k5ki-e3d37-hh4gn-s4opz-bnzxf-4qe

IP: 2606:f180:2:0:6801:efff:fe01:6663

URL: RIPE Atlas - RIPE Network Coordination Centre
Quick analysis: the lowest ping is from Colombia.

Node: ihttm-45oz5-an5mg-i2jtb-fayst-s47j6-vmuwr-fqotf-mp2il-n5s5x-cae

IP: 2606:f180:2:0:6801:9cff:fe75:1e81

URL: RIPE Atlas - RIPE Network Coordination Centre
Quick analysis: the lowest ping is from Colombia.

Node: tws6x-33lmm-tptgb-v2tte-opnm4-fychj-thpve-x4ofu-cn4vo-6yuhl-qqe

IP: 2606:f180:2:0:6801:73ff:fe8f:1fb

URL: RIPE Atlas - RIPE Network Coordination Centre
Quick analysis: the lowest ping is from Belize. No Colombian probes were selected for the measurements due to randomness of the Atlas probe allocation.

Local Ping Test

URL: RIPE Atlas - RIPE Network Coordination Centre
Quick analysis: local ping tests are showing results for Panama, Costa Rica, and Colombia. The top 7 probes are from Colombia, strongly indicating the local presence or point of entry.

Traceroute Test

All trace routes are ending and timing out at Ufinet Panama S.A. ASN 52468.

IP Info Test

Quick analysis: IP Info test shows location for Bogota, Colombia.

Overall Analysis for Geeta Kalwani Geolocation

While we saw that the lowest pings to the servers are indeed located in Colombia, In our tests we were not able to see any confirmation for pings to the servers lower than 10ms. Theoretically, given the speed of light in fiber, these servers could be up to 1000km away from the location of the probes, while the point of entry could be in Colombia.

Alternatively, it could mean that Colombian internet infrastructure needs to be modernized.

We addressed these concerns in the Additional Tests section further in this document.

Bianca-Martina Rohner

Self-reported server location: Panama City, Panama

Global Ping Test

Node: 2xph2-xvn4v-pc5xz-3upfj-etpio-qaf2k-d2s3v-jnceu-vcher-qhqav-rqe

IP: 2606:f180:9:1a:6801:ebff:fee1:8e66

URL: RIPE Atlas - RIPE Network Coordination Centre

Quick analysis: the lowest ping is from a probe in Panama City, Panama

Node: Bxczc-ao2x4-yzmq4-o2ezo-7mjct-ypeqs-6rcyl-ozl5d-j64m6-blata-iae

IP: 2606:f180:9:1a:6801:caff:fe3f:5e5

URL: RIPE Atlas - RIPE Network Coordination Centre
Quick analysis: the lowest ping is from Panama City, Panama

Node: Euo2x-vl67u-3vtja-yrovf-oah6r-pq43e-pn522-j3zq2-pnly3-ad7wd-lqe

IP: 2606:f180:9:1a:6801:b4ff:fe4e:71b5

URL: RIPE Atlas - RIPE Network Coordination Centre
Quick analysis: the lowest ping is from Dominican Republic. The probe in Panama wasn’t able to reach the node.

Node: Y7bml-csbq7-euzyf-njmvm-qfftp-iy7lc-wisaq-jlmul-sdo7p-7lkx4-3ae

IP: 2606:f180:9:1a:6801:a3ff:fe02:4b1b

URL: RIPE Atlas - RIPE Network Coordination Centre
Quick Analysis: the lowest ping is from Costa Rica with 15ms. Probe in Panama wasn’t able to reach the node.

Local Ping Test

URL: RIPE Atlas - RIPE Network Coordination Centre
Quick analysis: confirmed 1.833ms ping from Anchor 7104, located at InterRED Panama. This strongly suggests the server is within 180km radius of the Boca La Caja in Panama City.

Traceroute Test

All trace routes are ending and timing out at Ufinet Panama S.A. ASN 52468.

IP Info Test

Quick analysis: the IP Info test here reports the location for Johannesburg in South Africa. It doesn’t match the ping data observed. We can disregard this result as obsolete and/or incorrect.

Overall Analysis for Bianca-Martina Rohner Geolocation

Local ping test strongly points to the geolocation within 180km radius from the Panama City.

GeoNodes LLC

Self-reported server locations:

• San Jose, Costa Rica
• Tel Aviv, Israel

We chose 2 random nodes to San Jose DC to test.

Global Ping Test San Jose

Node: 7muaz-6c5bc-6wjw2-f65xy-i7poz-jwhob-ty26j-ol5dh-hf3oo-dkgb3-6qe

IP: 2800:c20:0:29:6801:49ff:fe53:bb30

URL: RIPE Atlas - RIPE Network Coordination Centre
Quick analysis: the shortest ping is 0.851ms from the probe in Costa Rica. This strongly indicates the location is within 85km from the probe in San Jose, CR.

Node: Qobom-nt626-4n6jf-nrepv-xpdez-m4s66-fch4n-tdwdg-mibua-pq5xc-rae

IP: 2800:c20:0:29:6801:ff:fec2:7fa1

URL: RIPE Atlas - RIPE Network Coordination Centre
Quick analysis: the 1.07ms reply from a probe in San Jose strongly indicates the server is within 100km of the location.

Local Ping Test San Jose

1.3ms test from Costa Rica probe 1003235

URL: RIPE Atlas - RIPE Network Coordination Centre
Quick analysis: confirming already discovered during the global ping test the location approximation, i.e. within 130km radius from San Jose.

Traceroute Test San Jose

Ending at Navegalo SA ASN28110

IP Info San Jose

Quick analysis: the IPInfo test is confirming the ping test findings, in this case.

Additional Tests To Determine The Connectivity Baseline

Local ping tests confirm the servers are located within 100km distance from the probes, which strongly indicates that the servers are indeed in the locations self-reported by the node providers.

The question to be answered is for the Colombian servers, which shows only 10ms ping local test for the best results. Since 10ms RTT can theoretically mean up to 1000 km distance from the measurement probe, we need additional tests to determine connectivity baseline within this region and test the hypothesis whether it is possible to have servers in Panama or Costa Rica, while showing a point of presence in Colombia.

We perform two tests:

• Colombian probes doing a ping test on one of the servers in Panama
• Colombian probes doing a ping test on one of the servers in Costa Rica

Testing connectivity to Panama City.
URL: RIPE Atlas - RIPE Network Coordination Centre

Testing connectivity to San Jose
URL: RIPE Atlas - RIPE Network Coordination Centre

Additional Tests Analysis

We can conclude that the baseline connectivity is quite poor, so it is extremely unlikely that someone could have a 10ms or even shorter tunnel to their servers from Colombia located in some other geographical location, it has to be within the same country.

Conclusion and Future Work

We were able to confirm the locations of the nodes for the three node providers in question. We plan to expand this work on the whole IC nodes and automate such checks in the future. We also welcome our community’s feedback on the work performed and happy to address any omissions/shortcomings and/or errors.

Thank you!

[Lorimer]

Thanks @alexu for the really thorough analysis! This confirms @tmshlvck’s findings. Automating and extending these checks to other nodes sounds like a great idea (particularly in light of the new proposed reward boosts based on country). I’ve since updated my SM review tooling to make use of a more accurate geolocation service (thanks @LaCosta for pointing me to it).

Out of interest, could you imagine the IC being able to utilise node machines themselves as probes at some point in the future? Not that that’s necessary, but would be cool to take advantage of the geographically distributed network that the IC already has at its disposal for this purpose. Just thinking out loud.

---

The other issue is related to KYC and independence (e.g. NP aliases).

@Zane and I had a zoom chat this morning before work to catch up and to discuss this, which I found really useful. When I’ve got some more time I’ll write up one of the ideas that came out of our chat.

I’d also like to further clarify some concerns.

[borovan]

They said that about Station

[tina23]

Hi Lorimer,

Thanks for your follow-up.

Onboarding as an Individual vs. a Legal Entity

There was no attempt to obscure ownership or gain an unfair advantage. The decisions we made were based on practical, transparent, and strategic reasons aimed at contributing to the decentralisation of the Internet Computer network.

1. Timing & Practicality

• George Bassadone onboarded as an individual simply because it was the fastest and most straightforward option. Setting up a legal entity takes time and resources, so onboarding as an individual was the logical first step.

2. Expanding into New Countries to Improve Decentralization

• After George’s initial onboarding, George and I identified opportunities to expand into underrepresented regions where there were very few nodes. The vast majority of nodes are in Europe and North America, so expanding to Latin America was an opportunity to strengthen decentralisation and network resilience.

• Since we’ve known each other for a long time and saw this as a good opportunity, we structured ownership through a jointly owned legal entity, ensuring clear accountability.

• It’s important to emphasise that if we had been trying to maximise rewards, we could have onboarded under multiple separate entities to take advantage of Gen2 node reward mechanisms. We deliberately did not do this, demonstrating that our goal was never to game the system.

• Additionally, some data centers only accept legal entities as customers, which was another reason for structuring the setup this way.

3. Further Expansion in Panama

• Later, I added four more nodes in my personal capacity in Panama, all of which were accurately declared in the self-declarations.

• There are no “aliases” or hidden entities involved—everything is fully transparent and documented.

Forum Participation & Communication

• There is no rule on forum usernames, and I have always used the same forum name I am posting from now.

• The Element channel is the primary space where node providers discuss operations, not this forum.

• Regarding past forum posts, it is completely reasonable to reference previously successful NNS proposals to ensure alignment. This is standard practice, as proposal rejections come with costs.

Commitment to the Community & Ecosystem

• We are active contributors to the Node Provider Working Group and ICP ecosystem. We both invest in ecosystem projects and strategically work with founders to help develop projects.

• We have met many DFINITY employees and fellow node providers in person, including at the Zurich node provider meet-up in May 2024.

• As the Internet Computer evolves, we remain committed to constructive discussions about node provider onboarding and broader ecosystem growth.

At the end of the day, our actions have been fully transparent, strategically sound, and beneficial to the network. The Internet Computer needs more node decentralisation, and our efforts have contributed to that goal.

Tina

[Lorimer]

Hi Tina,

Thanks for your explanation. Could you please follow up with a clear statement that clarifies the relation that @geeta23 and @paul23 have to you and @GAbassad? You’ve omitted this from your explanation above.

[Lorimer]

@Lorimer

Could you also comment on the naming conventions used for the various …23 accounts, and the other commonalities among these accounts - several of which I’ve highlighted

@tina23, it’s now been two weeks since I asked you this. You took the time to write the response above and avoided the most important question. What relation do these accounts have to you and/or @GAbassad?

Are you surprised by the commonalities these accounts have to yours? Is it a coincodence?

[ZackDS]

Proposal #135626 — Zack | CodeGov

Vote: Rejected
Reason:
Node Provide GeoNodes LLC has active nodes used in subnets.
Given the fact that this proposal is of Participant Management Topic and Add or Remove Node Provider Type there are certain steps that need to be taken before getting to this.
I recomend starting with a proposal of Governance Topic and Motion type.

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.

[timk11]

Proposal 135626 | Tim - CodeGov

Vote: Reject

This proposal seeks to remove a node provider that still has active nodes in the network. The proposal appears to have been submitted anonymously given that the included link is to this entire thread rather than to a specific post. I agree that the potential for surreptitious collusion (as Sybil attacks) is a big concern, but I would recommend that this be addressed by raising a discussion about methods that could be used to detect such collusion. Potential solutions could then be put into a Governance proposal so that the whole IC community can jointly decide how this should be managed.

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.

[Lorimer]

Given that proposal 135626 links directly to this thread which I started, I feel the need to clarify that this proposal was not submitted by me. The proposing neuron has a huuuuge stake, and has been around since 2021.

I’m glad to see whales taking an active role in due diligence, and recognising the severity of this sort of issue. I think this topic needs to be brought into focus. @geeta23, @tina23, @paul23 have so far declined to comment on their relationship to one another:

• Geeta Kalwani
• Tina Rohner
• Paul Creasey

All 3 of these individuals have pretty much identical onboarding statements, and a clear convention in their account name, as well as node machine hosting similarities. When questioned about this, there’s a lack of honesty/transparency - “I just chose some username”…

@Lorimer

if one NP would like to onboard more nodes under a different identity, they could ask their wife (or husband) to do so for them

Based on what I can find, I think it’s very likely that Geeta is George Bassadone’s wife (both are node providers). GeoNodes (another node provider entity) is basically a business alias for Tina and George. Tina and Paul (another node provider and prospective node provider) are close colleagues from Goldman Sachs. Unclear how many other business fronts there are. I strongly suspect there are other node providers involved that aren’t as obvious, and I think the problem is getting worse.

NPs are springing up with non-disclosure agreements that prevent them from disclosing the agreement between them and another node provider that gave them the nodes. In other cases new providers are declining to comment on the details about how they acquired their nodes. Despite this, proposal reviewers have been happy to adopt. We desperately need a better system, and more due diligence.

@katiep

DFINITY is trying to hand over more and more of the steering to the community, which is why the Technical Working Groups are taking a leading role in solving some of these things. Again, you are certainly welcome to join!

Node Provider Working groups, in my opinion, are not the forum for addressing this problem. What motivation do NPs have for making their lives harder, increasing the penalties that could be levied against them in the future? Also, given that I’m so far one of the few people who’s been vocal about this, I can’t imagine having much fun in one of these working groups. It also takes place during working hours for me, so it’s not really an option.

@maria

I suggest we continue exploring these ideas during the next Node Provider Working Group

Are you able to provide an update with how it went @maria? @louisevelayo has already been asked almost a week ago…

New Node Provider Proposals

@Lorimer These are great points and I agree with pretty much everything you’ve said here. I’m keen to hear other people’s thoughts on this. @louisevelayo Has much of this been discussed in the node provider working group?

Given that we know that there are Node Providers out there that are literally business fronts for other pre-existing Node Providers, we know that Node Providers are not at all required to be independent in order to convince the NNS to onboard them, yet that’s exactly what Node Providers are supposed to and need to be. It’s a foundational assumption that the IC Target Topology is based on.

Yet there are DFINITY representatives saying things like this…

@katiep

I personally believe that an ideal world would permit people to have nodes running under different entities if it makes more business sense

If you think this is a problem that will disappear as the IC scales, you’re mistaken. It can only get worse. As the number of node providers grows, the sybiling fraction that slip through the net become a larger portion relative to the size of individual subnets (which have as few as 13 nodes). As described here, it would be relatively easy to nudge those nodes into the same subnet and seize control.

---

I would suggest that we urgently need an initiative that does the following things:

• Node Provider consolidation
  • Node Providers that have multiplied their presence on the IC under multiple NP entities should be collapsed into a single Node Provider (note that this does not require a change to the businesses, just how they’re represented on the IC)
• Node Provider full-disclosure
  • All Node Providers should be required to publish details that describe how they acquired their nodes, who from, for how much, and which other Node Providers they have a close relationship with (this aspect needs a rigorous definition to capture nuance and edge cases).
• A Clear Statement of Intent for Punishment
  • One that’s blessed by a motion, which makes it clear that if at any point in the future any of the above statements that have been published by Node Providers are found to have been lies or objectively inaccurate, they will be off-boarded. By itself this isn’t really enough. We need proof-of-stake, and the threat of that stake being confiscated/slashed. Node machines themselves are not a stake, unless the NNS is able to revoke an NPs custody of the machine (in my opinion this would be ideal).
• Periodic Physical Audits (a solid plan that these will begin taking place in the future)
  • This is how NPs will be held to account, and the knowledge that this will take place in the future should be sufficient to encourage NPs to fully disclose their details honestly now.

Perhaps the above points can be fleshed out and put to a motion?

[louisevelayo]

Proposal 135626 – Louise | Aviate Labs

Vote: REJECT
Review:
The Node Provider GeoNodes LLC still has active nodes in subnets. In line with the other reviewers, I agree that there should first be a governance proposal of how to verify and handle this. That way the community can decide together.

About Aviate Labs

Aviate Labs is a team dedicated to supporting node providers since 2020. Our mission is to make high-performance infrastructure management on the Internet Computer (ICP) as seamless as possible, while adhering to the principles of decentralization.

We are known for our contributions to the ecosystem, including the go-agent and developer work packages on GitHub, as well as the Node Monitor tool, which alerts Node Providers as soon as any of their nodes go down.

In the NNS, Louise reviews and votes independently on ‘Node Admin’ and ‘Participant Management’ proposals on behalf of the Aviate Labs Neuron.

The Aviate Labs known neuron is configured to follow Louise for these topics and other trusted entities for broader proposals. We strive to be a credible and reliable Followee, committed to voting on every proposal and supporting decentralization within the ICP ecosystem.

[ZackDS]

Hey Alex allow me to clarify as well. Nobody from CodeGov (can’t speak for the rest of community) alleged that it was you behind the proposal, it was a choice on my part to reply to this thread since it was linked to the proposal and as you well know we are required to post on the forum so I tried to avoid spamming it by creating another new thread for said proposal and post here.

[sat]

To try to be constructive here… it’s certainly a big concern for me as well @Lorimer. I wanted to share that I do think that there is a way to limit the risk. Steps would be:

1. somehow agree, community-wide, which providers might be linked; possibly through an NNS vote, or maybe there is some other more efficient way
2. we can use the this information in the DRE tooling to maximally decentralize nodes considering the potential links, as this is currently done with Provider, DC, Country, etc. We could add the potential links as a new dimension for optimizing decentralization. Some changes in the DRE tooling would be needed but I don’t think it’s too hard.

Then we could just submit proposals that reduce the number of nodes that these “clusters” of potentially linked nodes have.
WDYT? Any suggestions how to practically implement the above? The DRE tooling changes are relatively easy, the tricky part would be mapping out links and coming to an agreement that everyone is happy with.

And additionally we need to come up with a way to identify and handle these cases in the future. We can’t expect 100% success rate since it’s not possible to prove that someone does NOT have a link to someone else. 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. Let’s just try to be constructive and pragmatic.

[timk11]

@sat That sounds like a very good suggestion and potentially a fair way to address this in cases where there is suspicion but not proof.

Perhaps “clusters” could be added as a single additional category in the DRE tool. Maybe just call it Tag, Group, or whatever. The field could take a single numerical value that serves as a binary representation of an NP’s membership of various clusters as agreed on through Governance motions, with a default value of 0. For example, let’s say we have NP A, NP B and NP C thought to be a colluding cluster (or the same person), so cluster 0. We also have NP D, NP E and NP F as another such cluster - cluster 1. At a later stage we find another cluster (cluster 2) consisting of NP A and NP D. In this case the field value for NP A would be 5 (binary 101) and for NP D would be 6 (binary 110). In this way any number of clusters could be mapped out and a change to the topology proposed to determine how many members of the same cluster are allowed on the same subnet. (Ideally 1, but this might get tricky if there are a large number of suspected clusters.) I’d suggest keeping this out of the Nakamoto coefficient calculation and treating it separately.

It warrants a lot more discussion and input of course - perhaps it could get out of hand, or some might see it as a soft option - I don’t have any firm position on it and I’m not discounting any other suggestions that involve firmer penalties. These are just my initial thoughts as to how such a solution could be put into practice.

To add context for anyone who’s not familiar - please see this proposal for an example of the output of the DRE tool.

[wpb]

Hey @sat and @timk11 please correct me if I’m wrong, but the only node relationship clusters that really matter are the nodes that were transferred to new node providers to comply with the new rule limiting node providers to 42 nodes. In all cases, don’t we know who transferred which nodes to which new node providers or which nodes had more than one owner in the past? Do the node IDs change when the hardware changes owners? Why not just avoid placing the nodes that were previously owned by the larger node provider in the same subnet? If the nodes are not uniquely identifiable, then define the cluster by node transfer relationships.

I’m not at all saying that there is any nefarious activity among the node providers as outlined in this long forum thread. I don’t think concrete evidence has been provided. However, I do think that the fact that node providers with excess nodes (more than 42) were allowed to sell the machine AND the right to place that machine on the network with guaranteed remuneration may have created opportunities to game the system in ways that were not intended. I think the rules around how those transfers were required to take place may not have been defined clearly enough. A simple solution seems like it would be to define relationship clusters based on who transferred nodes to who.

If that creates some sort of constraint on the topology we want to achieve, then perhaps we can add a new, optional verification that enables new node providers to decouple from the clusters if they can offer more verifiable and concrete proof of independence. This may be akin to what @Lorimer called Node Provider Full-Disclosure above. More than likely it will still be a judgement call, but the litmus test could be whatever folks like @Lorimer @timk11 @ZackDS @LaCosta @louisevelayo @sat, and anyone else who is actually reviewing Node Admin, Participant Management, and Subnet Management proposals finds acceptable. The number of people who are incentivized to review these proposal topics needs to increase in order for this to be fair.

The current rules that define what is sufficient proof of independence for new node providers who took ownership of excess nodes were defined before there was anyone in the community who started reviewing these proposal topics. Since they all know first hand how difficult it is to verify independence, perhaps they should be given the opportunity to define it in a more robust way and then we can let all node providers voluntarily attempt to satisfy this full disclosure litmus test in order to dissociate themselves from any cluster. Eventually a remuneration reduction factor can be introduced that penalizes any node provider that remains in a cluster or does not satisfy this full-disclosure litmus test.

I also agree with part of @Lorimer’s suggestion above that we have a Clear Statement of Intent for Punishment that is blessed by the NNS. I do not believe we should take it as far as the proof of stake that he suggested, but I do believe that any node provider that has provided objectively inaccurate disclosure information should be off-boarded. I believe the loss of remuneration is sufficient penalty because they would be stuck in expensive data center contracts that they can no longer pay for with remuneration and they would be stuck with specialized, high end, node machine hardware that they have to figure out how to unload at a fair market value that is likely less than what the machine is worth when it is deployed on the ICP network.

The idea for Periodic Physical Audits has also been discussed for a long time and I think it would be well worth pursuing.

[sat]

@wpb

please correct me if I’m wrong, but the only node relationship clusters that really matter are the nodes that were transferred to new node providers to comply with the new rule limiting node providers to 42 nodes

Not necessarily @wpb . Tina, George, etc are regular Gen2 providers, so not falling into this bucket of Gen1 providers (getting limited to 42 nodes).
I do agree with everything else you wrote. There is no PROOF that any of them are linked and certainly no proof that they are malicious in any way. There is only speculation that they MAY be linked and MAY collude given enough incentive. Consequentially, I do not feel that we should make any rash moves. Let’s think this through.

[GAbassad]

Dear IC Community,

I want to directly address these allegations and reaffirm that we have followed all onboarding processes correctly, transparently, and in full compliance with IC governance requirements in place at the time of our onboarding.

Clarifying Relationships & Compliance Regarding Geeta, Tina, and GeoNodes

Yes, Geeta is my wife, but this was not a required disclosure during onboarding, nor was there any reason to declare it.

She onboarded as an independent node provider, following the same process and meeting the same requirements as any other provider.

Tina and I have known each other for a long time. She runs her nodes independently under her own name and jointly owns GeoNodes with me.

We confirm that we do not control or have any affiliation with any other nodes.

On Business Structuring & Node Distribution

As mentioned in our previous post, structuring node operations through different entities is a legitimate and standard business practice for several reasons, including:

• Data centre requirements (some require contracts with legal entities).
• Operational and tax efficiency, which is standard across industries.

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.

The IC governance framework does not prohibit spouses, business partners, or colleagues from operating as separate node providers, as long as they meet onboarding requirements.

Addressing Accusations of Network Manipulation

The accusation that this is a Sybil attack or an attempt to manipulate the network is completely false.

• All entities were onboarded transparently and in compliance with IC governance rules.
• There was no attempt to obscure ownership or misrepresent node locations.
• The IC governance framework only requires node providers to comply with onboarding criteria, which we have done fully. The IC governance framework does not specify any “related party” rules or definition thereof, which would be a very extensive topic that would require some lengthy discussion. This was not something we thought about at all in our onboarding process.

If the community believes new rules should be introduced around disclosures, we welcome that discussion.

Community Engagement & Collaboration

Both Tina and I attended the Node Provider Workshop in Zurich, where we had the opportunity to meet other node providers and collaborate on best practices. Engaging with other node providers does not equate to collusion. It is an essential part of strengthening the IC network. The node provider network is filled with dedicated individuals who have been part of this community for a long time and who are committed to the success of the IC ecosystem.

It is concerning to see false narratives and personal accusations being used as a basis for governance discussions.

Transparency is important, but fairness is equally critical. Targeting specific node providers with vague accusations while ignoring the fact that these structures are fully compliant is misleading.

If governance changes are needed, they should be discussed constructively, not through public attacks that undermine trust in the ecosystem.

Governance discussions should not be driven by speculation, suspicion, or selective scrutiny. They should be fact-based and forward-looking.

Finally, we have always complied with IC governance policies and will continue to do so. We remain committed to strengthening the IC ecosystem through fair and transparent governance.

[wpb]

Thank you for offering this clarification @GAbassad. It really helps. I also agree with your comments about the IC governance policies and work process and the need for constructive discussion on improvements.