Hi @bjoern, I’ve revisited this this morning and wanted to clarify something. I understand the plausibility of not knowing the key corresponding to the controller principal, but I do not see a way to verifiably prove this. Am I missing something?
Assume I’m a user looking for a nice decentralised community-controlled neuron to follow. How can I determine (and verify) that the neuron is a decentralised community neuron (without being a followee for topic 1)?
In an alternative scenario where I am a followee for topic 1 (so can see the principal), how can I verify that nobody knows the private key for that principal?
This is not really verifiable as no one can verify (in an absolute sense) that you don’t secretly know the private key to the public key that leads to the, e.g., all-zero hash. It’s just extremely unlikely that you do, and would contradict the security of the hash function. Choosing values like that is a common method used in cryptography standards, sometime referred to as “nothing up my sleeve” numbers/values. The output value of the hash function has to be plausibly independent of the hash function itself, so you could use the all-zero string or some bit sequence obtained from pi or e or something like that.
Currently, neuron information such as the controller and the following graph are generally only queryable for the controller or hotkeys associated with a neuron. This will change soon with the advent of public neurons.
Thanks @bjoern, but doesn’t this make the assumption that the creator of the neuron wants to be oblivious to the private key? This would be a pretty big assumption. Have I misunderstood something?
Couldn’t an unscrupulous individual just choose / construct a principal for which they do know the public/private keys, while claiming that they generated the principal programmatically (in the way described above)?
If such a neuron gained lots of followers due to being regarded as highly decentralised, with a high nakamoto coefficient, couldn’t the creator of that neuron just swoop in (perhaps picking their moment) and unilaterally highjack the VP of that following?
If you look at it more formally, and the output and the hash function are chosen independently, then the security of the hash function requires that it’s hard to find an input that corresponds to that output. Now we have the additional complication that the hash function H is already known, and one can trivially choose x and compute y = H(x) and use y as the targeted output of the hash function, knowing the input x. So after H is known, we cannot actually choose any y independently of H anymore. That’s why we have to go back to plausibility and heuristics – bad luck. But it’s widely accepted that for (non-degenerate…) hash functions, it’s plausible that no one knows the preimage of, for example, the all-zero bit string. So if you say y = 000000..., then you can plausibly claim that you do not know any x with H(x) = y. In order for this argument to make any sense, you of course have to choose y in such a very restricted and structured way. If you choose y uniformly at random, then you also don’t know the corresponding x, but likely no one will believe you.
So, in more detail, the underlying claim is: “I believe that no one knows a value x such that sha224(x)=0000000...” – I think this would widely be accepted, although it’s not strictly verifiable.
Thanks @bjoern, I think I understand now. It looks like I misinterpreted what that textual_encode method is doing. The principal itself appears to have high entropy to me →
You’re saying that we can validate that this principal is derived from a low entropy sequence (where the sequence represents a hash for which, I agree, the input could very reasonably be assumed unknown).
This means that the textual_encode method must be reversible. Given a principal (e.g. uduew-qycai-baeaq-caiba-eaqca-ibaea-qcaib-aeaqc-aibae-aqcai-bae) is there a utility anywhere for decoding this back to the byte sequence? It seems that this is what would be needed to validate the plausibility of the decentralisation claim (by observing the low entropy bytes).
As a side question, presumably this same technique can be used for creating canister-controlled neurons (not just community-controlled neurons)? I’m assuming you would just specify the canister principal in the step that I’ve quoted below.
I’ve not seen any documentation anywhere for the process to go through for setting up a canister-controlled neuron. If I’m off the mark with my assumption above, would you be able to point me in the right direction?
If you group the characters slightly differently, the textual sequence also starts to indicate lower-entropy as well, although admittedly still not as much:
Note that I only changed the position of the dashes.
There is a textual_decode method in the Principals section of the Interface Specification, which does exactly the inverse of textual_encode.
The described method for creating neurons can indeed be used for canister-controlled neurons as well, but it’s not necessary, as a canister-controlled neuron can be configured from the canister. In the case described in this post, the difficulty was that we (a) want the controller field to be plausibly void and (b) still need the specific NeuronManagement following to be configured in order to have decentralized control over the neuron. For canister-controlled neurons, you can thus also use the the ClaimOrRefresh flow that is used for creating neurons in the NNS front end or via quill.
