We have plenty of other topics on this forum where your conspiracy theories are being discussed and I am happy to contribute again there. This topic was started by Dfinity to collect feedback on what they are proposing, which I have given. Let’s keep it constructive here and not derail this topic.
1 Like
I think it is an excellent suggestion from Dfinity and like @icarus I wholeheartedly support the changes.
I believe that it is essential that Dfinity know exactly who is reaponsible for their nodes. An increased KYC level is essential.
However, I do not think hosting this on a public wiki is a good idea. It does expose UBOs to security risks.
6 Likes
Yes, just like getting a mortgage. The bank know who you are, and how you got the money. Nobody else knows.
1 Like
Thank you for your detailed feedback @snoopy !
To make sure that I understand the above point: How does this differ from the suggestion in the original post to engage recognized third-party services to verify the independence of node providers?
1 Like
Thank you, @Thyassa! I completely agree. The (potentially sensitive or confidential) documents required for verifying identity and node provider independence should not be stored in a publicly accessible manner. For the network, it is only essential that the results of the node provider verification, for example in the form of a certificate, are publicly available.
1 Like
How I understood the original post is that each node provider would be KYC’ed on an individual basis. If then that KYC firm would also have to verify that each node provider doesn’t have a link to any other node provider (and there could be 100s or 1000s in the future), wouldn’t that be potentially costly and time consuming? Instead one could establish criteria of independence here on the NNS, node providers declare themselves if there is anything to declare in terms of links, and on a periodic basis one engages an outside firm that looks at the node provider “network” from a bird’s eye view to see if they can find any other links that have not been disclosed.
As I understood it:
The KYC firm would not be the validator for links. It is the validator for the ultimate beneficial owner.
That is the person who would then reveal what links they have. Note links are not “I had a coffee and a polite chat with x who happened to be in the same town”. As @icarus explained way better than I can in the call, it is to say what possibly exposure risks there are for their nodes. Do you share the same data center, have the same sys admin, that sort of thing.
Obviously, things like “my boss gave me money so I could buy some machines” should be discovered in the KYC process.
As to the penalties, most obvious would be to force a sale of their nodes at market rate to a 100% kyc’ed non-connected node provider. Anything else would really depend if they did something illegal or not. Fraud is still fraud whether you are a node provide or not, it isn’t a get out of jail free card.
Every node provider should be welcoming this with open arms. These measures help ensure that they will continue to have an income stream (and hopefully they also care about the growth and strength of the IC network too!)
The cost of a KYC check should be easily manageable by someone who is proposing to be a node provider given the cost per machine and maintenance costs involved.
The thing to remember is that nobody is forcing anyone to be a node provider. If any of the current ones no longer feel like it is in their interests to continue, more people will step up.
As the IC scales, this becomes less and less of an issue as it will become increasingly difficult for anyone entity to make an impact. We (the collective we, the community) have to protect the IC while she grows.
As for how this will be enforced, there is one tool, that has already been forked. More will come. We have people like @EnzoPlayer0ne and @Lorimer right now but eventually we will have 100 of each of them and many many other people (maybe a few Chloe O’Briens). The goal here is not to victimise people, but to ensure that it is not profitable to be a bad actor. You can go do that on some other blockchain…
Anyway this isn’t directed at you @snoopy as you are obviously fresh to these forums and are probably a bit shell shocked and just trying to catch up.
The IC is full of very passionate, very clever people. We will never 100% agree on everything and that is as it should be. For now, I think we can agree that more needs to be done and that the powers that be are listening and we are moving in a positive direction.
3 Likes
I have also been thinking about what @Lerak said on the call. I agree saying that you will be KYC’ed every x years seems a pointless waste of money. Anyone that is doing shady shenanigans will know that they have to clean everything up 6 months or so before and it will just be a pointless exercise.
Maybe we need to think of some way to do a “secret shopper” concept. The formal KYC, which should not be a problem for existing NPs as if anything it sets the barrier higher for new people on boarding.
You guys are the pioneers, you should lead by example.
We are all here as we believe in the IC and want to support it as much as possible.
3 Likes
They all seem to have the same status: IC_Execution_LongRunningQueries
This is not a known error, if I had to bet, it’s probably not related to those nodes themselves, but rather some other error. One of mine also has this status, will check in Matrix channel if any advice on this.
1 Like
No point replying because I’ll just get my post flagged by the usual group.
I think the node providers are not happy about the new KYC rules! 
1 Like
I think it’s a temporary issue, I can see that all my nodes that are all in different subnets have “passed through” this status and then recovered back. They ping fine, don’t think there is anything wrong with the nodes themselves. Maybe Dfinity can shed some light on this later, but seems all nodes are recovering quite quickly.
1 Like
I linked this internally, multiple node providers already asked about this too. AFAIU (although I don’t understand much about this part of the stack) this is not something related to the nodes, more about how messages are executed. I’ll wait for experts to say if this is something to be concerned about, but I don’t expect it to be the case
1 Like
Y’all just watching our nodes more closely now 
Actually it can happen for several different reasons, everything from real hardware problems, internet routing issues, IC-OS upgrades causing intermittent problems, dashboard monitoring stack problems.
Sometimes it’s a cause local to our data centre, sometimes it’s wait for the DFINITY SRE team to identify a wider problem. It’s what the node provider Matrix chat channels are mainly for: boring technical problem identification and resolution.
But also why the monitoring and communications are (and should be) open for anyone to see and raise questions like you have 
2 Likes
Just us NPs flicking the lights on and off, seeing if anyone is paying attention
2 Likes
The new alert IC_Execution_LongRunningQueries was added by the execution team to identify nodes that are for some reason slower processing queries. I don’t have the exact details on how these nodes are flagged, and I’ve asked the execution team to look into it and comment on the forum.
1 Like
@tina23 @icarus after discussing with the execution team, we’ll disable the alert until we have a better plan how to handle such flagged nodes. So everything should go back to normal in a few minutes. Thanks for proactively reaching out for more information.
4 Likes
Thank you Sasha for the quick feedback!
2 Likes