<p>Right now, the top two alternatives to Taproot &amp; Schnorr Signatures rely on multiparty ECDSA (elliptic curve digital signature algorithm) also known as threashold ECDSA.</p>
<p>Threshold ECDSA has two main functions: The first function is to spread out key generation across multiple machines. This makes it so that no single party is <em>ever</em> made aware of the full key. The second function is to sign a transaction with the key shares (generated in step 1) without needing to combine them in a single place. This allows a set of distinct parties (that do not trust each other and do not wish to reveal their PK to each other), to jointly compute a function over their inputs while keeping those inputs private.</p>
<p><a href="https://github.com/ZenGo-X/multi-party-ecdsa" rel="nofollow noreferrer">ZenGo</a>, is a Multi-party ECDSA written in Rust. It comes with two key features:</p>
<ul>
<li>Key Generation for creating secret shares.</li>
<li>Signing for using the secret shares to generate a signature.</li>
</ul>
<p><a href="https://github.com/binance-chain/tss-lib" rel="nofollow noreferrer">Binance Chain</a>, is a Multi-party threshold signature scheme that supports the first two features but also allows for Dynamic Regrouping of shares:</p>
<ul>
<li>Key Generation for creating secret shares with no trusted dealer (&quot;keygen&quot;).</li>
<li>Signing for using the secret shares to generate a signature (&quot;signing&quot;).</li>
<li>Dynamic Groups to change the group of participants while keeping the secret (&quot;resharing&quot;).</li>
</ul>
<p>Both libraries have been audited by Kudelski Security. Be warned, however, that both of these technologies are relatively &quot;new&quot; and may suffer from unknown bugs/security flaws. Use them at your own peril.</p>

CC BY-SA 4.0
2021-02-05T19:05:28.257Z
2021-02-05T19:46:21.260Z
2021-02-05T19:46:21.260Z
Design X
<p>In <a href="https://bitcoin.stackexchange.com/q/102007/78451">this question</a> I discussed how sharding a private key with <a href="https://bitcoin.stackexchange.com/a/44431/78451">Shamir's Secret Sharing Scheme</a> maybe a good alternative to MultiSig as a means of reducing excessive fees associated with MultiSig transactions. <a href="https://bitcoin.stackexchange.com/a/102008/78451">@Pieter Wuille</a> provided an excellent analysis of the pros and cons of using Sharding vs. MultiSig and revealed some of the work in progress aiming to address the main concern with sharding (the &quot;A Chain Only as Strong as Its Weakest Link&quot; problem).</p>
<p>As <a href="https://bitcoin.stackexchange.com/q/102007/78451">mentioned</a>, the main problem with employing SSS as an alternative to MultiSig is that it is necessary to reconstruct the actual secret key on a single machine before signing a transaction - once again making it vulnerable to a single point of failure (attack). As the saying goes &quot;a chain is only as strong as its weakest link&quot;.</p>
<p>While <a href="https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki" rel="nofollow noreferrer">Taproot</a> and <a href="https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki" rel="nofollow noreferrer">Schnorr signatures</a> were proposed as potential alternatives to SSS, these two solutions are for the time being just &quot;proposals&quot; and they will need to be accepted by the entire Bitcoin community (which could take forever) before they become viable alternatives.</p>
<p>Are there any alternatives to SSS, which can be used <em>right now</em>, where a transaction can be signed by two (or more) parties without needing the secret key to convene on one machine? Are there any alternatives to &quot;Shamir's Secret Sharing&quot; that might allow this functionality?</p>
<p>In case it makes a difference, all I need is n-of-n (i.e, 3-out-of-3) rather than k-of-n (i.e, 3-out-of-4 or 2-out-of-3).</p>
<p>Thanks</p>

CC BY-SA 4.0
2021-01-31T02:25:06.960Z
Yes, multiparty ECDSA exists. But it's many times more complicated than normal ECDSA.
Pieter Wuille
CC BY-SA 4.0
2021-01-31T03:35:43.973Z
If you need to ask "how to implement multiparty ECDSA", the answer is that you absolutely shouldn't. This sort of stuff should be done by people who know what they're doing.
Pieter Wuille
CC BY-SA 4.0
2021-02-01T13:26:32.293Z
@S.O.S You really shouldn't try to build your own crypto tools if you need to ask this kind of question here unless you really want to lose your money. It looks like people are working on it though so I would just wait it out.
ieatpizza
CC BY-SA 4.0
2021-02-03T17:00:50.833Z
Is there something wrong with the question that it was downvoted? I don't think it violates any rules on this site.. Please enlighten me.
S.O.S
CC BY-SA 4.0
2021-02-04T01:20:35.943Z
I didn't downvote, but note that downvoting does not mean any rules are violated (there are close votes and moderator flagging for that). It just means people think it's not a good question.
Pieter Wuille
<transactions><security><private-key><bitcoin-core-development><multi-signature>
Securing the "weakest link" of a chain through Sharding
S.O.S
# Securing the "weakest link" of a chain through Sharding

(Asked by: username_0 on 2021-01-31)

In [this question](https://bitcoin.stackexchange.com/q/102007/78451) I discussed how sharding a private key with [Shamir's Secret Sharing Scheme](https://bitcoin.stackexchange.com/a/44431/78451) maybe a good alternative to MultiSig as a means of reducing excessive fees associated with MultiSig transactions. [@username_1](https://bitcoin.stackexchange.com/a/102008/78451) provided an excellent analysis of the pros and cons of using Sharding vs. MultiSig and revealed some of the work in progress aiming to address the main concern with sharding (the "A Chain Only as Strong as Its Weakest Link" problem).

As [mentioned](https://bitcoin.stackexchange.com/q/102007/78451), the main problem with employing SSS as an alternative to MultiSig is that it is necessary to reconstruct the actual secret key on a single machine before signing a transaction - once again making it vulnerable to a single point of failure (attack). As the saying goes "a chain is only as strong as its weakest link".

While [Taproot](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki) and [Schnorr signatures](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki) were proposed as potential alternatives to SSS, these two solutions are for the time being just "proposals" and they will need to be accepted by the entire Bitcoin community (which could take forever) before they become viable alternatives.

Are there any alternatives to SSS, which can be used *right now*, where a transaction can be signed by two (or more) parties without needing the secret key to convene on one machine? Are there any alternatives to "Shamir's Secret Sharing" that might allow this functionality?

In case it makes a difference, all I need is n-of-n (i.e, 3-out-of-3) rather than k-of-n (i.e, 3-out-of-4 or 2-out-of-3).

Thanks

**Tags:** transactions, security, private-key, bitcoin-core-development, multi-signature

> **Comments:**
> **username_1**: Yes, multiparty ECDSA exists. But it's many times more complicated than normal ECDSA.  
> **username_1**: If you need to ask "how to implement multiparty ECDSA", the answer is that you absolutely shouldn't. This sort of stuff should be done by people who know what they're doing.  
> **username_2**: @username_0 You really shouldn't try to build your own crypto tools if you need to ask this kind of question here unless you really want to lose your money. It looks like people are working on it though so I would just wait it out.  
> **username_0**: Is there something wrong with the question that it was downvoted? I don't think it violates any rules on this site.. Please enlighten me.  
> **username_1**: I didn't downvote, but note that downvoting does not mean any rules are violated (there are close votes and moderator flagging for that). It just means people think it's not a good question.  

---

## 1 answers

### Answer by username_3 on 2021-02-05. Score: 1

Right now, the top two alternatives to Taproot & Schnorr Signatures rely on multiparty ECDSA (elliptic curve digital signature algorithm) also known as threashold ECDSA.

Threshold ECDSA has two main functions: The first function is to spread out key generation across multiple machines. This makes it so that no single party is *ever* made aware of the full key. The second function is to sign a transaction with the key shares (generated in step 1) without needing to combine them in a single place. This allows a set of distinct parties (that do not trust each other and do not wish to reveal their PK to each other), to jointly compute a function over their inputs while keeping those inputs private.

[ZenGo](https://github.com/ZenGo-X/multi-party-ecdsa), is a Multi-party ECDSA written in Rust. It comes with two key features:

* Key Generation for creating secret shares.
* Signing for using the secret shares to generate a signature.

[Binance Chain](https://github.com/binance-chain/tss-lib), is a Multi-party threshold signature scheme that supports the first two features but also allows for Dynamic Regrouping of shares:

* Key Generation for creating secret shares with no trusted dealer ("keygen").
* Signing for using the secret shares to generate a signature ("signing").
* Dynamic Groups to change the group of participants while keeping the secret ("resharing").

Both libraries have been audited by Kudelski Security. Be warned, however, that both of these technologies are relatively "new" and may suffer from unknown bugs/security flaws. Use them at your own peril.


---

