Using Shamir Secret Sharing vs. Multi-sig

Although multi-sig is very secure in its approach, there are drawbacks to it.

• There is no standard implementation for multi-sig for different blockchains that support it. There are different implementations done by various organizations, some of them even close-sourced. Additionally, there are risks involved with on-chain protocol changes which should ideally remain unchanged.

• In a multi-party multi-sig setup, there is a loss of privacy around funds amongst its various co-signers. So if a user has a third-party multi-sig co-signer, they can easily track the funds which paint a target on the fund’s owners.

• There is support for multi-sig by only certain number of Blockchains currently. Multi-sig is not a universal solution and needs to be implemented for every Blockchain separately which reduces standardization. Additionally, they cannot be used for securing other digital assets like the SSH keys in a similar way.

• There are higher costs associated with a multi-sig transaction as compared to a transaction done through a single key.

• There is a limit to the number of co-signers that are possible in a multi-sig setup.

• It is much more complex to change schemes. For example, if you are using a 3 of 5 multi-sig setup and one of the private keys get compromised, you have to generate a new multi-sig address with a new private key and uncompromised private keys, fetch at least 3 out of 5 devices, make a transaction to send it to the new multi-sig address and then keep them again in remote locations.

Shamir Secret Sharing (SSS) allows us to split a secret into n parts such that with any m-out-of-n pieces you can reconstruct the original secret, but with only m-1 pieces, no information is exposed about the secret. This allows the user to set up a safety threshold of ‘m’ number of pieces required. The original secret is decoded by the owners after reaching threshold parts using Lagrange polynomial. Method-wise it is very similar to Multi-sig, but SSS is carried out off-chain whereas Multi-sig is completely implemented on-chain. In multi-sig, different private keys contribute towards generating a multi-sig address, whereas, in SSS, a single private key is sharded into multiple parts. To balance between accessibility and security, SSS is more preferred for individuals whereas multi-sig is preferred more for enterprises.

There are some advantages of SSS which makes it superior to multi-sig:

• Since the computation is done off-chain, hierarchical SSS can be implemented where SSS is applied on a cryptographic part itself. This enables multi-dimensional access control which is not possible in multi-sig. Due to an off-chain implementation, there is no risk of on-chain protocol changes.

• Since SSS can be applied to any sensitive information, unlike multi-sig, standardized implementation is possible for securing any sensitive information which is not just limited to Blockchain private keys, server root keys, PGP/GPG certificates, etc.

• Unlike multi-sig, SSS is Blockchain agnostic. The BIP39 seed phrase protection using SSS solved a single point of failure with private keys and allows securing any Blockchain private keys.

• There is no loss of privacy if the co-signers do not know the public key in SSS.

• Since the transaction is still carried out by a single private key, the transaction costs are comparatively lower.

• There is no practical limit to the number of shares that can be generated using SSS.

• It is comparatively far simpler to change schemes when using SSS. For example, if you are using a 3 out of 5 SSS setup and one of the shares get compromised, you just have to generate new shares of the private key and then keep them again in remote locations. No need to make any transactions.