Threshold signature computing

0

I have two questions:

1. Can someone point me to some solution providing multi-party {t,n}-threshold ECDSA?
2. I imagine that such a scheme works first by creating an ECDSA private key then sharding it to n subkeys, t of which subkeys are required to generate the initial ECDSA private key. Am I right?

I would appreciate any feedback on this topic as I am trying to wrap my head around such systems.

Thank you!

One such proposed method is given in this paper

The performance data given in the paper doesn't look that bad - obviously, no where close to how fast you can sign with a nonthreshold implementation, but it should be fast enough for, say, generating a signature for a bitcoin wallet. The problem is the internal modular inversion operation, much messes up simple approaches. It is far simpler with schemes like EdDSA or Schnorr's. However, if you have to operation with an existing protocol which already uses ECDSA, well, that's of little help.

1. There is a very recent paper that refers to earlier results: https://eprint.iacr.org/2023/765.pdf

   They claimed that "only (t−1)·59.7 KiB to be sent" which sounds quite efficient.

2. The desired threshold signature (such as the above paper) is stronger than you described. The stronger security is that $t$ parties (or more) jointly compute the signature (in a distributed protocol) but the subkey of each party remains secret. Similar to the standard signature, the signing can be repeated many times. In contrast, if revealing subkeys as you suggested, then every party is able to sign any message after that, and hence the threshold security is lost.