Difference between revisions of "Transaction Construction Algorithm (voting pools)"

From Open Transactions
Jump to navigation Jump to search
(Initial page creation. Includes Overview and Preparation steps)
 
 
(47 intermediate revisions by 3 users not shown)
Line 1: Line 1:
==Introduction==
+
#REDIRECT [[:Category:Transaction Construction Algorithm (voting pools)]]
 
 
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==
 
 
 
===Overview===
 
 
 
[[File:Transaction_Construction_Algorithm_-_Overview.png|600px|right|thumb]]
 
 
 
====Initial Conditions====
 
 
 
The [[getdepositscript]] API call has been received by the wallet, and all the arguments have been checked for errors.
 
 
 
====Sequence====
 
 
 
The basic flow of the procedure is:
 
 
 
# Gather accounting information from the API call arguments
 
# Validate and sort the output list
 
# Start a new transactions
 
# Add outputs to the transaction until either all outputs are added or all inputs are used.
 
# Make sure all generated transactions are ready for signing.
 
# Create a list of all signatures which the wallet is capable of generating.
 
# Create a status list containing the deposition of every output the caller specified.
 
# Return the status list and signature list to the caller.
 
 
 
Each step in this chart is more fully described below.
 
 
 
{{clear}}
 
<hr>
 
===Preparation===
 
 
 
[[File:Transaction_Construction_Algorithm_-_Preparation.png|175px|right|thumb]]
 
 
 
====Initial Conditions====
 
 
 
The [[getdepositscript]] API call has been received by the wallet, and all the arguments have been checked for errors.
 
 
 
====Sequence====
 
 
 
# The algorithm must keep track of the next change address to be used. The initial value is supplied as the <code>[[Startwithdrawal#Arguments|changestart]]</code> argument. Any time a change output is allocated, the index value of the [[address identifier]] is incremented, and if a change output is remove from a transaction the index value is decremented. The final value will be returned to the caller as the <code>[[Withdrawal status|nextchangestart]]</code> value in the [[Withdrawal status| withdrawal status list]].
 
# Prepare an empty list for holding transactions as they are constructed and before they are signed.
 
# Prepare an empty array to hold the transaction signatures which will be returned to the caller as the <code>[[siglist| signatures]]</code> value.
 
# Prepare an <code>withdrawal status</code> object.
 
## <code>roundID</code>: copied from <code>roundID</code> argument
 
## <code>nextinputstart</code>: nil
 
## <code>nextchangestart</code>: nil
 
## <code>fees</code>: 0
 
## <code>outputs</code>: should contain an entry for every output passed:
 
### <code>outBailmentID</code>: copied from <code>outBailmentID</code> entry in <code>outputs</code> argument
 
### <code>status</code>: empty string
 
### <code>transactions</code>: nil
 
 
 
{{clear}}
 
<hr>
 
 
 
[[Category:Voting Pool Technical Specifications]]
 

Latest revision as of 14:55, 22 October 2014