New Node Provider Proposals

[Block23Finance]

Thank you for spotting, updated

[Lorimer]

@Lorimer

Do you mind if I ask what the arrangement has been between you and BDL for acquiring those nodes. Have you purchased them from BDL, or is there another sort of agreement?

Hey @roald-av8, do you mind if I chase you on this?

[roald-av8]

Yeah, I’m unable to comment on this as the terms are subject to a non-disclosure agreement

[Lorimer]

Thanks @roald-av8, this is interesting. I appreciate what you’re saying. I’m unfamiliar with what the motivations for such a non-disclosure agreement might be. Are you able to point to any other occasions where the terms of a node transfer between parties was subject to a non-disclosure agreement? Or are you able to provide a couple of reasons why there would be a legitimate/justifiable need for such an agreement? (I can’t think of any)

[timk11]

Proposal 135210 | Tim - CodeGov

Vote: Adopt

This proposal sets rewardable_nodes for node operator dvfhx to 24. As seen in the dashboard for the relevant node provider, Uvaca Labs LLC, there are 24 nodes registered for this node operator ID. The proposal is in keeping with the steps outlined earlier in this thread for onboarding of excess Gen1 node machines that are handed over to another node provider.

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 topics and Synapse on most other 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 and KongSwap with a known neuron and credible Followees.

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

[Lorimer]

@Lorimer

Or are you able to provide a couple of reasons why there would be a legitimate/justifiable need for such an agreement? (I can’t think of any)

Hi @timk11, @LaCosta, @ZackDS, @louisevelayo - did you come across this caveat during your onboarding reviews? Is it standard for there to be non-disclosure agreements of this sort? Surely this significantly limits the verifiability of NP independence. Has there been any prior guidance from anywhere about how to handle these sorts of situations?

[roald-av8]

Hi @Lorimer, I’m not sure if this helps, but in my experience it’s fairly standard for commercial agreements between businesses to include non-disclosure/confidentiality clauses. They’re typically part of the data center colocation and ISP contract terms I receive.

[kristamehr]

Hi everyone, I’m Krista from 100 Count Holdings and I will be taking over the operations of the nodes for CH3 data center, previously owned by the node provider MI Servers. For more details of the handover, please see this post:

Proposal: Update Interim Gen-1 Node Provider Remuneration After 48 months

Hi all, Please find the information regarding the excess nodes that will be transferred to the new Node Provider: 100 Count Holdings, LLC The signed handover statement, containing the same information as below, can be found here. 28 node machines will be transferred from Existing Node Provider (MI Servers, LLC) to the New Node Provider (100 Count Holdings, LLC). The following details outline the specifics of this transfer: Data Center Location: The 28 excess node machines will be operated …

In the coming days, I will submit my proposal to register my principal as my node provider ID.

Thanks, Krista

[ZackDS]

Proposal #135172 & #135186 #135199 — Zack | CodeGov

Vote: Adopted

Reason:

Adds Node Provider: 0X52 , Reist Telecom and BlockFinance in line with forum intro and the required documents uploaded to the wiki and matching hashes for “The self-declaration” and “The proof of identity”.

About CodeGov (click to expand).

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 topics and Synapse on most other 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 and KongSwap with a known neuron and credible Followees.


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

[ZackDS]

Hey Alex as far as I know there were no such issues, for the NP’s that won the auction we had confirmation from Dfinity and before that there was the requirement of having an invoice for the purchased hardware uploaded to the wiki, and now we have the “handover declaration” document from one NP to another. They are only self declarations and could very well include Non Disclosure clauses (on additional pages that are not required to be uploaded). as there are indeed many DC’s that require one, depending on the location and number of hardware units, racks rented, bandwidth usage, power draw and so on) they enforce mainly the different prices given to different entities.
So based on this, there should be no compliance issues by not disclosing the full event in my opinion. Not sure this helps answer your doubts about this NP or in general.

[Lorimer]

Thanks @ZackDS, thanks @roald-av8, the thing about non-disclosure agreements is that they’re designed to keep information hidden. Why is there a need to hide the terms of a node transfer? I’m still unclear on this. If it’s common, the reasoning must be well established.

Another aspect of non-disclosure agreements is that they make a transaction conditonal. What would be the repercussions of violating the terms of a non-disclosure agreement? Repossession of the node?

[ZackDS]

Hey again, I’m not sure I fully understand your perspective on this, I might be missing the bigger picture. I was initially thinking about possible “rental arrangements” for a NP’s excess nodes, but that shouldn’t be an issue if they’re in the same data center and already under contract.

As mentioned before, having multiple NO IDs, including the NP’s, adds complexity to what seems like a simple matter, but it’s a necessary and well-considered one. On one hand, there’s the stance of “no more NPs until further notice” (to put it simply), while on the other, there’s the argument for allowing new ones, whether by auctioning excess nodes or reallocating them to other parties. That debate is valid, but in my opinion, nodes operating in previously used DCs shouldn’t be a concern if they’re redistributed among other NPs. Adding them to subnets using the DRE tooling usually gets the job done.

That said, we have to consider the challenges of HSM-less redeployment and the limitations on the number of nodes per entity, which may not be the best approach for decentralization. Just my 2 cents!

[Lorimer]

I’m sorry, but I don’t get what you’re saying…

• Why is there a need to hide the terms of a node transfer?
• What would be the repercussions of violating the terms of a non-disclosure agreement?

[ZackDS]

Ok looking at the other side what benefit would bring disclosing such terms, since there is a “handover” document from a legit NP that we can check for excess nodes, to another “legit” entity that provided documentation as requested ? Would anyone care if X number of nodes were sold at half of the let’s say acquired price for eg. ?

As for second it may lead to “termination of contract” with one DC for eg. that could bring available nodes offline until further relocation is one I could think of.

[Lorimer]

@ZackDS

Ok looking at the other side what benefit would bring disclosing such terms

If you don’t know the terms of the transfer, you don’t know that a meaningful transfer has actually occurred. Have you heard of asset protection?

[ZackDS]

I’ll leave this up up the Dfinity team to answer, TL;DR I don’t see any harm done here by @roald-av8 that complied to the usual request when submitting a correct proposal.

[Lorimer]

@ZackDS

I don’t see any harm done here

You won’t see things that you don’t look for

@timk11, @LaCosta, do you guys know why there would be a justifiable need to hide the terms of a node transfer, and what are your thoughts about what that means for verifying the scope/permanence of the transfer?

[louisevelayo]

Proposal #135264 — Louise | Aviate Labs

Vote: ADOPT
Review
This proposal registers a new NP 100 Count Holdings, LLC.

• Forum Introduction
• Self-Declaration, Proof of Identity and Signed Node Handover documents are on the wiki, and a link is provided in the list of self declarations.
• Hashes mentioned in the proposal match what is on the wiki and what I have computed locally. The same is true for the node handover statement which is not part of the proposal (and is not a requirement), but is on the self declaration page of 100 Count Holdings, LLC.
• 100 Count Holdings, LLC entity is registered in the Wyoming registry of businesses and enterprises

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, our team—Roald, Louise, and Quint—reviews and votes independently on ‘Node Admin’ and ‘Participant Management’ proposals. Currently we don’t vote at all on other proposals.

The Aviate Labs known neuron is configured to follow our team 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.

[timk11]

Proposal 135245 | Tim - CodeGov

Vote: Adopt

This proposal adds a new node operator ID for node provider Reist Telecom AG. The addition of the new node operator ID is consistent with the processes outlined in the current thread for reconfiguring existing Gen-1 nodes under the new remuneration structure. This NP currently does not have any registered nodes, but will have 28 once the nodes in data centre ZH5 are handed over from Sygnum Bank, consistent with the agreed maximum of 42, the statement of intent here and the handover statement here.

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 topics and Synapse on most other 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 and KongSwap with a known neuron and credible Followees.

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

[timk11]

Proposal 135260 | Tim - CodeGov

Vote: Adopt

This proposal adds a new node operator ID for node provider 0X52. The addition of the new node operator ID is consistent with the processes outlined in the current thread for reconfiguring existing Gen-1 nodes under the new remuneration structure. This NP currently does not have any registered nodes, but will have 28 once the nodes in data centre TO1 (currently 26) are handed over from Blockchain Development Labs, consistent with the agreed maximum of 42, the statement of intent here and the handover statement here.

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 topics and Synapse on most other 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 and KongSwap with a known neuron and credible Followees.

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