Signing Transactions with Threshold ECDSA and EdDSA

io.vault uses threshold signing to sign transactions. Let's walk through the process of signing a transaction in io.vault and broadcasting it to the blockchain.

Transaction Signing Flow

1. Transaction Request: A user initiates a transaction from the io.vault web dashboard, specifying the asset, amount, recipient, and any other fields as needed.

2. Signer Notification: io.vault notifies the vault's signing party of the pending transaction. Each signer receives the transaction details on their registered mobile device. In the case of server-side signing via our Virtual Signer , its policies will be run through API or Smart Contracts based on its settings.

3. Distributed Signature Generation: Each signer participates in a secure multi-party computation (MPC) protocol to generate a valid signature without revealing their individual key shares.

   • For Threshold ECDSA, signers jointly participate in:
     • Distributed nonce generation: Signers collectively generate a random nonce (k) through a secure protocol, rather than generating individual nonces.
     • Computing r = k * G (where G is the curve's base point) in a distributed manner.
     • Generating signature shares based on the message hash, collective nonce, and each signer's share of the private key.
     • The signature shares are not complete (r, s) pairs; they are mathematical contributions toward the final signature.
   • For Threshold EdDSA, the process involves:
     • Nonce generation: Using a derivation function that incorporates the message, each signer's key share, and some randomness.
     • Computing R = r * G collectively (where r is the joint nonce).
     • Generating signature shares based on the message hash, collective R value, and each signer's share of the private key.

4. Signature Aggregation: Once enough signers have provided their signature shares to meet the vault's threshold, io.vault combines these shares into a final, valid signature.

   • For Threshold ECDSA, this typically involves:
     • Using mathematical techniques such as Lagrange interpolation to reconstruct the final signature (r, s) from the signature shares.
     • This process ensures that the combined signature is valid under standard ECDSA verification rules.
   • For Threshold EdDSA, the aggregation involves:
     • Combining the individual R contributions to form the final R point.
     • Using secure computation techniques to derive the final s value.
     • Ensuring the resulting (R, s) pair is a valid EdDSA signature.

5. Transaction Broadcast: io.vault packages the signed transaction and broadcasts it to the appropriate blockchain network.

6. Blockchain Confirmation: The blockchain network's nodes verify the transaction signature and, if valid, include the transaction in a new block. Once the block is mined and confirmed, the transaction is considered complete.

Signature Verification

When a blockchain node receives a new transaction, it checks the validity of the signature before accepting the transaction into its mempool and propagating it to other nodes. The verification process differs slightly for ECDSA and EdDSA.

For ECDSA:

1. Compute the message hash (z)
2. Verify that the signature values r and s are within the valid range
3. Calculate u1 = z·s⁻¹ mod n and u2 = r·s⁻¹ mod n
4. Compute the point P = (u1 · G) + (u2 · Public_Key)
5. If the x-coordinate of P mod n equals r, the signature is valid

For EdDSA:

1. Compute the message hash
2. Calculate h = SHA512(R || Public_Key || Message)
3. Verify that (s · G) = R + (h · Public_Key) for Ed25519
4. If the equation holds, the signature is valid

If the verification checks pass, the node considers the signature valid and the transaction authentic. The transaction is then propagated by other nodes on the network. This process ensures that only transactions signed by authorized private keys are accepted into the blockchain.

Security Considerations in Threshold Signing

• Distributed Key Generation: Key shares are generated in a secure ceremony where no single party ever knows the complete private key.
• Communication Security: All communications between signers are encrypted and authenticated to prevent attacks.
• Nonce Management: Proper nonce generation is critical to security, especially for ECDSA where reusing or predicting nonces could leak the private key.
• Fault Tolerance: The threshold scheme ensures that the system can continue to operate even if some signers are unavailable, up to the predetermined threshold.

By leveraging threshold ECDSA and EdDSA schemes, io.vault ensures that transactions maintain the security properties of these signature algorithms while adding the benefits of distributed trust and fault tolerance. The resulting signature is indistinguishable from a signature generated with a single private key, maintaining compatibility with existing blockchain verification mechanisms while eliminating single points of failure.