Threshold ECDSA Signatures


The feature is code complete now and we are finishing up the documentation and still need to perform some stress testing in order to make sure everything works as intended when being run on IC Mainnet as well as some benchmarking on Mainnet to get an understanding of the performance of the feature on a 13-node subnet on Mainnet.

We are very close to making the feature available for the general public with a threshold ECDSA test key to be used only for testing purposes.


Excuse me, Can you explain how threshold ECDSA works in solving the problem of on decentralized DNS and decentralized certificate authority?

1 Like

Thank @bjoerntm very much for your patient and detailed help in your busy schedule!

Threshold ECDSA Beta released! :rocket:

The threshold ECDSA Beta release, being a key part of the Bitcoin Testnet release, has been officially announced!

You can now use threshold ECDSA on the IC with a test key. Please note that the test key may be deleted at some point, so it is not advisable to store any value with this key. The test key of the current deployment is intended solely for development and testing purposes, e.g., to hold bitcoin on Bitcoin Testnet.


Sample dApp:

The team is now working mainly on further performance improvements and another security review as there have been quite some changes since the first one.

Have fun!


For the non-technical like me, came across this list so folks can see what the IC can easily integrate with using ECDSA.


Nice list, thanks for sharing! Shows there’s huge potential of this feature and a huge amount of work if we want to unleash all of that. :wink:


There’s a couple of things that need to be done now to be ready for a mainnet release. The below ones are the main open areas where we will spend most of the engineering time. We can expect 2-3 months until we can release, but this is a rough indication, please do not use this as a firm release date.

One of the big items here is to increase our assurance of correctness of the implementation. We have already done one external round of code reviews with a world-leading code audit company. We are planning to do another round when the changes that we still want to implement are complete. This will be again with a top-notch external review firm. Review reports will most likely be published. And of course we will be doing lots of testing on our own. For a feature like threshold ECDSA, which will protect large amounts of value, such efforts for quality assurance are crucial to ensure that the chance of security issues and thus the risk of value being lost is reduced to an acceptably tiny value.

In addition to these assurance-related efforts, we still need to work on improving the performance of the implementation. We are currently running the system with the test key on a 13-node subnet. For the production key, we decided to start with a 34-node subnet for the security / decentralization we want to have. This has a major implication on performance, i.e., it will be quite a bit slower there. In order to reach, what we think is an acceptable level of performance, we need to put some more thinking and engineering effort into getting good-enough performance on such larger subnet.

We will keep you posted on the progress!

B.t.w., user @flyq from our community has (against all warnings) already taken the risk to perform a Bitcoin mainnet transaction with the threshold ECDSA test key. After manually crafting a bitcoin transaction to transfer the funds his canister has received back out of the IC again, no Bitcoin was lost and this was the first successful threshold ECDSA-based Bitcoin Mainnet transaction roundtrip on the IC ever! Congratulations! :slight_smile:

The warning still applies to not attach any value to the current t-ECDSA test key. Any experiments are at your own risk if you choose to ignore this warning.


So we’re looking at around November 2022 now? This is a big change in timeline compared to what we’ve all been told so far, is the 2-3 month timeline based on a new assessment?


Do I need to enable something in the local replica to use this feature? I’m getting “No route to canister aaaaa-aa” when calling ecdsa_public_key

Indeed, this is very much a pity and I want to apologize for the inconvenience, but here are two key reasons why we cannot release the GA version now:

  • We need to get performance to an acceptable level for 34-node or larger subnets. We can currently do 1.5 signatures/s on a 13-node subnet and performance decreases faster than linear with the replication factors. Thus, engineering has to solve some challenge here which does take some time. The performance was impossible to assess upfront, therefore this is a new work item that we could not plan for in any way.
  • We need another security audit, which must be done on a final version of the code, if there are too many changes after it, it’s meaningless.
  • We need to do further testing and reviewing the code ourselves in order to make sure things are as they should be.

If we would release a production key now, it would make moving ahead with optimizations much harder or impossible for the case that optimizations change certain aspects of the protocol. And we cannot start the security review before the code is stable after the optimizations, as otherwise the review would be rather worthless.

Regarding the security-related items, let me quote @mparikh’s comment from the Bitcoin thread:

In this game, “only the paranoid survive”.

How true, we must not take a risk here and release prematurely without the assurance steps we have in mind. Secure must be a top priority for a cryptographic feature like this one.

And w.r.t. performance, we would like to at least get close to 1 signature per second on the large subnet, which would likely be good enough for a first GA release.

Hope this explains a little better why we must do some more work before releasing the feature for production.


Do you have the latest SDK installed? Seems like you might be on an older version that does not have the feature (auto-)enabled yet. On the latest SDK in should just work (it is always enabled).

Wow…that is slower than I expected :grimacing: …while acknowledging that you’re doing something amazing, difficult, and novel, what kind of costs are we expecting to call this function? Seems like it could be expensive and might restrict its usage.

It looks like currently, we’re looking at using the system subnet to do these…do we expect it to scale horizontally eventually where we can add more t-ecdsa-specific subnets to enable lots of sig/sec?


Oh yes I agree this should all be done, I’m just hoping the great increase in time limit was indeed unforeseen.


Performance wise, this is just where you get with this complex kind of protocols. However, the crypto and consensus teams are now spending lots of effort on increasing performance, looking, for example, at measures such as batch verification for artifacts used in the protocol. We are confident to be able to bring this to an acceptable level of performance, but that is what takes time.

We will deploy the production release initially on one 34-node signing subnet and the NNS for key backup.

A scale-out architecture by using k signing subnets is supported by most parts of the architecture already. What would be missing in case we want to enable that in the future, is a deterministic load balancing algorithm in the message routing layer so that signing requests can be transparently dispatched to a signing subnet.


Yes, it was! We could not anticipate what the performance of the protocol would be in practice. It comprises so many parts that it was completely infeasible to estimate this from the protocol specification accurately. Once we were running it first with all sub-features enabled on actual subnets, we realized that we will need to spend quite some effort in optimizing the performance of the protocol.


@dieter.sommer i was not aware of the rationale myself so thank you in explaining it simply enough I can follow (i am by far not in any capacity to opine on Crypto protocols), but I can follow the surprises of performance.

Fwiw, I am grateful to @lastmjs and @skilesare in diving deeper to help us reveal the thinking and memorialize it for others reading this thread.


Thanks for your great work, what you are Achieving is brilliant


what kind of costs are we expecting to call this function?

I think in the order of 10B cycles, but of course it depends on how much performance we can get.

do we expect it to scale horizontally eventually where we can add more t-ecdsa-specific subnets to enable lots of sig/sec?



Does 1 sig/s mean it can only do 1 tps?

Yes. But if demand is higher than this, we can scale out linearly using more signing subnets.

Most of the Bitcoin use on the IC may be anyway through the upcoming ckBTC, i.e., fully on chain on the IC. Only settlement transactions would need to go to the Bitcoin network.

B.t.w., I would be really happy to see 1 trx / sec on the Bitcoin network coming from the IC, that would be around 10% considering the max trx throughput on the Bitcoin network of around 7-10 trx/s. That would be the ultimate success for this feature! :rocket:


It looks like eth evm transactions need “v” in the transaction that specifies which point was used. I see how to get r and s, but what would v be? Is it always the same? Is it per curve?

sign_with_ecdsa: This method returns a new ECDSA signature of the given message_hash that can be separately verified against a derived ECDSA public key. This public key can be obtained by calling ecdsa_public_key with the caller’s canister_id, and the same derivation_path and key_id used here.
The signatures are encoded as the concatenation of the SEC1 encodings of the two values r and s. For curve secp256k1, this corresponds to 32-byte big-endian encoding.

Edit: Looks like you get it from r:

Once we have valid values for r and s , the last piece of the signature is v . This value allows you to calculate the public key from a transaction signature. There are a couple of different ways to derive this, but for our purposes, we’ll just use 37 if r is even and 38 if r is odd, as this follows EIP-155.