Key resharing
Key resharing is the process that is executed when the number of parties in the TSS network is changed. It involves the whole ecosystem reconfiguration and funds migration to the new accounts. There are several steps that should be executed one by one to ensure the correct further system operation.
Steps
1. New key generation
To start with, the new general system public key and private shares must be generated by the new set of parties (excluding the old and including the new ones). All parties should agree on the keygen session identifier, start time and run the new keygen session. Additionally, the signing threshold should be set to the new value.
The keygen service mode should be configured to save the generated key share to the file system (through the command flag):
tss-svc service run keygen -o file --path share.json
It is necessary to save the previous key share as it will be used further in the resharing process. If the new share rewrote the old one, the Hashicorp Vault stores the previous version of the secret, so it can be restored. But the service configured to use the latest version of the secret, so you should manually save the newly generated secret and update the latest version of the secret with the previous one.
2. EVM networks reconfiguration [Administrator only]
2.1. Obtaining TSS Ethereum address
The new general system public key should be used to derive the Ethereum address for the TSS service. Address can be obtained by executing the TSS service CLI helper command to parse the Ethereum address from the provided EC point (pubkey). It can be found in the newly generated private share data.
- Parsing the Ethereum address from the public key points:
tss-svc helpers parse address-eth <x-cord> <y-cord>
2.2. Updating Ethereum bridge contracts
The Ethereum bridge contracts should be provided with the new TSS Ethereum address as the new data signer.
Bridge owner should execute the method addSigners to add the new TSS Ethereum address to the list of signers.
Additionally, the old signer address can be removed from the list of signers by executing the method removeSigners.
No additional contract upgrades or redeploys are required.
3. Bitcoin network reconfiguration
3.1. Obtaining TSS Bitcoin address
The new general system public key should be used to derive the Bitcoin address for the TSS service. Address can be obtained by executing the helper CLI command to parse the Bitcoin address from the provided EC point (pubkey). It can be found in the newly generated private share data.
- Parsing the Bitcoin address (P2PKH) rom the public key points:
tss-svc helpers parse address-btc <x-cord> <y-cord> --network testnet|mainnet
As the result, the new P2PKH address will be generated (based on the compressed public key)
3.2. Funds migration to the new TSS bitcoin account
Once the Bitcoin address was derived from the new general system public key, the funds should be migrated to it. Each TSS party should be configured with the new funds receiving address and be ready to start the service in Bitcoin resharing mode. Additionally, parties should agree on the max number of inputs to include for a single migration transaction and a tx commission rate before the resharing process wil be started.
tss-svc service run reshare bitcoin [chain-id] [target-address] --fee-rate <fee-rate> --max-inputs-count <max-inputs> --outputs-count <outputs-count>
If the total amount of UTXOs is greater than the maximum number of inputs, the Bitcoin resharing mode can and should be started several times until all the funds are migrated.
3.3 Wallet reconfiguration
After the funds migration transaction was sent to the network, the wallet should be reconfigured to track the new TSS bitcoin account. Signing party should remove the old address descriptor that corresponded to the old TSS bitcoin account and import the new one.
When importing new address descriptor, do not forget to use the compressed public key format, f.e. pkh(027356..00)#[hash]
Also, the wallet do not have to be fully rescanned, it is enough to rescan the history starting from the block when the
migration transaction was included in the blockchain to sync the new TSS bitcoin account balance.
4. Zano network reconfiguration
4.1. Obtaining compressed TSS public key
Compressed public key can be obtained by executing the helper cli command to parse the public key from the provided EC point (pubkey). It can be found in the newly generated private share data.
4.2. Updating assets' ownership
For each asset used in the TSS network, the owner_eth_pub_key field should be updated with the new public key.
Each TSS party should be configured with the asset id and the new owner public key,and be ready to start the service in Zano resharing mode.
The process of asset ownership update should be repeated for each asset used in the TSS network.
tss-svc service run reshare zano [asset-id] [new-owner-eth-pub-key]
- Parsing the public key info:
tss-svc helpers parse pubkey <x-cord> <y-cord>
5. Bridge module settings reconfiguration [Administrator only]
After the chains reconfiguration, the bridge module should be reconfigured with the new parameters.
5.1. Parties list update
The list of active signing parties should be updated with the new set of parties.
5.2. TSS Threshold update
The signing threshold should be updated with the new value, if it was changed during the resharing process.
5.3. Chains list update
Some EVM chains may require the new TSS Ethereum address of the signer (operator) to be set in the chain configuration.
Samples of the CLI commands to update the Bridge Core module settings can be found here.
6. TSS Vault secrets reconfiguration
After the key resharing process was completed, the TSS Vault share secret should be updated with the newly generated key share. The service helper CLI command can be used to update the secret with the new key share by providing the share file.
tss-svc helpers vault set tss-share [path-to-share-json]
7. Local TSS config file update
7.1. Parties list update
New/old parties configurations (party connection string, TLS certificate etc.) should be added/removed to/from the parties list.
7.2. TSS session update
The new TSS sessions start time should be configured to the new value. Additionally, if the signing threshold was changed, the new value should be set.
8. Run the TSS service
After all the steps were executed, the service can be started in signing mode to continue the operations processing.