A few weeks ago, we shared a blog post about the first ever Threshold Signatures Scheme (TSS) transaction. Today, we are open-sourcing the code to the community so that everyone can create such TSS transactions.
By using TSS, we remove the burden of having a single atomic private key and split the responsibility between multiple parties.
In this blog post, we at Zengo would like to share some details about this project, executed by our blockchain research team.
Threshold Signatures Scheme (TSS) removes the burden of the single atomic private key and splits the responsibility between multiple parties.
Anecdotally, the importance of splitting the control over multiple private keys was demonstrated by the recent incident concerning the Binance hot-wallet Bitcoin account. The address of this account is said to be controlled by a single key according to the tweet below. TSS is probably what the Tweet refers to as “Cutting-edge threshold ECDSA scheme.”
With TSS, each of the parties generates its own secret and then uses these secrets to distributively sign a transaction without revealing the secrets to the other parties. For a high-level overview of TSS, please refer to our blog post.
TSS happens in two stages:
We have invested significant resources in implementing TSS and making it generic and reusable for different kinds of blockchains. Finally, the investment is starting to pay off, as we can rapidly onboard and add TSS support to new blockchains.
At KZen we already implemented Threshold Signatures Scheme (TSS) support for Bitcoin and Ethereum within our wallet. We had also experimented with creating Proof-of-Concept (PoC) support for other coins (Binance, Zilliqa and more are coming soon)
We chose to elaborate on our PoC and create a developer-ready solution for BNB because of the following main reasons:
The Binance Network might be complex and innovative in many respects — it’s built on the Cosmos infrastructure and uses Tendermint consensus for Proof-of-Stake — but the beauty of TSS is that it is completely blockchain agnostic. TSS only modifies the client (wallet) to generate the transaction in a TSS manner. TSS does not need to know about the blockchain and the blockchain does not need to know about TSS. That’s what allowed us to complete this PoC in one day with no need for “integration” by the Binance team.
Using the aforementioned SDK, we first made sure we could generate a normal transaction. Next we modified the SDK in a crude manual manner to provide Proof-of-Concept for sending TSS transactions. Lastly, we properly integrated our TSS ECDSA library with the SDK to enable a polished way to generate a transaction. This is what we are announcing today.
We followed the following steps:
1. Generation: During the initialization phase, instead of generating and storing a private key entirely on the client side, we used the TSS setup phase. Next, the client and the server (the co-signer) generated a separate share of the master key (the key from which all wallet’s addresses can be derived) for each party, by performing the TSS two-party interactive protocol.
Of course, this part does not definitely prove that we successfully integrated TSS, as any random string can be converted into an address. The real challenge now is to sign a transaction from this address.
2. Signing: This part was a bit more challenging from an engineering point of view, as the original Binance SDK assumes a private key to be present and uses it for multiple functions (reminder – with TSS, there’s no private key). Fortunately, the SDK allows a consuming application to delegate signing to a custom function.
We used that feature so that our own, two-party signing protocol would be called to sign the transaction instead of the regular private-key based signing protocol.
In the demo below, the top side shows the Binance TSS server, while the bottom side displays a Binance TSS basic command line client that can generate addresses, read the balance, and send a BNB transaction. This transaction is jointly signed with the server using TSS. The resulting transaction is then shown using Binance’s explorer.
Our code is already open-source and can be viewed at here.
All in all, it was very rewarding for us to add TSS support to a relevant crypto asset. It only took us several working hours to create the initial PoC and a few more working days to make it developer-ready by leveraging our previous experience with generic TSS infrastructure.
Our work with TSS is not done. We plan to continue to extend this project in the future to integrate with other Binance operations related to their developing Decentralized Exchange (DEX). We will also continue to bring TSS to other chains and coins.
We just added support for BNB. You can now store BNB in your Zengo wallet.