Difference between revisions of "Input Selection Algorithm (voting pools)"

From Open Transactions
Jump to navigation Jump to search
(Procedure: add procedure description)
m (Input Ordering)
Line 39: Line 39:
  
 
If an address references more than one eligible inputs, they are all selected and are sorted by txid, then by output index.
 
If an address references more than one eligible inputs, they are all selected and are sorted by txid, then by output index.
 +
 +
In an address contains no eligible inputs, it is skipped.
  
 
==Example==
 
==Example==

Revision as of 12:47, 16 September 2014

Introduction

In order to avoid an expensive and error-prone consensus process, it is mandatory for wallets to be able to construct withdrawal transactions in a deterministic manner, assuming they are given the withdrawal requests in a deterministic order. Once this is accomplished, then it only becomes necessary for wallets to share signatures among themselves because they know they all signed the exact same bitcoin transaction.

Procedure

The input selection algorithm generates an ordered list of eligible inputs for a withdrawal transaction. It is called from startwithdrawal with a set of three parameters:

  1. The first address identifier to be considered.
  2. The last adress identifier to be considered.
  3. The minimum allowed input size.

The algorithm returns all inputs associated with the inclusive range given by inputstart and inputstop which are considered eligable, in a specific order.

Eligibility criteria

An unspent output is considered eligable if it meets the following criteria:

  • Its size is larger than dustthreshold
  • The transaction in which it was created has more than 100 confirmations

The first criteria ensures the input will add more value to the transaction that is cost to spend in terms of fees.

The second ensures determinism.

Withdrawals are processed from the oldest deposits, in FIFO order and reuse of deposit addresses is not encouraged. However, it's not possible to prevent anyone from sending duplicate or unsolicited deposits to an address. The duplicate deposit procedure sweeps unsolicited deposits to their correct location, however at any given time it's not possible to ensure all nodes have performed this procedure at the exact same moment.

If the recommended values of weekly key rotation and 95% cold storage are followed, then the inputs being select should have about 20000 confirmations (two orders of magnitude higher than the limit.)

By rejecting all inputs with less than 100 confirmations, the pool effectively has a 16 hour window in which to detect duplicate deposits and perform the duplicate deposit procedure before there is a risk of non-deterministic transaction construction.

Input Ordering

When moving from address to address, the various parameters of the address identifier are incremented in the following order:

  1. branch (0 to n+1)
  2. index (0 to highest used for series)
  3. series (oldest to newest)

If an address references more than one eligible inputs, they are all selected and are sorted by txid, then by output index.

In an address contains no eligible inputs, it is skipped.

Example

Error creating thumbnail: File with dimensions greater than 12.5 MP