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?