Difference between revisions of "Deposit Address (voting pools)"

From Open Transactions
Jump to navigation Jump to search
(Initial page creation)
 
Line 1: Line 1:
 
==Introduction==
 
==Introduction==
  
In order to fufill the design criteria of [[Category:Voting Pools|voting pools]], blockchain deposit addresses must be created in a deterministic manner such that any entity with the [[Asset Contract (voting pools)|asset contract]] can predict the sequence of addresses and enumerate the holdings of the pool for auditing purposes.
+
In order to fufill the design criteria of [[:Category:Voting Pools|voting pools]], blockchain deposit addresses must be created in a deterministic manner such that any entity with the [[Asset Contract (voting pools)|asset contract]] can predict the sequence of addresses and enumerate the holdings of the pool for auditing purposes.
  
 
==Procedure==
 
==Procedure==

Revision as of 20:43, 17 April 2014

Introduction

In order to fufill the design criteria of voting pools, blockchain deposit addresses must be created in a deterministic manner such that any entity with the asset contract can predict the sequence of addresses and enumerate the holdings of the pool for auditing purposes.

Procedure

The asset contract contains an xpub for every member of the pool for every defined sequence in a keyset. The output scripts which defined the individual deposit addresses are composed from the set of public keys derived by applying the same index value to all xpubs.

For the rest of this discussion the following notation will be used.

y3(5)

The previous example should be interpreted as the specific public key derived by applying the index value of 5 to the xpub belonging to server y in series 3.

Multisig output scripts are created in the general form:

OP_m {pubkey}...{pubkey} OP_n OP_CHECKMULTISIG

Voting pools will create P2SH versions of multisig output scripts to use as deposit addresses. This implies that the exact ordering of the pubkeys in the output script must be defined in order to predict the sequence of P2SH deposit addresses. The ordering is as follows:

Within a given series, the binary representations of the list of xpubs is sorted in ascending order.

The resulting ordering is the standard order.

Public keys in a multisig output script are listed in standard order except the server which will issue an OT receipt for a given deposit moves its pubkey to the beginning of the list.

Because each server has its own unique list of deposit addresses, blockchain wallets must be capable of referencing addresses in a hierarchical fashion.

Each defined wallet produces n+1 independent lists of addresses: a list for each of the n servers in the pool, and a common change address list.

Example

Assume the standard order of the xpubs in series 1 doe a 2-of-3 voting pool is: y1, z1, w1. (this can and will change from series to series).

Server y will accept its very first three deposits to the P2SH addresses corresponding to the following output scripts:

OP_2 y1(1) z1(1), w1(1) OP_3 OP_CHECKMULTISIG

OP_2 y1(2) z1(2), w1(2) OP_3 OP_CHECKMULTISIG

OP_2 y1(3) z1(3), w1(3) OP_3 OP_CHECKMULTISIG

Server w, on the other hand, will use w-y-z ordering for deposits in this series:

OP_2 w1(1) z1(1), y1(1) OP_3 OP_CHECKMULTISIG

OP_2 w1(2) z1(2), y1(2) OP_3 OP_CHECKMULTISIG

OP_2 w1(3) z1(3), y1(3) OP_3 OP_CHECKMULTISIG