Skip to content

Validator Set Multi Sig Bitcoin Wallet: Wallet Creation and Transaction Coordination Design

Jump to bottom
Itamar Rogel edited this page Sep 14, 2018 · 2 revisions

Current Plan For Multi-Sig Coordination

Basics

The master address will be a m-n multisig address with, where n is the number of validators and m is the number of required sigs. Defaults: m = 10, n = 11.

Our goal with Cosmic Bridge is to preserve Tendermint's fault tolerance assurances with regard to the use of Bitcoin funds deposited to the payment zone, and potentially strengthen it. This can be be controlled with the choice of m and n for the multisig wallet. Since the likely scenarios for Cosmic Bridge are those of a tightly controlled validator set and we're dealing with sensitive funds, we are fine with validator failures (even under 1/3) causing delayed bitcoin transactions, but we are not fine with such failures enabling fraudulent transactions, and hence the selection of the defaults for m and n.

Detailed Flow

At any point in time, the master address is part of the blockchain state.

Address generation is triggered by one of these situations:

  • The master address being at an invalid state (that's the case when the blockchain is empty - e.g. it's a new payment zone)
  • A change has happened in the validator set (this is identifiable by checking the ValidatorHash & NextValidatorHash in the block header)

These triggering situations are checked for by a block handler. When such a triggering situation is identified by a validator, the validator generates a new private key (keeps it to itself of course) and issues a transaction indicating it has generated it and including the corresponding public key. This transactions mutates a state variable ValidatorBitcoinPubKeys - a hash from a validator's (tendermint) public key to its bitcoin public key.

Also in a block handler, every node checks if all validator keys have been newly generated (e.g. all keys are there - for every validator pubkey). If so, the node generates a p2sh address (will result in the same address on all nodes) and saves it in the chain state.

When a legitimate need ("Bitcoin Payment Request", BPR) to perform a payment from arises - in other words, when one of the following happens:

  • User has asked for a payout
  • Periodical settlement has been triggered

...then a bitcoin transaction request is generated (it is a type of a transaction on the tendermint chain) and added to a BPR queue in the state.

The validator that proposed the block including the BPR will generate the base bitcoin transaction, sign it and issue a tendermint transaction that includes it. (We need the proposer to do this, since the generated initial transaction needs to be signed ant thus will not be identical when generated by different validators.) That transaction mutates the state by adding the BPR to the queue.

In turn, every validator that proposes a block will check if there are BPRs not yet signed by it in the queue. If so, it will sign them and issue a transaction with the updated signed multi-sig transaction.

When a validator proposing a block identifies a fully-signed BPR (aka signed by m validators, per the multisig setup) in the queue when the block execution ended, it will broadcast that transaction to the bitcoin network and issue a transaction on the tendermint network updating the BPR with the bitcoin transaction ID and the validator's public key (the validator that broadcasted the transaction to the bitcoin network). The number of confirmations (on the bitcoin network) is also kept in the state and is initialized to 0.

Whenever a validator proposes a block, the validator checks BPRs that are pending on the bitcoin network and were broadcast by that validator. If it finds such pending BPRs, it will check for their number of confirmations. If has increased relative to what's in the current state, it will issue a cosmos transaction updating the state to the new number of confirmations. Each node, upon checking this transaction, will reject it if the number of confirmations does not match what they observe on the bitcoin network. If the number is 6, the BPR will be marked as complete (it is still saved in the state).

TBD/Future:

  • Movement of funds from an old master address to a new master address (when the validator set changes). Whenever the validator set changes, a bitcoin transaction needs to be performed in order to send the funds from the previous master address to the new one. This is an interesting case, but not required for many practical usages of Cosmic Bridge, so we're leaving it for later.

  • Handling of failure conditions when the validator set changes while transactions are being prepared, or when a validator that has issued a yet-to-be-confirmed bitcoin transaction fails. Perhaps we can somehow simplify/change the coordination logic to remove potential failure conditions?

Clone this wiki locally