Progress update:
The crypto and consensus engineering teams are currently intensively working on the milestone of a first integration between consensus and the cryptographic primitives to generate the 4-tuples required for threshold ECDSA signatures. This is the core of the implementation of the actual threshold signing protocol and not a particularly easy implementation task. We have set a (very, very aggressive) deadline at the end of the coming week for this milestone. We have been making good progress so far, but thereâs still a lot of work to be done to accomplish it. Weâll keep you posted on the progress at the end of next week.
5 Likes
Progress update:
We have made good progress towards the abovementioned milestone for Nov 20, however, we are not fully there yet. We hope to reach the milestone by next week and show the quadruple generation in an internal demo.
7 Likes
This is super interesting⌠hopefully the canister API that will be exposed will be low-level enough to enable signing of any kind of UTXO spending condition? If it will support all the Bitcoin Script op codes, this will make BTC canisters just as flexible as ETH contracts
2 Likes
The API of threshold ECDSA that will be exposed to canisters will be a signing API which you can make use of for any use case you intend, be it Bitcoin or something else. The Bitcoin API allows for obtaining the UTXO set for a specific Bitcoin address and to submit Bitcoin transactions.
4 Likes
This would be awesome; I can imagine an open source canister that is a virtual multi-chain wallet;
I can see ECDSA is used on many of the top-100 cryptocurrencies ( Cryptography behind the top 100 cryptocurrencies )
4 Likes
Exactly, a general threshold signing API is the foundation for a large number of cool use cases that anybody in the community can implement solutions for.
4 Likes
Great table, thanks for sharing. I think they should update that table. They are missing a very important blockchain platform on there.
This is a dumb question, but my understanding is that the IC first and foremost uses BLS signatures.
But here in the interface spec it says that Ed25519 and certain types of ECDSA signatures are also supported. Are these signatures used in different contexts than the BLS signatures?
Ed25519 and ECDSA are supported as the signatures from users on ingress messages, i.e. incoming signatures. BLS is used for signatures produced by the system.
1 Like
-
How complex would it be to implement Threshold EdDSA Signatures? As itâs the second signature algorithm used by top 100 (incl. IC for ingress messages);
-
Could canister sends ingress-messages to other canisters? (so a virtual wallet calling another canister)
It could certainly sign such messages, but I think youâd still need an external (untrusted) service that takes the message from the canister and feeds it into the IC.
With that, the Internet Computer has even solved the problem of making secret keys transferrable: you can now transfer control of such keys via canisters! I wonder if that is a first out there? Or are there other decentralized services that offer ECDSA threshold signatures?
(Amusingly, it renders attempts to prevent canisters from holding ICPs or to prevent neurons from being transferrable more or less futile.)
3 Likes
So that a future DeFi SmartContractDAO could give you back a percentage of ICP held in your neuron (assuming that the neuron is a staking neuron) as a loan till the loan is repaid through the rewards earned in the neuron? Many assumptions would of course need to be baked in.
I donât think anyone out there provide this kind of tech to developers; Itâs usually more a core component of some protocol (ThorchainâŚ);
Adding some threshold encryption as a next step would allow to build not only a wallet; but a virtual decentralized KMS/HSM; (signature & encryption);
4 Likes
Milestone accomplished! 
The milestone of having an integration of the consensus functionality and cryptographic primitives for the presigning protocol has been reached this week. In addition to what has been originally planned for the milestone, encryption has been implemented already for this milestone. Presigning is the most complex part of the implementation of the threshold ECDSA feature and is working now end to end with some shortcuts that we still need to âiron outâ.
Paul from our consensus team has given an internal demo of this on Wednesday in our company-wide team meeting. To make the presigning more tangible, the functionality has been visualized via a Grafana dashboard showing metrics related to the computation of the quadruples via DKGs on a size-4 subnet. These operations are executed besides the regular subnet operation to fill up a pool of quadruples to be consumed by instances of the threshold ECDSA signing protocol. See the screenshot from the internal demo session for the visualization: You can see the quantities of various related operations and the actual number of quadruples (limited to 8 for this test) in the pool.
We have, as mentioned previously, taken some âshortcutsâ in the implementation to get the core of the protocol working end to end. For those shortcuts we still need to implement the full functionality which will be done once the signing protocol has been implemented.
The next upcoming milestone is the implementation of the signing protocol that consumes a quadruple generated in the presigning protocol for each threshold ECDSA signature. It is simpler than the presigning protocol and is being worked on right now.
This has been a great joint effort of multiple dedicated teams and its nice to see how everything has come together after lots of hard work!
14 Likes
When users want to transfer their btc to ic, they transfer btc to a btc address controlled by a canister, but how do they tell ic their principal id or need to use the transferred btc address to generate a signature?
Hi all, now that Taproot is activated, would it be possible to use schnorr signatures?
And if so, could we then use Frost?
Taproot and threshold Schnorr signatures could be a next step after threshold ECDSA, but thereâs no firm decision on this yet. When implementing threshold Schnorr, we can definitely leverage synergies from the work on threshold ECDSA, however, we still would need to define the protocol specification incl. a key derivation scheme, proof it secure, create a system design (lots of synergies) and implement it. So this is not something that can be done quickly.
Threshold ECDSA will also have other use cases, e.g., letting the IC act as a CA to issue security certificates in a decentralized manner, so we want to get it done anyway.
So, the plan is to get threshold ECDSA out and then think about Taproot and threshold Schnorr if this fits the priorities.
Regarding FROST, I have not had the time to look into it and do not know whether it would fit our requirements in terms of threshold etc. At least the key derivation scheme we require for our setting to derive canister keys and further keys per canister would need to be added to the protocol I think.
Maybe @victorshoup can give you a response on the viability of FROST. In case it would fit our needs, the integration in consensus would be a decent-sized project that we could only launch after completing threshold ECDSA.
Hope that answers your question sufficiently.
6 Likes
Iâll repeat the question because I donât think it got an answer yet. Is EdDsa on the agenda or is there something in chain key tech that makes it more difficult or impossible?
Use case: Investors/Projects question the IC and ask why we donât integrate with other chains. We get to counter that soon âall the chains will be IC chainsâ and we explain the ECDSA techâŚeveryone gets excited once they understanâŚbut Solona, Cardano, Monero, and a few others use EdDSA and then our friends are sad again. It would be nice to tell them the same story even if they have to wait a bit longer than the ECDSA chains.
3 Likes
Our current target is threshold ECDSA, so thatâs what we focus on right now. Once threshold ECDSA is available, threshold Schnorr / EdDSA (which is essentially Schnorr) should be relatively simple, I imagine we could reuse a lot of the work weâre doing for ECDSA now. But I donât think itâs clear how this would be prioritize against all the other plans, so I wouldnât want to make claims wrt a possible timeline.
11 Likes