Threshold ECDSA Signatures

Roadmap
104

Great to know it is possible! Thanks for the quick reply.

1 Like
105

Status update:
We have set a new (aggressively timed) milestone for implementing the signing protocol creating ECDSA signatures and thereby consuming the quadruples we can compute already: December 22.
After that we need to “iron out” the shortcuts we still have in there in order to get towards the final protocol. We’ll keep you posted!

7 Likes
106

Hmm, nobody bit this bait, so maybe I should make it clearer:

With canisters performing ECDSA signatures, it will be possible for canisters to control neurons (with a little help to submit ingress messages signed by the canister), and thus make neurons transferable. I assume this is not a new observation to @dieter.sommer and the rest of the team, but I am curious what the consequences are. I can see four possible consequences; is is clear which way we are heading?

  1. The system somehow tries to recognize canister-owned ECDSA keys and will not allow them in ingress messages, to plug this hole.
  2. Accept that canisters can own neurons this way, but not do anything about. If people really want canister-own or transferable neurons, they’ll have to jump through these hoops.
  3. Remove the restriction that neuron owners can’t be canisters, because it can be worked around anyways, canisters can already own ICP, and it opens up interesting applications like autonomous neurons.
  4. Additionally, simply make neurons transferable, given that they can be transferred using this feature.
5 Likes
107

I am struggling with making the logical leap to the transfer functionality conceptually.

Given that canisters already can manage self-authenticating principals with ICPs in them , I suppose that it is (or would be) possible for canisters to create neurons through those principals and hence become owner of the neuron through the self authentication principals.

The controlling of the neuron; including disbursement; would be possible as well.

I get lost while thinking about the transfer functionality. Could you elaborate a little on what exactly is meant by a transfer?

2 Likes
108

What method are you thinking of here? Canister signatures as used by the Internet Identity? Yes, these lead to the same conclusions, once they are accepted from any subnet, not just the root subnet. This is not yet the case, as far as I know.

You can’t change the controller of a neuron; this is an intentional restriction related to long term incentives or accountability or something like that. But if you put a controlling canister in between, you can now easily transfer ownership of the canister (which is unrestricted and not tracked), thus circumvent the restriction.

2 Likes
109

Yes. We are still stuck here. https://github.com/dfinity/ic/blob/master/rs/certified_vars/src/lib.rs#L94-L96.

Either this restriction will be lifted OR the allow https calls. This restriction is easier in many perspectives to being amenable to being lifted, imo.

Thanks. That was the missing link for me.

1 Like
110

Hi. Just want to make sure I understand. It sounds like this would only work for new neurons created using a canister and not for existing neurons. Is that right?

111

Correct. (Existing neurons can be transferred as well, in away, if you find a way to transfer the controlling cryptographic key. Send the yubikey by mail. Let the receiver take over your Internet Identity. Somehow convince the receiver that you deleted all copies of the secret key. I guess it is just a matter of hassle…)

4 Likes
112

Update

We are close to reaching our milestone of having signature generation working end-to-end (with shortcuts in the implementation still being there) that has been scheduled for Dec 22. Most of the functionality for reaching this milestone is there, but the system API still needs to be hooked up so that canisters can make signing requests and responses can find their way back to canisters. As the holiday season starts now, milestone achievement will likely slip into the first week of the new year.

9 Likes
113

Could I request the foundation releases a means of verifying signatures with Motoko. Even outside of its intended use with Bitcoin this is an incredibly useful feature.

1 Like
114

Which signature schemes are you interested in?

115

Maybe Relevant with use cases for needing to verify signatures: Tackling CertifiedData in Motoko

116

Just having a Motoko lib capable of verifying the generated ECDSA signatures would be all I need.

117

FWIW, I definitely think that neuron transfer implications need to be explicitly addressed sooner rather than later, given that it sounds like neuron transfer will soon be possible.

Perhaps the most foundational concern (among a number) is that liquid democracy can be frustrated in a world with transferable neurons.

Neurons follow other neurons. So if a followed neuron is transferred, its followers end up following an entity they didn’t choose (the transferred neuron’s new controller). Neurons can be transferred without any record of the transfer. So how does liquid democracy work when followers can’t know that they’re following who they chose in the first place?

NNS voting today depends on liquid democracy. So IMHO, it’s critical to determine, at the very least, how liquid democracy will work when neurons soon become transferable.

@jwiegley and @johan, given that you are working on IC tokenomics and have previously alluded to the risks of neuron transfer, I would be interested in what may be in the works to address.

1 Like
118

Neuron transfer is inevitable. Liquid democracy != equal democracy. The more voting power one has the greater is the right to be heard. So if some neurons are bought by someone else, they will have greater voting power.

Also coming soon to a theater near you is the ability to self-borrow from your future self some percentage of your neuron’s present value; by temporarily suspending your internet identity linked to the neuron; repaying that loan through time. Think a model similar to Alchemy.

1 Like
119

Agreed: it sounds like neuron transfer is inevitable. Hence why its biggest risks need to be addressed.

The concern above isn’t about those more invested in the IC getting more VP.

The concern is that untracked neuron transfer (to a new neuron controller) means that follower neurons can end up following new neuron controllers they don’t want to. So the idea of liquid democracy as currently implemented breaks down.

120

Have to say I agree with this, although even with the ECDSA I don’t think it’s 100% secure. Who knows whether Dfinity will suspend the chain-key api in future or unavailable. However, even if Dfinity puts in blocks on using the ECDSA signatures then some other org/chain whatever with the technology will make it possible. It’s inevitable imo.

1 Like
121

The right to vote/follow whoever goes with the transfer. Just like the original owner can change whom to follow. How does this break down liquid democracy

122

The problem is that the neuron that is being followed can be transferred to a new (canister) controller without the follower’s knowledge. So the follower can’t be sure that they continue to follow who they chose to represent them initially.

If followers can’t trust that they’re following who they want to, then liquid democracy breaks down.

1 Like
123

Just because the terminology is cumbersome here, symbols may be helpful:

  • Neuron ‘A’ follows Neuron ‘B,’ staked by a canister controlled by Person ‘C’ - whom A’s controller trusts to represent her in NNS voting.
  • But without advertisement, C transfers canister control of Neuron B to Person ‘D’ - someone unknown to A’s controller.
  • A is now effectively following Person D, without A’s controller’s knowledge or choice.