Reevaluating Neuron Control Restrictions

The term “disbursement key” that is being referred to here, what exactly is its form? Is it similar to an encrypted Ethereum public/private key or is it just an authentication UI button like the same process when we log in to NNS ?

I still confuse, let’s use an example so I can visualize how the interaction would be like on NNS:

Example Case:
Through NNS, User A creates a new neuron and binds it with a disbursement key for 3 years. When the neuron dissolved in the third year and becomes eligible for disbursement, how will the process of disbursement exactly will work? Will it still be the same process as disbursing a neuron currently? Would it require entering the private key for disbursement, or will NNS automatically detect that the Internet Identity performing the disbursement is the one that create & own the disbursement key (meaning the user does not need to know or remember their private/disbursement keys, and everything is done automatically by NNS).

How about the process of claiming maturity ? does user always need to enter the disbursement key to claim maturity from a PoK bounded neuron ?

I believe this stems from a greater issue:

Can the disbursement key disperse maturity? If so, does it put the dispersement key and a sold II in a race to disperse maturity every time it gets over 1+maxmodulo?

Also what’s the reason the disbursement key is not required to interact with the neuron? A neuron that is managed with quill requires a PEM file. A neuron that is managed by Ledger requires the PIN / seed phrase.

A neuron that has a disbursement key but is not required to use it to perform functions weakens the link to the neuron don’t you think?

As I understand it, the “disbursement key” does not alter the neuron management process, nor does it affect the fund withdrawal process even after 8 years. Essentially, the “disbursement key” represents a psychological attack aimed at the potential buyer, suggesting that the seller might use it after 8 years to redirect all funds to their own address. The sole purpose is to deter people from buying neurons, as there is no 100% certainty of receiving the funds after 8 years.

3 Likes

Yes, that sums it up very nicely.

2 Likes

I would suggest to restrict the scope of the disbursement key only to disburse the ICP of a dissolve neuron (and potentially also to staked maturity).

1 Like

This seems to significantly nerf the deterrent. I’m much less willing to buy a neuron if I’m going to have a race to harvest maturity from a dishonest seller. The whole reason I’m buying the neuron is to get the maturity. (I’d imagine a bit would emerge to try to snipe, but I guess both sides can use one…then it is just a race)

In fact a much more significant deterrent might be to give it the rights to split. Then an attacker could cut he thing into a thousand pieces and the buyer would rarely ever get to harvest(although I guess they could combine back.

Basically you want the dishonest seller to be able to make the neuron inoperable for the buyer or I don’t think it is a deterrent at all.

2 Likes

I can confirm that @bjoernek is representing dfinity in this proposal.

4 Likes

Interesting points, let me think about this.

1 Like

By the way, when splitting a neuron, will the PoK/disbursement key be inherited by all pieces?

will the PoK/disbursement key be inherited by all pieces?

I suppose, there shouldn’t be a way from PoK to non-PoK.

A few extra questions for @bjoernek:

  • Is this an isolated feature, or could it be part of something larger?
  • What is the estimated development time for phases 2 and 3?

Thanks

@bjoernek mind responding to this?

If the disbursement key can only be used to disburse a fully dissolved neuron then it has no impact on people buying neurons who never intend on dissolving them. I’d happily buy an 8 year neuron at a discount regardless of if it has a disbursement key and just leave it locked and earning rewards.

3 Likes

This seems to solve it.

We could make every neuron have a permanent key which the controller can query for at any time (or maybe we’d need vetKeys so that the key never exists in the replica?) and which can be used when calling manage_neuron for any operation (it can’t be just for disburse for the reasons mentions in my previous post).

This way you can never fully trust a neuron which was previously owned by another user, destroying the demand for neuron markets.

This is simple for users, makes all neurons equal, requires no special behaviour from users to add PoK, and prevents neurons from being tradable.

This would also allow for the neuron’s controller to be changed since it could only ever change between principals owned by the same user. For example if I wanted to move a neuron from being controlled by my II to being controlled by a hardware wallet.

1 Like

Hmmm? I ask for a vetKey that the governance canister gives me and I upload my key encrypted with it. How does it know it what my key is so it can let me call network functions? You need a trusted party to produce the encrypted key and produce a pub key you can trust.

I think that is what PoK gives you with a different method. You can just prove you have the key. Well…isn’t that just a signature of some random data? Probably understanding the tech better would be helpful for me.

But it think you are on to the right idea. If there is a key that can’t be divested then it eliminates trading of neurons.

We get this easy for standard canisters principals. If it is a canister principal making the neuron, tie it to the self auth principal controllers forever. If it is controlled by a canister principal I think you have to have a dox list(known neurons, sufficiently decentralized SNSs, etc.)

Can the Tecdsa canister track produced keys so we know which keys are Tecdsa?

Maybe every neuron gets a Tecdsa key added to it from the NNS that has a write only allow list that every key that ever has access get added to and can always make a call through.

The negative here is that if your key is stolen there wouldn’t be much you could do.(maybe there is a NNS prop to report stolen keys)

When you add a key to II it goes in the allow list. Canister controllers (self authenticating) are added for canisters. Canisters controlling canister are tracked back through the chain until you get to a self auth principal or SNS, NNS, blackhole, or doxed org. (Can control chains be circular? Maybe these are the only ones that need a penalty) (canister control chains might grow exponentially…:thinking:)

1 Like

What if someone created a DApp called ‘Neuron Rental Market,’ where neuron owners could transfer their neurons to the dApp controlled-canister, then, renters who access the Neuron Rental Market DApp would have permission to use the voting power associated with those transferred neurons without needing to actually transfer ownership of the neuron between the owner and the renter. Instead, the DApp canister serves as the custody/intermediary. The renter does not care about disbursement or claiming maturity. They just want to use the voting power. Under this system, wouldn’t the disbursement keys lose all significance for protecting ICP governance security?

2 Likes

I still believe that, as long as the tokens are locked, it’s possible that the same guarantees hold regardless of the owner.

Also, I would expect good and bad neuron marketplaces to exist. Most users would choose to buy in good marketplaces, which might have safety measures like ‘an 8-year-old neuron can only be sold if it last voted 1 year ago’. Or maybe the market will price in these factors.

The precise amount of the penalty can be fine-tuned and maybe we can come up with some kind of formula instead of the flat 20% suggestion. I guess we should also consider that selling a neuron typically involves discount so there is an additional penalty applied by the market.

Regarding your other question I will get back to you later.

1 Like

If there is a logical connection to some other aspect of neuron management then it could be combined with something else (if this adds value). Do you have something specific in mind ?

Phase 2 (in the way it is currently defined) would not be a big change, from my perspective (but I did not review this with the NNS engineering team in detail yet). Hence I would assume that this could be done in a timely manner after phase 1, subject of course to prioritization compared to other things with respect to NNS/SNS.

Phase 3 would be a relatively big change. We just started the discussion of the high-level ideas and it will take probably take some time to define the detailed design (assuming we reach an agreement to go in this direction). Afterwards it would take certainly several months for implementation.

2 Likes