Skip to content

TSS.md

Latest commit

 

History

History
136 lines (104 loc) · 4.37 KB

TSS.md

File metadata and controls

136 lines (104 loc) · 4.37 KB
Raw

DKG

This document explains the specs for the client implementation of distributed key generation (DKG) for the threshold signature scheme (TSS). This logic is mostly abstracted away by the TssKeyGen class in bitcore-wallet-client/lib/tsskey.ts.

Asynchronous DKG

If the DKG ceremony is executed asynchronously (meaning all parties are not online at the same time during the DKG), the keyGen.export() function should be used between each step to export the local session state. The session state should be securely stored and used with KeyGen.restore() for following steps. See the exportSession() and restoreSession() methods in bitcore-wallet-client/lib/tsskey.ts for a reference.

Flow Diagram

DKG Flow

API Spec

POST /v1/tss/keygen/:id

Initialize the KeyGen class with a seed that is the derived private key.

E.g.: given your HD master key, derive an Ethereum key along the Ethereum standard path m/44'/60'/0'/<index>. The resulting private key will be the seed for the KeyGen class.

If you are creating a session, your partyId should be 0.

If you are joining a session, the join code should have your partyId.

Request body:

{
  message: object, // Message object from the TSS keygen initJoin() or nextRound() methods
  n?: number, // Number of participants. Only provided by party 0 when initiating the session
  password?: string // Optional join password set by party 0 when initiating the session
}

Response body:

None
GET /v1/tss/keygen/:id/:round

Request body:

None

Response body:

{
  messages?: Array, // Array of P2P or Broadcast messages ready to be given to the TSS keygen nextRound() method. Only given if ALL other-party messages are posted
  publicKey?: string, // The resulting public key at the end of the session
  hasKeyBackup?: boolean // Indicates if this party's encrypted key share has been backed up to the server
}
POST /v1/tss/keygen/:id/store

Request body:

{
  publicKey?: string, // The resulting public key 
  encryptedKeyChain?: string, // Your encrypted key share
}

THIS IS A SUB-OPTIMAL ENDPOINT. We do NOT want users to be dependent on our servers for recovering their funds. However, this is a stop-gap until we have DKG recovery implemented.

Response body:

None

DSG

This document explains the specs for the client implementation of distributed signature generation (DSG) for the threshold signature scheme (TSS). This logic is mostly abstracted away by the TssSign class in bitcore-wallet-client/lib/tsssign.ts.

Asynchronous DSG

If the DSG ceremony is executed asynchronously (meaning all signing parties are not required to be online at the same time during the DSG), the sign.export() function should be used between each step to export the local session state. The session state should be securely stored and used with Sign.restore() for following steps.

Flow Diagram

DSG Flow

API Spec

POST /v1/tss/sign/:id

Request body:

{
  message: object // Message object from the TSS sign initJoin() or nextRound() methods
}

Response body:

None
GET /v1/tss/sign/:id/:round

Request body:

None

Response body:

{
  messages?: Array, // Array of P2P or Broadcast messages ready to be given to the TSS keygen nextRound() method. Only given if ALL other-party messages are posted
  signature?: // The resulting signature at the end of the session. The existence indicates the session has ended
}
POST /v1/tss/sign/:id/store

Request body:

{
  signature?: string, // Provided after the final round
}

Response body:

None