http://opentransactions.org/wiki/api.php?action=feedcontributions&user=Justusranvier&feedformat=atomOpen Transactions - User contributions [en]2024-03-28T18:26:35ZUser contributionsMediaWiki 1.32.2http://opentransactions.org/wiki/index.php?title=Update_Status&diff=3153Update Status2015-07-08T20:53:41Z<p>Justusranvier: </p>
<hr />
<div><div style="float: right"><include iframe src="https://www.lucidchart.com/documents/embeddedchart/b4dcbb56-3b87-4f56-b249-dfd4276c7cc4" width="300" height="800" frameborder="0" scrolling="yes" /></div><br />
<br />
==Initial Conditions==<br />
<br />
* Every outBailmentID in the [[Outputs (Voting Pool Wallet API)|output]] list provided has a non-nil <code>status</code> value in the [[withdrawal status]] object.<br />
<br />
==Sequence==<br />
<br />
# Update the status for any split outBailments which exist:<br />
## Split outBailments have more than one item in their <code>outpoints</code> array and have an existing <code>status</code> value of "success".<br />
## Change the <code>status</code> for all split outBailments from "success" to "split".<br />
# Update the status for any partial outBailments which exist:<br />
## Partial outBailments have existing <code>status</code> value of "partial-".<br />
## Calculate the total missing value needed to satisfy the partial outputs.<br />
## The missing value of an outBailment is the originally-requested size of the outBailment minus the sum of all outputs created to satisfy it (if any exist).<br />
### Obtain a list of eligible inputs from the series after <code>inputstop</code> and calculate their total value.<br />
### If the eligible value of this series is greater than the total missing value, then the series after <code>inputstop</code> is the target series.<br />
#### If not, repeat the above process while keeping a running total of eligible value until a target series is located.<br />
### Append the number of the target series to the <code>status</code> value for every partial series.<br />
# Update the <code>nextinputstart</code> value.<br />
## If the input stack is empty, <code>nextinputstart</code> is the first [[address identifier]] for the the series after <code>inputstop</code>.<br />
## If the input stack is not empty, <code>nextinputstart</code> is the [[address identifier]] for the next input in the stack.<br />
<br />
[[Category:Transaction Construction Algorithm (voting pools)|07]]</div>Justusranvierhttp://opentransactions.org/wiki/index.php?title=Update_Status&diff=3152Update Status2015-07-08T20:52:43Z<p>Justusranvier: </p>
<hr />
<div><div style="float: right"><include iframe src="https://www.lucidchart.com/documents/embeddedchart/b4dcbb56-3b87-4f56-b249-dfd4276c7cc4" width="300" height="800" frameborder="0" scrolling="yes" /></div><br />
<br />
==Initial Conditions==<br />
<br />
* Every outBailmentID in the [[Outputs (Voting Pool Wallet API)|output]] list provided has a non-nil <code>status</code> value in the [[withdrawal status]] object.<br />
<br />
==Sequence==<br />
<br />
# Update the status for any split outBailments which exist:<br />
## Split outBailments have more than one item in their <code>outpoints</code> array and have an existing <code>status</code> value of "success".<br />
## Change the <code>status</code> for all split outBailments from "success" to "split".<br />
# Update the status for any partial outBailments which exist:<br />
## Partial outBailments have existing <code>status</code> value of "partial-".<br />
## Calculate the total missing value needed to satisfy the partial outputs.<br />
## The missing value of an outBailment is the originally-requested size of the outBailment minus the sum of all outputs created to satisfy it (if any exist).<br />
### Obtain a list of eligible inputs from the series after inputstop and calculate their total value.<br />
### If the eligible value of this series is greater than the total missing value, then the series after inputstop is the target series.<br />
#### If not, repeat the above process while keeping a running total of eligible value until a target series is located.<br />
### Append the number of the target series to the <code>status</code> value for every partial series.<br />
# Update the <code>nextinputstart</code> value.<br />
## If the input stack is empty, <code>nextinputstart</code> is the first [[address identifier]] for the the series after inputstop.<br />
## If the input stack is not empty, <code>nextinputstart</code> is the [[address identifier]] for the next input in the stack.<br />
<br />
[[Category:Transaction Construction Algorithm (voting pools)|07]]</div>Justusranvierhttp://opentransactions.org/wiki/index.php?title=Update_Status&diff=3151Update Status2015-07-08T20:52:06Z<p>Justusranvier: /* Sequence */ clarify procedure for calculating target series</p>
<hr />
<div><div style="float: right"><include iframe src="https://www.lucidchart.com/documents/embeddedchart/b4dcbb56-3b87-4f56-b249-dfd4276c7cc4" width="300" height="800" frameborder="0" scrolling="yes" /></div><br />
<br />
==Initial Conditions==<br />
<br />
* Every outBailmentID in the [[Outputs (Voting Pool Wallet API)|output]] list provided has a non-nil <code>status</code> value in the [[withdrawal status]] object.<br />
<br />
==Sequence==<br />
<br />
# Update the status for any split outBailments which exist:<br />
## Split outBailments have more than one item in their <code>outpoints</code> array and have an existing <code>status</code> value of "success".<br />
## Change the <code>status</code> for all split outBailments from "success" to "split".<br />
# Update the status for any partial outBailments which exist:<br />
## Partial outBailments have existing <code>status</code> value of "partial-".<br />
## Calculate the total missing value needed to satisfy the partial outputs.<br />
## The missing value of an outBailment is the originally-requested size of the outBailment minus the sum of all outputs created to satisfy it (if any exist).<br />
### Obtain a list of eligible inputs from the series after inputstop and calculate their total value.<br />
### If the eligible value of this series is greater than the total missing value, then the series after inputstop is the target series.<br />
#### If not, repeat the above process while keeping a running total of eligible value until a target series is located.<br />
### Append the number of the target series to the <code>status</code> value for every partial series.<br />
# Update the <code>nextinputstart</code> value.<br />
## If the input stack is empty, <code>nextinputstart</code> is the first [[address identifier]] for the next un-thawed series.<br />
## If the input stack is not empty, <code>nextinputstart</code> is the [[address identifier]] for the next input in the stack.<br />
<br />
[[Category:Transaction Construction Algorithm (voting pools)|07]]</div>Justusranvierhttp://opentransactions.org/wiki/index.php?title=Signature_status&diff=3146Signature status2015-06-30T17:15:09Z<p>Justusranvier: correct URL to reference json</p>
<hr />
<div>The [[startwithdrawal]] API call returns a list of signatures which can be shared with other members of the voting pool to create an valid withdrawal transaction.<br />
<br />
The list is formatted as a JSON object.<br />
<br />
==Schema==<br />
<br />
<include src="https://raw.githubusercontent.com/Monetas/rfc/master/json/schema/signaturestatus-01.json" /><br />
<br />
<br />
==Example==<br />
<br />
* Input 0 is a 2-of-3 multisig script and none of the required signatures have been supplied<br />
* Input 1 is a 2-of-3 multisig script and all of the required signatures have been supplied<br />
<br />
<include src="https://raw.githubusercontent.com/Monetas/rfc/master/json/data/signaturestatus-01.json" /><br />
<br />
[[Category:Voting Pool Technical Specifications]]</div>Justusranvierhttp://opentransactions.org/wiki/index.php?title=Signature_status&diff=3145Signature status2015-06-30T17:14:03Z<p>Justusranvier: Initial page creation</p>
<hr />
<div>The [[startwithdrawal]] API call returns a list of signatures which can be shared with other members of the voting pool to create an valid withdrawal transaction.<br />
<br />
The list is formatted as a JSON object.<br />
<br />
==Schema==<br />
<br />
<include src="https://raw.githubusercontent.com/Monetas/rfc/master/json/schema/siglist-01.json" /><br />
<br />
<br />
==Example==<br />
<br />
* Input 0 is a 2-of-3 multisig script and none of the required signatures have been supplied<br />
* Input 1 is a 2-of-3 multisig script and all of the required signatures have been supplied<br />
<br />
<include src="https://raw.githubusercontent.com/Monetas/rfc/master/json/data/siglist-01.json" /><br />
<br />
[[Category:Voting Pool Technical Specifications]]</div>Justusranvierhttp://opentransactions.org/wiki/index.php?title=Replaceseries&diff=3142Replaceseries2015-01-16T16:40:43Z<p>Justusranvier: /* Description */</p>
<hr />
<div>==Description==<br />
<br />
This call instructs the [[wallet (blockchain)|blockchain wallet]] to replace an already-defined series with a new one. This will occur with the structure of the voting pool is changed.<br />
<br />
Series which have already been [[thawseries|thawed]] or activated may not be replaced.<br />
<br />
The new series created by this call becomes the new highest-defined series for the pool. If the series it replaced was not previously the highest-defined series, then the effect of this call will be to create an "orphan chain" of obsolete series definitions.<br />
<br />
The private keys for orphaned series definitions should not be deleted, but the series associated with them are no longer considered to be part of the voting pool.<br />
<br />
==Status==<br />
<br />
;Version 1 Release candidate<br />
:This version of the specification contains is believed to be complete, but is still subject to revision before version 1<br />
<br />
==Arguments==<br />
<br />
;version<br />
:Should be 1. This field allows for future expansion of the voting pool wallet specification.<br />
<br />
;[[Wallet_(blockchain)#Series_Identifier|series identifier]]<br />
:The series to be replaced<br />
<br />
;required signatures<br />
:The number of signatures needed to sign an outgoing transaction. This is the <code>m</code> value for the <code>m-of-n</code> multiscript opcode.<br />
<br />
;list of [[xpub|xpubs]]<br />
:The <code>n</code> value for the <code>m-of-n</code> multiscript opcode is implicitly derived from the number of xpubs provided here.<br />
<br />
==Return Values==<br />
<br />
===Data===<br />
<br />
None<br />
<br />
===Errors===<br />
<br />
;Success<br />
:The wallet has replaced the given series with the new definition.<br />
;Unknown version<br />
:The wallet does not support the supplied version number.<br />
;Series not defined<br />
:The series to be replaced must already exist.<br />
;Too many pubkeys<br />
:This error indicates that more than the maximum number of pubkeys allowed by <code>OP_CHECKMULTISIG</code> have been supplied.<br />
;Duplicate pubkeys<br />
:[[xpub|xpubs]] in a series must be unique.<br />
;Insufficient pubkeys<br />
:The number of xpubs supplied must be larger than <code>required signatures</code><br />
;Invalid pool<br />
:The pool supplied as part of the <code>series identifier</code> must be a valid [[color definition]].<br />
;Invalid pubkey<br />
:Each xpub supplied must be a valid [[BIP32]] extended public key.<br />
;Invalid series<br />
:Series numbers supplied as part of the <code>series identifier</code> must be positive integers.<br />
;Series not cold<br />
:In order to avoid losing deposits, a series that has been [[thawseries|thawed]] may not be replaced.<br />
;Series already active<br />
:In order to avoid losing deposits, a series that has been activated may not be replaced.<br />
<br />
[[Category:Voting Pool Wallet API]]</div>Justusranvierhttp://opentransactions.org/wiki/index.php?title=Createseries&diff=3141Createseries2015-01-16T16:34:49Z<p>Justusranvier: /* Errors */ Note that series numbers must increase monotonically</p>
<hr />
<div>==Description==<br />
<br />
This call instructs the [[wallet (blockchain)|blockchain wallet]] to create and populate new series.<br />
<br />
==Status==<br />
<br />
;Version 1 Release candidate<br />
:This version of the specification contains is believed to be complete, but is still subject to revision before version 1<br />
<br />
==Arguments==<br />
<br />
;version<br />
:Should be 1. This field allows for future expansion of the voting pool wallet specification.<br />
<br />
;[[Wallet_(blockchain)#Series_Identifier|series identifier]]<br />
:The series to be created<br />
<br />
;required signatures<br />
:The number of signatures needed to sign an outgoing transaction. This is the <code>m</code> value for the <code>m-of-n</code> multiscript opcode.<br />
<br />
;list of [[xpub|xpubs]]<br />
:The <code>n</code> value for the <code>m-of-n</code> multiscript opcode is implicitly derived from the number of xpubs provided here.<br />
<br />
==Return Values==<br />
<br />
===Data===<br />
none<br />
<br />
===Errors===<br />
;Success<br />
:The wallet has created the series.<br />
;Unknown version<br />
:The wallet does not support the supplied version number.<br />
;Series already exists<br />
:This call should not allow the same series number to be created in the same voting pool. If it's necessary to change an already-defined series, the <code>[[replaceseries]]</code> call should be used instead.<br />
;Too many pubkeys<br />
:This error indicates that more than the maximum number of pubkeys allowed by <code>OP_CHECKMULTISIG</code> have been supplied.<br />
;Duplicate pubkeys<br />
:[[xpub|xpubs]] in a series must be unique.<br />
;Insufficient pubkeys<br />
:The number of xpubs supplied must be larger than <code>required signatures</code><br />
;Invalid pool<br />
:The pool supplied as part of the <code>series identifier</code> must be a valid [[color definition]].<br />
;Invalid pubkey<br />
:Each xpub supplied must be a valid [[BIP32]] extended public key.<br />
;Invalid series<br />
:Series numbers supplied as part of the <code>series identifier</code> must be positive integers, and must be exactly one higher than the current highest defined series for the pool.<br />
<br />
[[Category:Voting Pool Wallet API]]</div>Justusranvierhttp://opentransactions.org/wiki/index.php?title=Split_Output&diff=3133Split Output2014-12-01T17:24:12Z<p>Justusranvier: /* Sequence */</p>
<hr />
<div><div style="float: right"><include iframe src="https://www.lucidchart.com/documents/embeddedchart/c72ce59c-65c0-4a90-943a-c669bac5a737" width="300" height="1004" frameborder="0" scrolling="yes" /></div><br />
<br />
This procedure is used when, either due to a large output or small inputs, the inputs required to satisfy a single output can not fit within transaction size limits.<br />
<br />
The <code>outBailment</code> will be split across two or more transactions.<br />
<br />
==Initial Conditions==<br />
<br />
* The transaction being constructed contains one output, and many inputs.<br />
* The transaction did not exceed any size limits until the most recent input was added.<br />
<br />
==Sequence==<br />
<br />
# Update the value of the output in the transaction to be the sum of the inputs minus the required transaction fee.<br />
# Make a copy of the [[Outputs (Voting Pool Wallet API)|outputs]] object corresponding to this outBailmentID.<br />
# Update the <code>amount</code> field of the copied output by subtracting the value determined in step 4.<br />
# Push this new output to the output stack.<br />
# Update the <code>status</code> field for this outBailmentID in the [[withdrawal status]] object to "partial-".<br />
# Perform the [[Finalize Transaction]] Procedure.<br />
# [[Initialize New Transaction|Initialize]] a new transaction.<br />
<br />
[[Category:Transaction Construction Algorithm (voting pools)|12]]</div>Justusranvierhttp://opentransactions.org/wiki/index.php?title=Oversize_Transaction&diff=3132Oversize Transaction2014-12-01T17:24:06Z<p>Justusranvier: /* Procedure */</p>
<hr />
<div><div style="float: right"><include iframe src="https://www.lucidchart.com/documents/embeddedchart/4abd7b4f-1079-48d7-af9d-d892433cd65a" width="300" height="400" frameborder="0" scrolling="yes" /></div><br />
<br />
An oversize transaction may occur while attempting to add inputs to satisfy an output which has been added to a transaction as part of the [[Add Next Output]] step.<br />
<br />
Even with the worst case of high <code>m</code> and/or <code>n</code> values, inputs will never be large enough that a transaction can be oversized while attempting to add the first input to a transaction.<br />
<br />
Oversize transactions will have one change output, at least one non-change output, and many inputs.<br />
<br />
If an oversize has two or more non-change outputs, then Add Next Output was successful for the previous output. In this case, the transaction was valid before attempting to add the current output, so the current output should be removed from the current transaction and moved to the next one.<br />
<br />
Otherwise, the transaction has become too large while adding its first non-change output. This can happen due to a series of small inputs, or a large output, or a combination of the two. In this case the [[outBailment]] can not be satisfied with a single transaction and must be split across multiple transactions.<br />
<br />
==Initial Conditions==<br />
<br />
* The Add Next Output procedure has created a transaction that exceeds size limits, in one of the following circumstances:<br />
** Immediately upon adding an output to the transaction<br />
*** The transaction contains other outputs which were added successfully. All inputs currently in the transaction are required to satisfy the previous output(s) before the output that failed.<br />
** After adding the first input to the transaction to satisfy an output<br />
*** The transaction contains other outputs which were added successfully. All inputs currently in the transaction are required to satisfy the previous output(s) before the output that failed.<br />
** After having added at least one input to the transaction to satisfy an output without causing an oversize condition.<br />
*** At least one of the inputs in this transaction are only required to satisfy the current output, not any previous outputs (if any exist).<br />
<br />
==Procedure==<br />
<br />
# Count the number of non-change outputs in the transaction.<br />
# If the number exceeds one, follow the [[Rollback Last Output]] procedure.<br />
# If the number is one:<br />
## Remove the most-recently added input.<br />
## Follow the [[Split Output]] procedure.<br />
<br />
[[Category:Transaction Construction Algorithm (voting pools)|10]]</div>Justusranvierhttp://opentransactions.org/wiki/index.php?title=OTX&diff=3131OTX2014-11-25T13:25:49Z<p>Justusranvier: </p>
<hr />
<div>== OTX Protocol ==<br />
<br />
For using OT in your own application, see the [[API|article on the high-level API.]]<br />
<br />
For more details on how these messages work, see the [[Messaging|article on messaging.]]<br />
<br />
Also see the [[Transactions|article on transaction messages.]]<br />
<br />
=== Version 0.1 ===<br />
<br />
These are the messages used by versions of the opentxs client and server up to [https://github.com/Open-Transactions/Open-Transactions 0.93]<br />
<br />
For specifics on each message, see the [https://github.com/FellowTraveler/Open-Transactions/blob/master/src/otlib/OTMessage.cpp#L313 OTMessage.cpp file.]<br />
<br />
{|class="wikitable" border="1" cellspacing="0" cellpadding="5" style="border: 1px solid black; border-collapse: collapse;"<br />
|- style="font-weight:bold;"<br />
|Message||Action||Response||Transactional (Y/N)<br />
|-<br />
|checkServerID||Like a server “ping”.||@checkServerID||N<br />
|-<br />
|createUserAccount||Register Nym + Credentials at Server||@createUserAccount||Y<br />
|-<br />
|createUserAccount||(If already exists) Download Nym from server||@createUserAccount||N<br />
|-<br />
|deleteUserAccount||Delete Nym from server||@deleteUserAccount||Y<br />
|-<br />
|getRequest||Get current request number for Nym||@getRequest||N<br />
|-<br />
|getContract||Download contract by ID||@getContract||N<br />
|-<br />
|getMint||Download Mint by Asset ID||@getMint||N<br />
|-<br />
|getMarketList||Download list of markets||@getMarketList||N<br />
|-<br />
|getMarketOffers||Download offers active on market||@getMarketOffers||N<br />
|-<br />
|getMarketRecentTrades||Download recent trades for market||@getMarketRecentTrades||N<br />
|-<br />
|getNym_MarketOffers||Download list of offers on market for Nym||@getNym_MarketOffers||N<br />
|-<br />
|checkUser||Download public credentials for a Nym||@checkUser||N<br />
|-<br />
|usageCredits||Get Nym's usage credits from server||@usageCredits||N<br />
|-<br />
|usageCredits||Set Nym's usage credits for server (admin)||@usageCredits||Y<br />
|-<br />
|sendUserMessage||Send message to another Nym||@sendUserMessage||Y<br />
|-<br />
|sendUserInstrument||Send payment instrument to another Nym||@sendUserInstrument||Y<br />
|-<br />
|issueAssetType||Issue currency or stock based on contract||@issueAssetType||Y<br />
|-<br />
|queryAssetTypes||Download list of asset types from server||@queryAssetTypes||N<br />
|-<br />
|issueBasket||Issue basket currency onto server||@issueBasket||Y<br />
|-<br />
|createAccount||Create asset account on server||@createAccount||Y<br />
|-<br />
|getAccount||Download account balance from server||@getAccount||N<br />
|-<br />
|deleteAssetAccount||Delete asset account from server||@deleteAssetAccount||Y<br />
|-<br />
|getTransactionNum||Ask server for 100 new transaction numbers||@getTransactionNum||Y<br />
|-<br />
|getNymbox||Download Nymbox from server||@getNymbox||N<br />
|-<br />
|getInbox||Download Inbox from server||@getInbox||N<br />
|-<br />
|getOutbox||Download outbox from server||@getOutbox||N<br />
|-<br />
|getBoxReceipt||Download box receipt from server||@getBoxReceipt||N<br />
|-<br />
|processInbox||Process inbox items||@processInbox||Y<br />
|-<br />
|processNymbox||Process nymbox items||@processNymbox||Y<br />
|-<br />
|triggerClause||Trigger clause on running smart contract||@triggerClause||Y<br />
|-<br />
|notarizeTransactions||“transfer” acct-to-acct||@notarizeTransactions||Y<br />
|-<br />
|notarizeTransactions||“deposit” cash||@notarizeTransactions||Y<br />
|-<br />
|notarizeTransactions||“deposit” cheque||@notarizeTransactions||Y<br />
|-<br />
|notarizeTransactions||“withdrawal” of cash||@notarizeTransactions||Y<br />
|-<br />
|notarizeTransactions||“withdrawal” of voucher||@notarizeTransactions||Y<br />
|-<br />
|notarizeTransactions||Place a “marketOffer”||@notarizeTransactions||Y<br />
|-<br />
|notarizeTransactions||Activate a “paymentPlan”||@notarizeTransactions||Y<br />
|-<br />
|notarizeTransactions||Activate a “smartContract”||@notarizeTransactions||Y<br />
|-<br />
|notarizeTransactions||“cancelCronItem” - Cancel a market offer, payment plan or smart contract.||@notarizeTransactions||Y<br />
|-<br />
|notarizeTransactions||“exchangeBasket” (Into the basket)||@notarizeTransactions||Y<br />
|-<br />
|notarizeTransactions||“exchangeBasket” (Out of the basket)||@notarizeTransactions||Y<br />
|-<br />
|notarizeTransactions||“payDividend” to shareholders||@notarizeTransactions||Y<br />
|}<br />
<br />
=== Version 0.2 ===<br />
<br />
For more details on message contents and formats, see [https://github.com/monetas/protocol-docs/blob/master/content/doctypes/notaryMessage.md GitHub documentation]<br />
<br />
{|class="wikitable" border="1" cellspacing="0" cellpadding="5" style="border: 1px solid black; border-collapse: collapse;"<br />
|- style="font-weight:bold;"<br />
|Old name||New name||Response Message<br />
|-<br />
|createUserAccount||registerNym||registerNymResponse<br />
|-<br />
|}<br />
<br />
[[About|Click here to return to the About page.]]</div>Justusranvierhttp://opentransactions.org/wiki/index.php?title=OTX&diff=3130OTX2014-11-25T13:19:39Z<p>Justusranvier: /* Version 0.2 */</p>
<hr />
<div>== OTX Protocol ==<br />
<br />
For using OT in your own application, see the [[API|article on the high-level API.]]<br />
<br />
For more details on how these messages work, see the [[Messaging|article on messaging.]]<br />
<br />
Also see the [[Transactions|article on transaction messages.]]<br />
<br />
=== Version 0.1 ===<br />
<br />
These are the messages used by versions of the opentxs client and server up to [https://github.com/Open-Transactions/Open-Transactions 0.93]<br />
<br />
For specifics on each message, see the [https://github.com/FellowTraveler/Open-Transactions/blob/master/src/otlib/OTMessage.cpp#L313 OTMessage.cpp file.]<br />
<br />
{|class="wikitable" border="1" cellspacing="0" cellpadding="5" style="border: 1px solid black; border-collapse: collapse;"<br />
|- style="font-weight:bold;"<br />
|Message||Action||Response||Transactional (Y/N)<br />
|-<br />
|checkServerID||Like a server “ping”.||@checkServerID||N<br />
|-<br />
|createUserAccount||Register Nym + Credentials at Server||@createUserAccount||Y<br />
|-<br />
|createUserAccount||(If already exists) Download Nym from server||@createUserAccount||N<br />
|-<br />
|deleteUserAccount||Delete Nym from server||@deleteUserAccount||Y<br />
|-<br />
|getRequest||Get current request number for Nym||@getRequest||N<br />
|-<br />
|getContract||Download contract by ID||@getContract||N<br />
|-<br />
|getMint||Download Mint by Asset ID||@getMint||N<br />
|-<br />
|getMarketList||Download list of markets||@getMarketList||N<br />
|-<br />
|getMarketOffers||Download offers active on market||@getMarketOffers||N<br />
|-<br />
|getMarketRecentTrades||Download recent trades for market||@getMarketRecentTrades||N<br />
|-<br />
|getNym_MarketOffers||Download list of offers on market for Nym||@getNym_MarketOffers||N<br />
|-<br />
|checkUser||Download public credentials for a Nym||@checkUser||N<br />
|-<br />
|usageCredits||Get Nym's usage credits from server||@usageCredits||N<br />
|-<br />
|usageCredits||Set Nym's usage credits for server (admin)||@usageCredits||Y<br />
|-<br />
|sendUserMessage||Send message to another Nym||@sendUserMessage||Y<br />
|-<br />
|sendUserInstrument||Send payment instrument to another Nym||@sendUserInstrument||Y<br />
|-<br />
|issueAssetType||Issue currency or stock based on contract||@issueAssetType||Y<br />
|-<br />
|queryAssetTypes||Download list of asset types from server||@queryAssetTypes||N<br />
|-<br />
|issueBasket||Issue basket currency onto server||@issueBasket||Y<br />
|-<br />
|createAccount||Create asset account on server||@createAccount||Y<br />
|-<br />
|getAccount||Download account balance from server||@getAccount||N<br />
|-<br />
|deleteAssetAccount||Delete asset account from server||@deleteAssetAccount||Y<br />
|-<br />
|getTransactionNum||Ask server for 100 new transaction numbers||@getTransactionNum||Y<br />
|-<br />
|getNymbox||Download Nymbox from server||@getNymbox||N<br />
|-<br />
|getInbox||Download Inbox from server||@getInbox||N<br />
|-<br />
|getOutbox||Download outbox from server||@getOutbox||N<br />
|-<br />
|getBoxReceipt||Download box receipt from server||@getBoxReceipt||N<br />
|-<br />
|processInbox||Process inbox items||@processInbox||Y<br />
|-<br />
|processNymbox||Process nymbox items||@processNymbox||Y<br />
|-<br />
|triggerClause||Trigger clause on running smart contract||@triggerClause||Y<br />
|-<br />
|notarizeTransactions||“transfer” acct-to-acct||@notarizeTransactions||Y<br />
|-<br />
|notarizeTransactions||“deposit” cash||@notarizeTransactions||Y<br />
|-<br />
|notarizeTransactions||“deposit” cheque||@notarizeTransactions||Y<br />
|-<br />
|notarizeTransactions||“withdrawal” of cash||@notarizeTransactions||Y<br />
|-<br />
|notarizeTransactions||“withdrawal” of voucher||@notarizeTransactions||Y<br />
|-<br />
|notarizeTransactions||Place a “marketOffer”||@notarizeTransactions||Y<br />
|-<br />
|notarizeTransactions||Activate a “paymentPlan”||@notarizeTransactions||Y<br />
|-<br />
|notarizeTransactions||Activate a “smartContract”||@notarizeTransactions||Y<br />
|-<br />
|notarizeTransactions||“cancelCronItem” - Cancel a market offer, payment plan or smart contract.||@notarizeTransactions||Y<br />
|-<br />
|notarizeTransactions||“exchangeBasket” (Into the basket)||@notarizeTransactions||Y<br />
|-<br />
|notarizeTransactions||“exchangeBasket” (Out of the basket)||@notarizeTransactions||Y<br />
|-<br />
|notarizeTransactions||“payDividend” to shareholders||@notarizeTransactions||Y<br />
|}<br />
<br />
=== Version 0.2 ===<br />
<br />
{|class="wikitable" border="1" cellspacing="0" cellpadding="5" style="border: 1px solid black; border-collapse: collapse;"<br />
|- style="font-weight:bold;"<br />
|Old name||New name||Response Message<br />
|-<br />
|[[createUserAccount]]||registerNym||registerNymResponse<br />
|-<br />
|}<br />
<br />
[[About|Click here to return to the About page.]]</div>Justusranvierhttp://opentransactions.org/wiki/index.php?title=OTX&diff=3129OTX2014-11-25T13:18:50Z<p>Justusranvier: </p>
<hr />
<div>== OTX Protocol ==<br />
<br />
For using OT in your own application, see the [[API|article on the high-level API.]]<br />
<br />
For more details on how these messages work, see the [[Messaging|article on messaging.]]<br />
<br />
Also see the [[Transactions|article on transaction messages.]]<br />
<br />
=== Version 0.1 ===<br />
<br />
These are the messages used by versions of the opentxs client and server up to [https://github.com/Open-Transactions/Open-Transactions 0.93]<br />
<br />
For specifics on each message, see the [https://github.com/FellowTraveler/Open-Transactions/blob/master/src/otlib/OTMessage.cpp#L313 OTMessage.cpp file.]<br />
<br />
{|class="wikitable" border="1" cellspacing="0" cellpadding="5" style="border: 1px solid black; border-collapse: collapse;"<br />
|- style="font-weight:bold;"<br />
|Message||Action||Response||Transactional (Y/N)<br />
|-<br />
|checkServerID||Like a server “ping”.||@checkServerID||N<br />
|-<br />
|createUserAccount||Register Nym + Credentials at Server||@createUserAccount||Y<br />
|-<br />
|createUserAccount||(If already exists) Download Nym from server||@createUserAccount||N<br />
|-<br />
|deleteUserAccount||Delete Nym from server||@deleteUserAccount||Y<br />
|-<br />
|getRequest||Get current request number for Nym||@getRequest||N<br />
|-<br />
|getContract||Download contract by ID||@getContract||N<br />
|-<br />
|getMint||Download Mint by Asset ID||@getMint||N<br />
|-<br />
|getMarketList||Download list of markets||@getMarketList||N<br />
|-<br />
|getMarketOffers||Download offers active on market||@getMarketOffers||N<br />
|-<br />
|getMarketRecentTrades||Download recent trades for market||@getMarketRecentTrades||N<br />
|-<br />
|getNym_MarketOffers||Download list of offers on market for Nym||@getNym_MarketOffers||N<br />
|-<br />
|checkUser||Download public credentials for a Nym||@checkUser||N<br />
|-<br />
|usageCredits||Get Nym's usage credits from server||@usageCredits||N<br />
|-<br />
|usageCredits||Set Nym's usage credits for server (admin)||@usageCredits||Y<br />
|-<br />
|sendUserMessage||Send message to another Nym||@sendUserMessage||Y<br />
|-<br />
|sendUserInstrument||Send payment instrument to another Nym||@sendUserInstrument||Y<br />
|-<br />
|issueAssetType||Issue currency or stock based on contract||@issueAssetType||Y<br />
|-<br />
|queryAssetTypes||Download list of asset types from server||@queryAssetTypes||N<br />
|-<br />
|issueBasket||Issue basket currency onto server||@issueBasket||Y<br />
|-<br />
|createAccount||Create asset account on server||@createAccount||Y<br />
|-<br />
|getAccount||Download account balance from server||@getAccount||N<br />
|-<br />
|deleteAssetAccount||Delete asset account from server||@deleteAssetAccount||Y<br />
|-<br />
|getTransactionNum||Ask server for 100 new transaction numbers||@getTransactionNum||Y<br />
|-<br />
|getNymbox||Download Nymbox from server||@getNymbox||N<br />
|-<br />
|getInbox||Download Inbox from server||@getInbox||N<br />
|-<br />
|getOutbox||Download outbox from server||@getOutbox||N<br />
|-<br />
|getBoxReceipt||Download box receipt from server||@getBoxReceipt||N<br />
|-<br />
|processInbox||Process inbox items||@processInbox||Y<br />
|-<br />
|processNymbox||Process nymbox items||@processNymbox||Y<br />
|-<br />
|triggerClause||Trigger clause on running smart contract||@triggerClause||Y<br />
|-<br />
|notarizeTransactions||“transfer” acct-to-acct||@notarizeTransactions||Y<br />
|-<br />
|notarizeTransactions||“deposit” cash||@notarizeTransactions||Y<br />
|-<br />
|notarizeTransactions||“deposit” cheque||@notarizeTransactions||Y<br />
|-<br />
|notarizeTransactions||“withdrawal” of cash||@notarizeTransactions||Y<br />
|-<br />
|notarizeTransactions||“withdrawal” of voucher||@notarizeTransactions||Y<br />
|-<br />
|notarizeTransactions||Place a “marketOffer”||@notarizeTransactions||Y<br />
|-<br />
|notarizeTransactions||Activate a “paymentPlan”||@notarizeTransactions||Y<br />
|-<br />
|notarizeTransactions||Activate a “smartContract”||@notarizeTransactions||Y<br />
|-<br />
|notarizeTransactions||“cancelCronItem” - Cancel a market offer, payment plan or smart contract.||@notarizeTransactions||Y<br />
|-<br />
|notarizeTransactions||“exchangeBasket” (Into the basket)||@notarizeTransactions||Y<br />
|-<br />
|notarizeTransactions||“exchangeBasket” (Out of the basket)||@notarizeTransactions||Y<br />
|-<br />
|notarizeTransactions||“payDividend” to shareholders||@notarizeTransactions||Y<br />
|}<br />
<br />
=== Version 0.2 ===<br />
<br />
{|class="wikitable" border="1" cellspacing="0" cellpadding="5" style="border: 1px solid black; border-collapse: collapse;"<br />
|- style="font-weight:bold;"<br />
|Old name||New name||Response Message<br />
|-<br />
|createUserAccount||registerNym||registerNymResponse<br />
|-<br />
|}<br />
<br />
[[About|Click here to return to the About page.]]</div>Justusranvierhttp://opentransactions.org/wiki/index.php?title=OTX&diff=3128OTX2014-11-25T13:03:42Z<p>Justusranvier: </p>
<hr />
<div>== OTX Protocol ==<br />
<br />
For using OT in your own application, see the [[API|article on the high-level API.]]<br />
<br />
For more details on how these messages work, see the [[Messaging|article on messaging.]]<br />
<br />
Also see the [[Transactions|article on transaction messages.]]<br />
<br />
=== Version 0 ===<br />
<br />
These are the messages used by versions of the opentxs client and server up to [https://github.com/Open-Transactions/Open-Transactions 0.93]<br />
<br />
For specifics on each message, see the [https://github.com/FellowTraveler/Open-Transactions/blob/master/src/otlib/OTMessage.cpp#L313 OTMessage.cpp file.]<br />
<br />
{|class="wikitable" border="1" cellspacing="0" cellpadding="5" style="border: 1px solid black; border-collapse: collapse;"<br />
|- style="font-weight:bold;"<br />
|Message||Action||Response||Transactional (Y/N)<br />
|-<br />
|checkServerID||Like a server “ping”.||@checkServerID||N<br />
|-<br />
|createUserAccount||Register Nym + Credentials at Server||@createUserAccount||Y<br />
|-<br />
|createUserAccount||(If already exists) Download Nym from server||@createUserAccount||N<br />
|-<br />
|deleteUserAccount||Delete Nym from server||@deleteUserAccount||Y<br />
|-<br />
|getRequest||Get current request number for Nym||@getRequest||N<br />
|-<br />
|getContract||Download contract by ID||@getContract||N<br />
|-<br />
|getMint||Download Mint by Asset ID||@getMint||N<br />
|-<br />
|getMarketList||Download list of markets||@getMarketList||N<br />
|-<br />
|getMarketOffers||Download offers active on market||@getMarketOffers||N<br />
|-<br />
|getMarketRecentTrades||Download recent trades for market||@getMarketRecentTrades||N<br />
|-<br />
|getNym_MarketOffers||Download list of offers on market for Nym||@getNym_MarketOffers||N<br />
|-<br />
|checkUser||Download public credentials for a Nym||@checkUser||N<br />
|-<br />
|usageCredits||Get Nym's usage credits from server||@usageCredits||N<br />
|-<br />
|usageCredits||Set Nym's usage credits for server (admin)||@usageCredits||Y<br />
|-<br />
|sendUserMessage||Send message to another Nym||@sendUserMessage||Y<br />
|-<br />
|sendUserInstrument||Send payment instrument to another Nym||@sendUserInstrument||Y<br />
|-<br />
|issueAssetType||Issue currency or stock based on contract||@issueAssetType||Y<br />
|-<br />
|queryAssetTypes||Download list of asset types from server||@queryAssetTypes||N<br />
|-<br />
|issueBasket||Issue basket currency onto server||@issueBasket||Y<br />
|-<br />
|createAccount||Create asset account on server||@createAccount||Y<br />
|-<br />
|getAccount||Download account balance from server||@getAccount||N<br />
|-<br />
|deleteAssetAccount||Delete asset account from server||@deleteAssetAccount||Y<br />
|-<br />
|getTransactionNum||Ask server for 100 new transaction numbers||@getTransactionNum||Y<br />
|-<br />
|getNymbox||Download Nymbox from server||@getNymbox||N<br />
|-<br />
|getInbox||Download Inbox from server||@getInbox||N<br />
|-<br />
|getOutbox||Download outbox from server||@getOutbox||N<br />
|-<br />
|getBoxReceipt||Download box receipt from server||@getBoxReceipt||N<br />
|-<br />
|processInbox||Process inbox items||@processInbox||Y<br />
|-<br />
|processNymbox||Process nymbox items||@processNymbox||Y<br />
|-<br />
|triggerClause||Trigger clause on running smart contract||@triggerClause||Y<br />
|-<br />
|notarizeTransactions||“transfer” acct-to-acct||@notarizeTransactions||Y<br />
|-<br />
|notarizeTransactions||“deposit” cash||@notarizeTransactions||Y<br />
|-<br />
|notarizeTransactions||“deposit” cheque||@notarizeTransactions||Y<br />
|-<br />
|notarizeTransactions||“withdrawal” of cash||@notarizeTransactions||Y<br />
|-<br />
|notarizeTransactions||“withdrawal” of voucher||@notarizeTransactions||Y<br />
|-<br />
|notarizeTransactions||Place a “marketOffer”||@notarizeTransactions||Y<br />
|-<br />
|notarizeTransactions||Activate a “paymentPlan”||@notarizeTransactions||Y<br />
|-<br />
|notarizeTransactions||Activate a “smartContract”||@notarizeTransactions||Y<br />
|-<br />
|notarizeTransactions||“cancelCronItem” - Cancel a market offer, payment plan or smart contract.||@notarizeTransactions||Y<br />
|-<br />
|notarizeTransactions||“exchangeBasket” (Into the basket)||@notarizeTransactions||Y<br />
|-<br />
|notarizeTransactions||“exchangeBasket” (Out of the basket)||@notarizeTransactions||Y<br />
|-<br />
|notarizeTransactions||“payDividend” to shareholders||@notarizeTransactions||Y<br />
|}<br />
<br />
=== Version 1 ===<br />
<br />
{|class="wikitable" border="1" cellspacing="0" cellpadding="5" style="border: 1px solid black; border-collapse: collapse;"<br />
|- style="font-weight:bold;"<br />
|Old name||New name||Response Message<br />
|-<br />
|createUserAccount||registerNym||registerNymResponse<br />
|-<br />
|}<br />
<br />
[[About|Click here to return to the About page.]]</div>Justusranvierhttp://opentransactions.org/wiki/index.php?title=Consensus_Process_(voting_pools)&diff=3126Consensus Process (voting pools)2014-11-12T14:48:44Z<p>Justusranvier: </p>
<hr />
<div>==Introduction==<br />
<br />
In order to process blockchain withdrawals from the pool, the audit servers must agree on a set of parameters used to deterministically construct blockchain transactions. The servers arrive at a new consensus at a short intervals.<br />
<br />
Each new consensus will result in a unanimous agreement on the following parameters:<br />
<br />
# The [[Wallet_(blockchain)#Address_Identification|address identifier]] for the first input to be used for constructing withdrawal transaction(s)<br />
# The address identifier for the first [[Change Address (voting pools)|Change Address]] to be used by the resulting withdrawal transaction(s)<br />
# The highest series number which at least <code>m</code> pool members have thawed<br />
# A list of valid withdrawals to be processed, which may be an empty list<br />
# The smallest value above which an input is considered eligible for inclusion in a transaction and below which is considered "dust"<br />
<br />
[[Category:Voting Pool Technical Specifications]]</div>Justusranvierhttp://opentransactions.org/wiki/index.php?title=Asset_contract_(voting_pools)&diff=3125Asset contract (voting pools)2014-11-12T14:36:24Z<p>Justusranvier: </p>
<hr />
<div>==Introduction==<br />
<br />
Asset contract for voting pools differ from standard OT asset contracts in two ways: they contain a copy of the [[Keyset_(voting_pools)|keyset definition]], and they are not identified by their hash.<br />
<br />
Since keyset definitions change over time, or when the pool is modified, this means voting pool asset contracts are mutable, This means the asset contracts can not be identified by their hash. Instead, voting pool contracts are linked to a [[Colored_coins#Smart_Property|smart property]], and use the smart property's [[Colored_coins#Color_descriptors|color descriptor]] as their identifier.<br />
<br />
==Identifying voting pool asset contracts==<br />
<br />
Each valid version of the contract is known as an <code>instance</code> of the contract, and has an <code>instance identifier</code>. Prior to creating a voting pool asset contract, one of the creators of the pool must create a smart property virtual token. This indivisible virtual token (smart property) is known as the <code>charter output</code>. The color descriptor for the charter output is the permanent identifier that will be used as the asset contract ID.<br />
<br />
The initial pool asset contract instance is created with the smart property descriptor in its header. Each future instance must contain the same descriptor.<br />
<br />
To activate the pool contract, the charter output must be moved to the 0<sup>th</sup> change address defined for the first series, will setting the value of the smart property to the instance identifier.<br />
<br />
==Modifying the contract==<br />
<br />
Clients validate the asset contract by looking up the value of its smart property and verifying this value matches the instance identifier of the asset contract. Additionally, the charter output must be located in the 0<sup>th</sup> [[Change_Address_(voting_pools)|change output]] for the current [[Keyset_(voting_pools)#series|series]].<br />
<br />
This means the only way the charter output can be moved is if <code>m-of-n</code> members of the voting pool, therefore it is possible to prove that the current instance of the contract is part of an uninterrupted continuity from the original version if the charter output is located at the correct address.<br />
<br />
[[Category:Voting Pool Technical Specifications]]</div>Justusranvierhttp://opentransactions.org/wiki/index.php?title=Colored_coins&diff=3124Colored coins2014-11-12T14:33:24Z<p>Justusranvier: /* Common Color kernels */</p>
<hr />
<div>==Definitions==<br />
<br />
The term “colored coins” can mean two different things:<br />
<br />
* A technique for carefully constructing blockchain transactions in a way that preserves information apart from the base monetary value of the underlying units<br />
* The extra information preserved in the blockchain by employing the colored coin technique<br />
<br />
For the sake of clarity we will differentiate the technique from the information by using the term “virtual tokens” to refer to the extra information that is preserved using the colored coins technique.<br />
<br />
===Virtual Tokens===<br />
<br />
Virtual tokens possess all the capabilities of currency, plus one additional capability (smart property) which is helpful for non-currency usage.<br />
<br />
====Capabilities====<br />
<br />
Users of virtual tokens can:<br />
<br />
*Transfer them between individuals<br />
*Combine multiple tokens into a single token with a greater value<br />
*Divide the value of a single token into multiple tokens<br />
*Use them in blockchain-scripted contracts<br />
*Store them on the blockchain with multisig scripts<br />
*Unambiguously prove that any particular virtual token is a valid member of a set created by the issuer, without requiring the issuer to *create and manage a token registry.<br />
<br />
====Limitations====<br />
<br />
There are certain tasks which virtual tokens inherently cannot perform unaided:<br />
<br />
; Enforcement<br />
: Virtual tokens represent ownership information, but they can’t enforce real-world obligations. For example, a particular issuance of virtual tokens might represent tickets for entry to a concert. The virtual token can prove the bearer should be allowed to enter the concert, but it can’t force the bouncer to step aside and let him pass. Colored coin techniques can’t prevent the user from manipulating the underlying bitcoins in a way that destroys the extra information, because operations on virtual tokens are governed by Bitcoin transaction rules, and colored coin requirements are more strict but not enforced by the network. Using virtual tokens in a transaction that does not obey the colored coin rules destroys their extra meaning, leaving behind only their base monetary value. This is equivalent to taking one’s paper concert ticket and setting it on fire.<br />
; Metadata<br />
: The quantity and ownership of virtual tokens can be stored in the blockchain, but the semantic information that indicates what a token means is not (and cannot be) similarly stored. For example, the blockchain will track how many concert tickets have been issued and which address owns them, but not the fact that they represent authorised entry into a particular concert at a specific time and place. The storage of and operations on metadata require a specific kind of external system, such as Open-Transactions.<br />
; Blockchain Limitations<br />
: The speed of colored coin transactions, and the capabilities of scripted contracts that use virtual tokens are the same as those of the underlying blockchain.<br />
<br />
===Coloring techniques===<br />
<br />
There are two techniques that may be used to create virtual tokens: transaction-based coloring and address-based coloring.<br />
<br />
====Transaction-based coloring====<br />
Transaction-based coloring was pioneered by ChromaWallet and works by identifying a specific Bitcoin transaction at a particular time as the “genesis transaction” and tracking all units which descend from the genesis transaction. Transaction-based coloring can produce the full range of virtual token types, and has the security property that even a loss of the original private keys to the genesis address cannot result in the issuing of counterfeit virtual tokens. This security property means the number of virtual tokens matching a color definition is fixed at the time of creation and cannot be altered in the future—which can be an advantage or a disadvantage, depending on the application.<br />
<br />
====Address-based coloring====<br />
Address-based coloring was created by Coinprism and tracks bitcoins which are descended from any transaction that passes through a defined address. This means the issuer can easily create new units in the future, but so could a thief who manages to steal the private key for that address.<br />
<br />
==Virtual Tokens==<br />
<br />
The different use cases for virtual tokens can be divided into three general categories, which form the different types of virtual tokens.<br />
<br />
===Tickets===<br />
<br />
Tickets are transferable bearer tokens which are designed to be eventually redeemed for some kind of real world value.<br />
<br />
Examples of tickets include:<br />
<br />
* Event entry passes<br />
* Store coupons and special offers<br />
* Frequent flyer miles and other redeemable rewards<br />
<br />
Both address-based and transaction-based coloring can be used to create tickets.<br />
<br />
===Certificates===<br />
<br />
Certificates are transferable and redeemable in the same manner as tickets, and they additionally entitle the bearer to some kind of revenue paid through the blockchain.<br />
<br />
Certificates can be used for bearer securities, such as securitized loans, mortgages, bonds, and dividend-paying stocks.<br />
<br />
Both address-based and transaction-based coloring can be used to create certificates.<br />
<br />
===Smart Property===<br />
<br />
Smart properties are transferable like tickets and certificates, and in addition, every particular smart property is both unique and atomic. Only one smart property of a given identifier can be created, and once created it may not be subdivided.<br />
<br />
Smart properties can be used to indicate ownership of an unique real-world asset, and can also be used for objective naming of content-addressed mutable data. This naming function is related to, and an extension of, hash-based naming.<br />
<br />
A common operation in software engineering is to use cryptographic hash functions to create short identifiers for large pieces of data. This is useful because hash values are easy to communicate since they are short, and also are easy to check since they are deterministic. This means if you know the name of some piece of data, you can independently verify that you have the correct copy of it. But the limitation of hash-based naming is that the named data can never change.<br />
<br />
Smart property overcomes this limitation. Because of a Bitcoin feature (OP_RETURN) that allows arbitrary data to be attached to transactions, every time smart property is moved it can be associated with a new hash. This means if data is identified by a smart property identifier instead of using the hash, the identifier of the smart property can objectively and unambiguously identify the most current version of the data.<br />
<br />
==Transaction-based Coloring==<br />
<br />
Transaction based coloring defines a set of tokens using a genesis outpoint, and a color kernel.<br />
<br />
===Genesis outpoint===<br />
<br />
The genesis outpoint is a named outpoint (transaction hash, output index) in the blockchain. It functions as the head of the tree where the outpoints created by transaction which consumes it, and all descendants of those outpoints, potentially inherit a portion of the genesis transaction's color balance.<br />
<br />
===Color balance===<br />
<br />
The color balance of an outpoint is a quantity which represents some blockchain-external unit. The color balance is encoded into the satoshi balance of an outpoint, but they are not equal.<br />
<br />
It's normally not practical to encode a 1:1 relationship between the color balance and the satoshi value of an output, because blockchain anti-spam rules makes the creation of very small value outputs impractical.<br />
<br />
To account for this, most coloring techniques use a padding system where an extra satoshi amount is added to each output to fulfill minimum output size rules.<br />
<br />
The color balance of an outpoint can then be calculated by subtracting the padding from the satoshi amount.<br />
<br />
===Color Kernel===<br />
<br />
A color kernel is a set of rules which are applied to a transaction to calculate the color balance of the outputs.<br />
<br />
The rules which make up a color kernel may consider any or all of:<br />
<br />
* The color balance of all inputs<br />
* The relative position of outputs relative to inputs<br />
* The relative size of outputs<br />
* The details of the script associated with outputs<br />
* Information encoded in the transaction header fields, such as <code>nSequence</code>.<br />
<br />
After applying a color kernel to a transaction with colored inputs, the color balance of each output is known. Starting from the genesis outpoint, the color kernel can be recursively applied to all descendant transactions in the blockchain until the present position of all colored units can be located.<br />
<br />
Because kernel rules are not enforced by the underlying network, it's possible to create colored coin transactions improperly such that the resulting outpoints do not contain a color balance. This is known as "destroying" colored coins.<br />
<br />
Color kernels are typically identified with a 3-5 character code.<br />
<br />
====Common Color kernels====<br />
<br />
; EPOBC (enhanced, padded, order-based coloring)<br />
: This kernel was created by Chromawallet and is suitable for creating ticket virtual tokens. As implemented in Chromawallet, it does have a limited ability implement certificate virtual tokens.<br />
; SPOBC (smart property order-based coloring)<br />
: This kernel was created by Monetas and is a derivation of EPOBC optimized for creating smart property virtual tokens. Unlike EPOBC, SPOBC tokens have a fixed color balance of one and may not be subdivided.<br />
: Instead of a color balance, an SPOBC token has a value. This value is set by including up to 40 bytes of data in an OP_RETURN output in the transaction containing the token. To change the value of a SPOBC token, it must be included as an input to a new transaction so that the new value may be set.<br />
; DHKEC (diffie-hellman key exchange coloring)<br />
: This kernel was created by Monetas and is a derivation of EPOBC optimized for creating certificate virtual tokens. The DHKEC kernel imposes a restriction on allowed script types to those which expose an ECDSA public key in the blockchain. This allows for payments to be sent to addresses derived via ECDH, which helps maintain the non-colored payment segregated from the colored tokens.<br />
<br />
===Color descriptors===<br />
<br />
Color descriptors provide a URI-like method for identifying issued virtual tokens. The form of a color descriptor is:<br />
<br />
<code><br />
<pre><br />
kernel name : colon-seperated parameter list</pre><br />
</code><br />
<br />
All currently-defined kernels use the same list of parameters:<br />
<br />
<code><br />
<pre>genesis outpoint txid : genesis outpoint index : genesis outpoint block height</pre><br />
</code><br />
<br />
[[Category:Bitcoin Terms]]<br />
[[Category:Voting Pool Terms]]</div>Justusranvierhttp://opentransactions.org/wiki/index.php?title=Colored_coins&diff=3123Colored coins2014-11-12T14:27:05Z<p>Justusranvier: Created page with "==Definitions== The term “colored coins” can mean two different things: * A technique for carefully constructing blockchain transactions in a way that preserves informat..."</p>
<hr />
<div>==Definitions==<br />
<br />
The term “colored coins” can mean two different things:<br />
<br />
* A technique for carefully constructing blockchain transactions in a way that preserves information apart from the base monetary value of the underlying units<br />
* The extra information preserved in the blockchain by employing the colored coin technique<br />
<br />
For the sake of clarity we will differentiate the technique from the information by using the term “virtual tokens” to refer to the extra information that is preserved using the colored coins technique.<br />
<br />
===Virtual Tokens===<br />
<br />
Virtual tokens possess all the capabilities of currency, plus one additional capability (smart property) which is helpful for non-currency usage.<br />
<br />
====Capabilities====<br />
<br />
Users of virtual tokens can:<br />
<br />
*Transfer them between individuals<br />
*Combine multiple tokens into a single token with a greater value<br />
*Divide the value of a single token into multiple tokens<br />
*Use them in blockchain-scripted contracts<br />
*Store them on the blockchain with multisig scripts<br />
*Unambiguously prove that any particular virtual token is a valid member of a set created by the issuer, without requiring the issuer to *create and manage a token registry.<br />
<br />
====Limitations====<br />
<br />
There are certain tasks which virtual tokens inherently cannot perform unaided:<br />
<br />
; Enforcement<br />
: Virtual tokens represent ownership information, but they can’t enforce real-world obligations. For example, a particular issuance of virtual tokens might represent tickets for entry to a concert. The virtual token can prove the bearer should be allowed to enter the concert, but it can’t force the bouncer to step aside and let him pass. Colored coin techniques can’t prevent the user from manipulating the underlying bitcoins in a way that destroys the extra information, because operations on virtual tokens are governed by Bitcoin transaction rules, and colored coin requirements are more strict but not enforced by the network. Using virtual tokens in a transaction that does not obey the colored coin rules destroys their extra meaning, leaving behind only their base monetary value. This is equivalent to taking one’s paper concert ticket and setting it on fire.<br />
; Metadata<br />
: The quantity and ownership of virtual tokens can be stored in the blockchain, but the semantic information that indicates what a token means is not (and cannot be) similarly stored. For example, the blockchain will track how many concert tickets have been issued and which address owns them, but not the fact that they represent authorised entry into a particular concert at a specific time and place. The storage of and operations on metadata require a specific kind of external system, such as Open-Transactions.<br />
; Blockchain Limitations<br />
: The speed of colored coin transactions, and the capabilities of scripted contracts that use virtual tokens are the same as those of the underlying blockchain.<br />
<br />
===Coloring techniques===<br />
<br />
There are two techniques that may be used to create virtual tokens: transaction-based coloring and address-based coloring.<br />
<br />
====Transaction-based coloring====<br />
Transaction-based coloring was pioneered by ChromaWallet and works by identifying a specific Bitcoin transaction at a particular time as the “genesis transaction” and tracking all units which descend from the genesis transaction. Transaction-based coloring can produce the full range of virtual token types, and has the security property that even a loss of the original private keys to the genesis address cannot result in the issuing of counterfeit virtual tokens. This security property means the number of virtual tokens matching a color definition is fixed at the time of creation and cannot be altered in the future—which can be an advantage or a disadvantage, depending on the application.<br />
<br />
====Address-based coloring====<br />
Address-based coloring was created by Coinprism and tracks bitcoins which are descended from any transaction that passes through a defined address. This means the issuer can easily create new units in the future, but so could a thief who manages to steal the private key for that address.<br />
<br />
==Virtual Tokens==<br />
<br />
The different use cases for virtual tokens can be divided into three general categories, which form the different types of virtual tokens.<br />
<br />
===Tickets===<br />
<br />
Tickets are transferable bearer tokens which are designed to be eventually redeemed for some kind of real world value.<br />
<br />
Examples of tickets include:<br />
<br />
* Event entry passes<br />
* Store coupons and special offers<br />
* Frequent flyer miles and other redeemable rewards<br />
<br />
Both address-based and transaction-based coloring can be used to create tickets.<br />
<br />
===Certificates===<br />
<br />
Certificates are transferable and redeemable in the same manner as tickets, and they additionally entitle the bearer to some kind of revenue paid through the blockchain.<br />
<br />
Certificates can be used for bearer securities, such as securitized loans, mortgages, bonds, and dividend-paying stocks.<br />
<br />
Both address-based and transaction-based coloring can be used to create certificates.<br />
<br />
===Smart Property===<br />
<br />
Smart properties are transferable like tickets and certificates, and in addition, every particular smart property is both unique and atomic. Only one smart property of a given identifier can be created, and once created it may not be subdivided.<br />
<br />
Smart properties can be used to indicate ownership of an unique real-world asset, and can also be used for objective naming of content-addressed mutable data. This naming function is related to, and an extension of, hash-based naming.<br />
<br />
A common operation in software engineering is to use cryptographic hash functions to create short identifiers for large pieces of data. This is useful because hash values are easy to communicate since they are short, and also are easy to check since they are deterministic. This means if you know the name of some piece of data, you can independently verify that you have the correct copy of it. But the limitation of hash-based naming is that the named data can never change.<br />
<br />
Smart property overcomes this limitation. Because of a Bitcoin feature (OP_RETURN) that allows arbitrary data to be attached to transactions, every time smart property is moved it can be associated with a new hash. This means if data is identified by a smart property identifier instead of using the hash, the identifier of the smart property can objectively and unambiguously identify the most current version of the data.<br />
<br />
==Transaction-based Coloring==<br />
<br />
Transaction based coloring defines a set of tokens using a genesis outpoint, and a color kernel.<br />
<br />
===Genesis outpoint===<br />
<br />
The genesis outpoint is a named outpoint (transaction hash, output index) in the blockchain. It functions as the head of the tree where the outpoints created by transaction which consumes it, and all descendants of those outpoints, potentially inherit a portion of the genesis transaction's color balance.<br />
<br />
===Color balance===<br />
<br />
The color balance of an outpoint is a quantity which represents some blockchain-external unit. The color balance is encoded into the satoshi balance of an outpoint, but they are not equal.<br />
<br />
It's normally not practical to encode a 1:1 relationship between the color balance and the satoshi value of an output, because blockchain anti-spam rules makes the creation of very small value outputs impractical.<br />
<br />
To account for this, most coloring techniques use a padding system where an extra satoshi amount is added to each output to fulfill minimum output size rules.<br />
<br />
The color balance of an outpoint can then be calculated by subtracting the padding from the satoshi amount.<br />
<br />
===Color Kernel===<br />
<br />
A color kernel is a set of rules which are applied to a transaction to calculate the color balance of the outputs.<br />
<br />
The rules which make up a color kernel may consider any or all of:<br />
<br />
* The color balance of all inputs<br />
* The relative position of outputs relative to inputs<br />
* The relative size of outputs<br />
* The details of the script associated with outputs<br />
* Information encoded in the transaction header fields, such as <code>nSequence</code>.<br />
<br />
After applying a color kernel to a transaction with colored inputs, the color balance of each output is known. Starting from the genesis outpoint, the color kernel can be recursively applied to all descendant transactions in the blockchain until the present position of all colored units can be located.<br />
<br />
Because kernel rules are not enforced by the underlying network, it's possible to create colored coin transactions improperly such that the resulting outpoints do not contain a color balance. This is known as "destroying" colored coins.<br />
<br />
Color kernels are typically identified with a 3-5 character code.<br />
<br />
====Common Color kernels====<br />
<br />
; EPOBC (enhanced, padded, order-based coloring)<br />
: This kernel was created by Chromawallet and is suitable for creating ticket virtual tokens. As implemented in Chromawallet, it does have a limited ability implement certificate virtual tokens.<br />
; SPOBC (smart property order-based coloring)<br />
: This kernel was created by Monetas and is a derivation of EPOBC optimized for creating smart property virtual tokens. Unlike EPOBC, SPOBC tokens have a fixed color balance of one and may not be subdivided.<br />
; DHKEC (diffie-hellman key exchange coloring)<br />
: This kernel was created by Monetas and is a derivation of EPOBC optimized for creating certificate virtual tokens. The DHKEC kernel imposes a restriction on allowed script types to those which expose an ECDSA public key in the blockchain. This allows for payments to be sent to addresses derived via ECDH, which helps maintain the non-colored payment segregated from the colored tokens.<br />
<br />
===Color descriptors===<br />
<br />
Color descriptors provide a URI-like method for identifying issued virtual tokens. The form of a color descriptor is:<br />
<br />
<code><br />
<pre><br />
kernel name : colon-seperated parameter list</pre><br />
</code><br />
<br />
All currently-defined kernels use the same list of parameters:<br />
<br />
<code><br />
<pre>genesis outpoint txid : genesis outpoint index : genesis outpoint block height</pre><br />
</code><br />
<br />
[[Category:Bitcoin Terms]]<br />
[[Category:Voting Pool Terms]]</div>Justusranvierhttp://opentransactions.org/wiki/index.php?title=Wallet_(blockchain)&diff=3122Wallet (blockchain)2014-11-12T13:00:09Z<p>Justusranvier: /* Deposits */</p>
<hr />
<div>==Introduction==<br />
<br />
In order to avoid ambiguity, the terms "blockchain wallet" and "blockchain address" refers to the cryptocurrency for which is pool is tracking receipts. This differentiation is necessary to avoid confusion with [[wallet_(OT)|OT wallets]] or [[nym|nym addresses]].<br />
<br />
==Responsibilities==<br />
<br />
The blockchain wallet tracks and manipulates cryptocurrencies balances on the appropriate blockchain. The wallet notifies the [[auditor]] of received deposits, constructs outgoing transactions, and monitors the state of all relevant incoming and outgoing transactions.<br />
<br />
An auditor requires access to a wallet provider for every cryptocurrency its operator wishes to accept deposits for, and this wallet must support the [[Voting Pool Wallet API]].<br />
<br />
Wallets should understand both hierarchical determinism and multisig capability, and also output coloring.<br />
<br />
==Operations==<br />
<br />
===Address Identification===<br />
<br />
All components of a voting pool, except for the blockchain wallet, must be currency-agnostic and do not have any inherent understanding of currency-specific parameters such as address formats.<br />
<br />
Because of this, all addresses are passed as a set of index numbers. These numbers represent the parameters which can deterministically generate the underlying blockchain address from the voting pool asset contract.<br />
<br />
The numbers are grouped into two identifiers based on the resolution needed for common operations.<br />
<br />
====Series Identifier====<br />
<br />
Since one wallet will need to handle multiple pools and series, a series identifier must include the pool for which it belongs.<br />
<br />
A series identifier is defined as JSON object and is composed of two parts:<br />
<br />
;Pool<br />
:UUID for a specific voting pool. This UUID is persistent even as members are added or removed.<br />
<br />
;Series<br />
:An index number that starts at 1 and increases monotonically (from the [[Keyset (voting pools)|Keyset Definition]])<br />
<br />
=====Schema=====<br />
<br />
<include src="https://raw.githubusercontent.com/Open-Transactions/rfc/master/json/schema/seriesid-01.json" /><br />
<br />
=====Example=====<br />
<br />
<include src="https://raw.githubusercontent.com/Open-Transactions/rfc/master/json/data/seriesid-01.json" /><br />
<br />
====Address Identifier====<br />
<br />
An address identifier is defined as a JSON object and is composed of three parts:<br />
<br />
;Series<br />
:The series identifier which contains the address<br />
<br />
;Branch<br />
:0 for change addresses, 1-through-n for deposit addresses.<br />
<br />
Note the branch represents the position of a server’s [[xpub]] in the standard order for a given series. The auditor must reference the [[Keyset (voting pools)|keyset definition]] to obtain the correct notary ID-to-branch mapping for a given series since the standard order will change between series.<br />
<br />
;Index<br />
:The index applied to the [[xpub|xpubs]] in a given series to obtain the desired multisig output script.<br />
<br />
When the auditor needs to query a specific address from the blockchain wallet, will pass the address identifier instead of a raw blockchain address or script.<br />
<br />
=====Schema=====<br />
<br />
<include src="https://raw.githubusercontent.com/Open-Transactions/rfc/master/json/schema/addressid-01.json" /><br />
<br />
=====Example=====<br />
<br />
<include src="https://raw.githubusercontent.com/Open-Transactions/rfc/master/json/data/addressid-01.json" /><br />
<br />
===Wallet Creation===<br />
<br />
When an auditor first initializes a voting pool contract, it must create the appropriate cryptocurrency wallets via the [[Createseries]] call to a wallet provider of the appropriate coin type (Bitcoin, Litecoin, etc).<br />
<br />
The auditor must call this function for every defined series in the keyset.<br />
<br />
When the extended private keys for a series are brought online, the wallet must call [[Thawseries]] to load them into the blockchain wallet.<br />
<br />
The wallet must find the correct extended public key when it adds the extended private key to the wallet and must return an error to the operator if he attempts to load and extended private key for an extended public key not defined in that series.<br />
<br />
===Deposits===<br />
<br />
The wallet provides a deposit scripts for an address when requested via the [[getdepositscript]] call which may be wrapped a [[Payment Protocol (voting pools)|PaymentRequest]] and passed to the depositor.<br />
<br />
When a deposit is received, or if the confirmation status of the incoming transaction changes unexpectedly, the wallet will inform the caller via push notifications.<br />
<br />
[[Category:Voting Pool Components]]</div>Justusranvierhttp://opentransactions.org/wiki/index.php?title=Notary_(voting_pools)&diff=3121Notary (voting pools)2014-11-12T12:59:06Z<p>Justusranvier: /* Responsibilities */</p>
<hr />
<div>==Introduction==<br />
<br />
When a [[Notary]] is operates as part of a [[Voting Pools|voting pool]], it additional requirements apply on top of its existing functionality.<br />
<br />
==Responsibilities==<br />
<br />
The Notary must keep track of all blockchain-denominated balances via OT receipts. In addition to the separate account(s) for each customer, the server must track a service account to hold the blockchain-denominated balance owned by the service itself.<br />
<br />
If necessary, the server should also maintain an application account to hold the balance of any funds which are being manipulated by an external system. <br />
<br />
For example, in the case of a high-frequency exchange, the application account would belong to the order matching engine. When a customer enters a trade, the exchange front-end will call the applicable OT functions to transfer the appropriate balance from the selling customer’s OT account to the application OT account, and also from the application account back to the the appropriate purchasing customer’s OT account. Any trade fees that the exchange earns would be sent to the service account as part of the transaction. This separation of application account, service account, and customer account, prevents the mingling of funds.<br />
<br />
The Notary is also responsible for passing [[Payment Protocol (voting pools)|PaymentRequests]] from the [[Auditor (voting pools)|Auditor]] to the customer, crediting customer balances after the successful receipt of a blockchain deposit, and passing withdrawal requests to the rest of the voting pool via the audit servers.<br />
<br />
The Notary must maintain a permanent deposit database containing each PaymentRequest generated for that server and its associated status (number of blockchain confirmations and the OT receipt crediting the appropriate Nym with the deposit)<br />
<br />
== Audit Stream ==<br />
<br />
The Notary must broadcast five types of messages in an indexed and hash-chained sequence which form an Audit Stream.<br />
<br />
The five types of messages are:<br />
# Update to an inbox<br />
# Update to an outbox<br />
# Update to an account balance file<br />
# Update to a Nym box file<br />
# All Notary replies to transaction requests.<br />
<br />
[[Category:Voting Pool Components]]</div>Justusranvierhttp://opentransactions.org/wiki/index.php?title=Category:Voting_Pools&diff=3120Category:Voting Pools2014-11-12T12:54:52Z<p>Justusranvier: /* Overview */</p>
<hr />
<div><div class="toclimit-2">__TOC__</div><br />
<br />
==Introduction==<br />
<br />
Voting pools are an arrangement of OT transaction servers to securely store and account for customer cryptocurrency deposits, and to redeem valid withdrawal requests even in the event the custodial entity has completely disappeared. They are designed to ensure that no single person or organization can ever perform unilateral actions on deposited funds in order to reduce the risk of loss or theft, and custodial liability.<br />
<br />
By forming voting pools, users of OT can create and transact in financial instruments which are based on Bitcoin (or other blockchain-based cryptocurrencies), and it's possible to create exchanges which can not lose or steal customer cryptocurrency deposits. Voting pools are a "best of both worlds" merger between trustless blockchain technology and high speed server-mediated transactions.<br />
<br />
===Role of Open-Transactions===<br />
<br />
Open-Transactions (OT) is a financial cryptography library that implements triple entry accounting with destructible receipts. OT allows creditors to issue liabilities in the form of digitally signed and notarized receipts whose balances can be traded as currency and are available for manipulation via smart contracts and other financial instruments. Transactions are constructed by users and notarized by [[Notary (voting pools)| third party witnesses]]. OT maintains a real-time, cryptographically secured state of all liability balances for a given issuance type. Account balances in OT are protected from tampering with strong cryptography, which eliminates the co-mingling of funds between unrelated accounts. As an accounting system, OT does not normally have the ability to manipulate actual underlying assets, such as physical gold reserves.<br />
<br />
Unlike other technologies for creating financial instruments in blockchain currencies, Open-Transactions does not use or require special tokens.<br />
<br />
===Role of Bitcoin===<br />
<br />
Bitcoin is a digital asset ledger that includes its own currency and payment system. Bitcoins are not backed by any issuer, and therefore carry no counterparty risk. The validity of the global Bitcoin ledger (blockchain) is enforced by a global P2P network which requires, on average, ten minutes to update.<br />
<br />
===Applications of voting pools===<br />
<br />
With regards to OT, Bitcoin (and other cryptocurrencies) form a unique case. Since cryptocurrencies can be manipulated digitally in the way that other assets can not, OT servers can provide additional functions beyond merely ownership accounting. Importantly, in the case of cryptocurrencies, OT can provide auditing and safe storage of reserves on the blockchain itself. Since OT servers can process transactions more rapidly and inexpensively than a blockchain, it is desirable in many cases to allow an OT server to handle financial transactions off-chain, rather than performing them directly on the blockchain itself.<br />
<br />
Many services in the cryptocurrency space already require this functionality. Currency exchanges and other trading platforms usually desire to perform order matching more rapidly than what is possible on the blockchain itself. These services accept custody of user funds, perform transactions in a separate off-chain system, and use a database to track customer balances. Typically these services are not cryptographically secured, or independently auditable. Customers also give full control of their deposited funds to the custodial service, which exposes them to the risk of theft or loss of their coins.<br />
<br />
Unlike legacy currencies, cryptocurrencies can be irrevocably lost or stolen, and it’s typically not possible to distinguish between insider or external theft. Historically, this ambiguity appears to have been routinely exploited.<br />
<br />
Voting pools are an open standard intended to be a universal replacement for bespoke systems that handle customer cryptocurrency deposits.<br />
<br />
==Overview==<br />
<br />
[[File:Voting Pools Diagram NT.png|800px]]<br />
<br />
Voting pools bridge two worlds - OT and Bitcoin (cryptocurrency). The OT Voting Pool system consists of transaction servers, audit servers, and Bitcoin wallets held by wallet providers. OT tracks the BTC-denominated balances of every user of a service (down to 16 decimal places currently), as well any "service" balances that may be held by the transaction servers. The [[Notary (voting pools)|Notary]] is the portion of a voting pool which is closest to the users themselves. Users can interact with notaries through software user-interface clients that generate API function calls, or directly through client-side scripts containing OT API function calls. The Notary acts as a backend processor for a deposit-accepting business (such as a currency exchange or issuer), and handles all issues related to cryptocurrency deposits, withdrawals, and balance updates.<br />
<br />
The transaction server and the bitcoin wallet communicate via an [[Audit Server (voting pools)|Auditor]]. The Auditor independently verifies the OT operations of all transaction servers in the voting pool, as well as the bitcoins held by the pool on the blockchain itself. It uses this audit data to know when it should direct the wallet to create a withdrawal transaction, and it is also the component responsible for information sharing and achieving consensus between all members of the pool. It is the Auditors and the wallets who hold the keys to creating transactions at the request of the user, and the Auditors must all act by consensus and with the cooperation of the wallet to create multi-signature blockchain transactions.<br />
<br />
In order to manage the actual bitcoins held by the pool, each transaction server has a corresponding blockchain [[Wallet (blockchain)|wallet]]. The wallet software manages a hierarchical and deterministic list of addresses and the multi-signature transaction generation. The blockchain wallet supports standard cryptocurrency balances and separate tracking of colored coins. Most funds are held in a cold-wallet system where human interaction by multiple independent operators is required to rotate to a new sequence of hot-wallet addresses, and the blockchain wallet supports a formal "cold" state for addresses which require a signed consensus message to become "hot". Wallet providers maintain platforms robust enough to handle peak deposit and withdrawal volumes experienced by a popular service.<br />
<br />
==Security==<br />
<br />
===Goals===<br />
<br />
In order to achieve the desired security and robustness goals for voting pools, the following criteria are enforced:<br />
<br />
#Customers should be strongly discouraged from reusing deposit addresses. The voting pool itself must never intentionally reuse a bitcoin address.<br />
#All Bitcoin addresses used by the pool must be deterministic for auditing purposes. Each member of the pool should be able to calculate all members’ series of deposit and change addresses.<br />
#Withdrawal transaction input selection must be deterministic in order to minimise the cost of coordinating transaction signing.<br />
#It must be possible to keep a majority of the private keys offline for security reasons, and bring them online as needed to process withdrawals.<br />
#It must be possible to alter the voting pool by adding, removing, or replacing members in a coordinated and secure fashion.<br />
<br />
===Model===<br />
<br />
The goal of the voting pool security model is that users of deposit-accepting services should never experience a loss of deposited funds.<br />
<br />
We can group the various ways in which this goal might not be met into two general categories:<br />
<br />
;Type 1 Event ('''Theft/Loss''')<br />
:A user permanently loses their funds because a third party has gained control of them without the user’s consent, or because the private keys needed to spend them have been irrevocably lost.<br />
<br />
;Type 2 Event ('''Denial of Service''')<br />
:A user temporarily loses some or all of their ability to use their funds, but no third party has gained control over them.<br />
<br />
Type 0 Events will be used to describe all other abnormal conditions from which the pool must recover which do not directly involve a loss of customer deposits.<br />
<br />
<br />
====Voting Pool Security Theorem====<br />
<br />
If the probability of <code>m+1</code> (Type 1 Event) or <code>n-m+1</code> (Type 2 Event) services simultaneously and identically behaving in a malicious or incompetent manner is lower than the probability of any individual server behaving in a malicious or incompetent manner, user deposits on that service are at less risk of loss if the service is a member of an <code>m-of-n</code> voting pool than they would be at risk if the service is not a member of a voting pool.<br />
<br />
Voting pools can guarantee the integrity of user deposits if, in any given situation, at least <code>m</code> pool members are well-behaving for Type 1 events and at least <code>n-m</code> pool members are well-behaving for Type 2 events.</div>Justusranvierhttp://opentransactions.org/wiki/index.php?title=Category:Voting_Pools&diff=3119Category:Voting Pools2014-11-12T12:54:00Z<p>Justusranvier: /* Overview */</p>
<hr />
<div><div class="toclimit-2">__TOC__</div><br />
<br />
==Introduction==<br />
<br />
Voting pools are an arrangement of OT transaction servers to securely store and account for customer cryptocurrency deposits, and to redeem valid withdrawal requests even in the event the custodial entity has completely disappeared. They are designed to ensure that no single person or organization can ever perform unilateral actions on deposited funds in order to reduce the risk of loss or theft, and custodial liability.<br />
<br />
By forming voting pools, users of OT can create and transact in financial instruments which are based on Bitcoin (or other blockchain-based cryptocurrencies), and it's possible to create exchanges which can not lose or steal customer cryptocurrency deposits. Voting pools are a "best of both worlds" merger between trustless blockchain technology and high speed server-mediated transactions.<br />
<br />
===Role of Open-Transactions===<br />
<br />
Open-Transactions (OT) is a financial cryptography library that implements triple entry accounting with destructible receipts. OT allows creditors to issue liabilities in the form of digitally signed and notarized receipts whose balances can be traded as currency and are available for manipulation via smart contracts and other financial instruments. Transactions are constructed by users and notarized by [[Notary (voting pools)| third party witnesses]]. OT maintains a real-time, cryptographically secured state of all liability balances for a given issuance type. Account balances in OT are protected from tampering with strong cryptography, which eliminates the co-mingling of funds between unrelated accounts. As an accounting system, OT does not normally have the ability to manipulate actual underlying assets, such as physical gold reserves.<br />
<br />
Unlike other technologies for creating financial instruments in blockchain currencies, Open-Transactions does not use or require special tokens.<br />
<br />
===Role of Bitcoin===<br />
<br />
Bitcoin is a digital asset ledger that includes its own currency and payment system. Bitcoins are not backed by any issuer, and therefore carry no counterparty risk. The validity of the global Bitcoin ledger (blockchain) is enforced by a global P2P network which requires, on average, ten minutes to update.<br />
<br />
===Applications of voting pools===<br />
<br />
With regards to OT, Bitcoin (and other cryptocurrencies) form a unique case. Since cryptocurrencies can be manipulated digitally in the way that other assets can not, OT servers can provide additional functions beyond merely ownership accounting. Importantly, in the case of cryptocurrencies, OT can provide auditing and safe storage of reserves on the blockchain itself. Since OT servers can process transactions more rapidly and inexpensively than a blockchain, it is desirable in many cases to allow an OT server to handle financial transactions off-chain, rather than performing them directly on the blockchain itself.<br />
<br />
Many services in the cryptocurrency space already require this functionality. Currency exchanges and other trading platforms usually desire to perform order matching more rapidly than what is possible on the blockchain itself. These services accept custody of user funds, perform transactions in a separate off-chain system, and use a database to track customer balances. Typically these services are not cryptographically secured, or independently auditable. Customers also give full control of their deposited funds to the custodial service, which exposes them to the risk of theft or loss of their coins.<br />
<br />
Unlike legacy currencies, cryptocurrencies can be irrevocably lost or stolen, and it’s typically not possible to distinguish between insider or external theft. Historically, this ambiguity appears to have been routinely exploited.<br />
<br />
Voting pools are an open standard intended to be a universal replacement for bespoke systems that handle customer cryptocurrency deposits.<br />
<br />
==Overview==<br />
<br />
[[File:Voting Pools Diagram NT.png|800px]]<br />
<br />
Voting pools bridge two worlds - OT and Bitcoin (cryptocurrency). The OT Voting Pool system consists of transaction servers, audit servers, and Bitcoin wallets held by wallet providers. OT tracks the BTC-denominated balances of every user of a service (down to 16 decimal places currently), as well any "service" balances that may be held by the transaction servers. The [[Notary (voting pools)|Notary] is the portion of a voting pool which is closest to the users themselves. Users can interact with notaries through software user-interface clients that generate API function calls, or directly through client-side scripts containing OT API function calls. The Notary acts as a backend processor for a deposit-accepting business (such as a currency exchange or issuer), and handles all issues related to cryptocurrency deposits, withdrawals, and balance updates.<br />
<br />
The transaction server and the bitcoin wallet communicate via an [[Audit Server (voting pools)|Auditor]]. The Auditor independently verifies the OT operations of all transaction servers in the voting pool, as well as the bitcoins held by the pool on the blockchain itself. It uses this audit data to know when it should direct the wallet to create a withdrawal transaction, and it is also the component responsible for information sharing and achieving consensus between all members of the pool. It is the Auditors and the wallets who hold the keys to creating transactions at the request of the user, and the Auditors must all act by consensus and with the cooperation of the wallet to create multi-signature blockchain transactions.<br />
<br />
In order to manage the actual bitcoins held by the pool, each transaction server has a corresponding blockchain [[Wallet (blockchain)|wallet]]. The wallet software manages a hierarchical and deterministic list of addresses and the multi-signature transaction generation. The blockchain wallet supports standard cryptocurrency balances and separate tracking of colored coins. Most funds are held in a cold-wallet system where human interaction by multiple independent operators is required to rotate to a new sequence of hot-wallet addresses, and the blockchain wallet supports a formal "cold" state for addresses which require a signed consensus message to become "hot". Wallet providers maintain platforms robust enough to handle peak deposit and withdrawal volumes experienced by a popular service.<br />
<br />
==Security==<br />
<br />
===Goals===<br />
<br />
In order to achieve the desired security and robustness goals for voting pools, the following criteria are enforced:<br />
<br />
#Customers should be strongly discouraged from reusing deposit addresses. The voting pool itself must never intentionally reuse a bitcoin address.<br />
#All Bitcoin addresses used by the pool must be deterministic for auditing purposes. Each member of the pool should be able to calculate all members’ series of deposit and change addresses.<br />
#Withdrawal transaction input selection must be deterministic in order to minimise the cost of coordinating transaction signing.<br />
#It must be possible to keep a majority of the private keys offline for security reasons, and bring them online as needed to process withdrawals.<br />
#It must be possible to alter the voting pool by adding, removing, or replacing members in a coordinated and secure fashion.<br />
<br />
===Model===<br />
<br />
The goal of the voting pool security model is that users of deposit-accepting services should never experience a loss of deposited funds.<br />
<br />
We can group the various ways in which this goal might not be met into two general categories:<br />
<br />
;Type 1 Event ('''Theft/Loss''')<br />
:A user permanently loses their funds because a third party has gained control of them without the user’s consent, or because the private keys needed to spend them have been irrevocably lost.<br />
<br />
;Type 2 Event ('''Denial of Service''')<br />
:A user temporarily loses some or all of their ability to use their funds, but no third party has gained control over them.<br />
<br />
Type 0 Events will be used to describe all other abnormal conditions from which the pool must recover which do not directly involve a loss of customer deposits.<br />
<br />
<br />
====Voting Pool Security Theorem====<br />
<br />
If the probability of <code>m+1</code> (Type 1 Event) or <code>n-m+1</code> (Type 2 Event) services simultaneously and identically behaving in a malicious or incompetent manner is lower than the probability of any individual server behaving in a malicious or incompetent manner, user deposits on that service are at less risk of loss if the service is a member of an <code>m-of-n</code> voting pool than they would be at risk if the service is not a member of a voting pool.<br />
<br />
Voting pools can guarantee the integrity of user deposits if, in any given situation, at least <code>m</code> pool members are well-behaving for Type 1 events and at least <code>n-m</code> pool members are well-behaving for Type 2 events.</div>Justusranvierhttp://opentransactions.org/wiki/index.php?title=File:Voting_Pools_Diagram_NT.png&diff=3118File:Voting Pools Diagram NT.png2014-11-12T12:51:12Z<p>Justusranvier: Justusranvier uploaded a new version of &quot;File:Voting Pools Diagram NT.png&quot;</p>
<hr />
<div>Design by Jonathan Vaage <jonvaage@gmail.com></div>Justusranvierhttp://opentransactions.org/wiki/index.php?title=Category:Voting_Pools&diff=3117Category:Voting Pools2014-11-12T12:48:12Z<p>Justusranvier: /* Role of Open-Transactions */</p>
<hr />
<div><div class="toclimit-2">__TOC__</div><br />
<br />
==Introduction==<br />
<br />
Voting pools are an arrangement of OT transaction servers to securely store and account for customer cryptocurrency deposits, and to redeem valid withdrawal requests even in the event the custodial entity has completely disappeared. They are designed to ensure that no single person or organization can ever perform unilateral actions on deposited funds in order to reduce the risk of loss or theft, and custodial liability.<br />
<br />
By forming voting pools, users of OT can create and transact in financial instruments which are based on Bitcoin (or other blockchain-based cryptocurrencies), and it's possible to create exchanges which can not lose or steal customer cryptocurrency deposits. Voting pools are a "best of both worlds" merger between trustless blockchain technology and high speed server-mediated transactions.<br />
<br />
===Role of Open-Transactions===<br />
<br />
Open-Transactions (OT) is a financial cryptography library that implements triple entry accounting with destructible receipts. OT allows creditors to issue liabilities in the form of digitally signed and notarized receipts whose balances can be traded as currency and are available for manipulation via smart contracts and other financial instruments. Transactions are constructed by users and notarized by [[Notary (voting pools)| third party witnesses]]. OT maintains a real-time, cryptographically secured state of all liability balances for a given issuance type. Account balances in OT are protected from tampering with strong cryptography, which eliminates the co-mingling of funds between unrelated accounts. As an accounting system, OT does not normally have the ability to manipulate actual underlying assets, such as physical gold reserves.<br />
<br />
Unlike other technologies for creating financial instruments in blockchain currencies, Open-Transactions does not use or require special tokens.<br />
<br />
===Role of Bitcoin===<br />
<br />
Bitcoin is a digital asset ledger that includes its own currency and payment system. Bitcoins are not backed by any issuer, and therefore carry no counterparty risk. The validity of the global Bitcoin ledger (blockchain) is enforced by a global P2P network which requires, on average, ten minutes to update.<br />
<br />
===Applications of voting pools===<br />
<br />
With regards to OT, Bitcoin (and other cryptocurrencies) form a unique case. Since cryptocurrencies can be manipulated digitally in the way that other assets can not, OT servers can provide additional functions beyond merely ownership accounting. Importantly, in the case of cryptocurrencies, OT can provide auditing and safe storage of reserves on the blockchain itself. Since OT servers can process transactions more rapidly and inexpensively than a blockchain, it is desirable in many cases to allow an OT server to handle financial transactions off-chain, rather than performing them directly on the blockchain itself.<br />
<br />
Many services in the cryptocurrency space already require this functionality. Currency exchanges and other trading platforms usually desire to perform order matching more rapidly than what is possible on the blockchain itself. These services accept custody of user funds, perform transactions in a separate off-chain system, and use a database to track customer balances. Typically these services are not cryptographically secured, or independently auditable. Customers also give full control of their deposited funds to the custodial service, which exposes them to the risk of theft or loss of their coins.<br />
<br />
Unlike legacy currencies, cryptocurrencies can be irrevocably lost or stolen, and it’s typically not possible to distinguish between insider or external theft. Historically, this ambiguity appears to have been routinely exploited.<br />
<br />
Voting pools are an open standard intended to be a universal replacement for bespoke systems that handle customer cryptocurrency deposits.<br />
<br />
==Overview==<br />
<br />
[[File:Voting Pools Diagram NT.png|800px]]<br />
<br />
Voting pools bridge two worlds - OT and Bitcoin (cryptocurrency). The OT Voting Pool system consists of transaction servers, audit servers, and Bitcoin wallets held by wallet providers. OT tracks the BTC-denominated balances of every user of a service (down to 16 decimal places currently), as well any "service" balances that may be held by the transaction servers. The OT [[Transaction Server (voting pools)|transaction server]] is the portion of a voting pool which is closest to the users themselves. Users can interact with transaction servers through software user-interface "clients" that generate API function calls, or directly through client-side scripts containing OT API function calls. The transaction server acts as a backend processor for a deposit-accepting business (such as a currency exchange or issuer), and handles all issues related to cryptocurrency deposits, withdrawals, and balance updates.<br />
<br />
The transaction server and the bitcoin wallet communicate via an [[Audit Server (voting pools)|auditing server]]. The auditing server independently verifies the OT operations of all transaction servers in the voting pool, as well as the bitcoins held by the pool on the blockchain itself. It uses this audit data to know when it should direct the wallet to create a withdrawal transaction, and it is also the component responsible for information sharing and achieving consensus between all members of the pool. It is the audit servers and the wallets who hold the keys to creating transactions at the request of the user, and the audit servers must all act by consensus and with the cooperation of the wallet to create multi-signature blockchain transactions.<br />
<br />
In order to manage the actual bitcoins held by the pool, each transaction server has a corresponding Bitcoin [[Wallet (blockchain)|wallet]]. The wallet software manages a hierarchical and deterministic list of addresses and the multi-signature transaction generation. The Bitcoin wallet supports standard cryptocurrency balances and separate tracking of colored coins. Most funds are held in a cold-wallet system where human interaction by multiple independent audit server operators is required to rotate to a new sequence of hot-wallet addresses, and the bitcoin wallet supports a formal "cold" state for addresses which require a signed consensus message to become "hot". Wallet providers maintain platforms robust enough to handle peak deposit and withdrawal volumes experienced by a popular service.<br />
<br />
==Security==<br />
<br />
===Goals===<br />
<br />
In order to achieve the desired security and robustness goals for voting pools, the following criteria are enforced:<br />
<br />
#Customers should be strongly discouraged from reusing deposit addresses. The voting pool itself must never intentionally reuse a bitcoin address.<br />
#All Bitcoin addresses used by the pool must be deterministic for auditing purposes. Each member of the pool should be able to calculate all members’ series of deposit and change addresses.<br />
#Withdrawal transaction input selection must be deterministic in order to minimise the cost of coordinating transaction signing.<br />
#It must be possible to keep a majority of the private keys offline for security reasons, and bring them online as needed to process withdrawals.<br />
#It must be possible to alter the voting pool by adding, removing, or replacing members in a coordinated and secure fashion.<br />
<br />
===Model===<br />
<br />
The goal of the voting pool security model is that users of deposit-accepting services should never experience a loss of deposited funds.<br />
<br />
We can group the various ways in which this goal might not be met into two general categories:<br />
<br />
;Type 1 Event ('''Theft/Loss''')<br />
:A user permanently loses their funds because a third party has gained control of them without the user’s consent, or because the private keys needed to spend them have been irrevocably lost.<br />
<br />
;Type 2 Event ('''Denial of Service''')<br />
:A user temporarily loses some or all of their ability to use their funds, but no third party has gained control over them.<br />
<br />
Type 0 Events will be used to describe all other abnormal conditions from which the pool must recover which do not directly involve a loss of customer deposits.<br />
<br />
<br />
====Voting Pool Security Theorem====<br />
<br />
If the probability of <code>m+1</code> (Type 1 Event) or <code>n-m+1</code> (Type 2 Event) services simultaneously and identically behaving in a malicious or incompetent manner is lower than the probability of any individual server behaving in a malicious or incompetent manner, user deposits on that service are at less risk of loss if the service is a member of an <code>m-of-n</code> voting pool than they would be at risk if the service is not a member of a voting pool.<br />
<br />
Voting pools can guarantee the integrity of user deposits if, in any given situation, at least <code>m</code> pool members are well-behaving for Type 1 events and at least <code>n-m</code> pool members are well-behaving for Type 2 events.</div>Justusranvierhttp://opentransactions.org/wiki/index.php?title=Startwithdrawal&diff=3116Startwithdrawal2014-11-07T10:29:23Z<p>Justusranvier: /* Errors */</p>
<hr />
<div>==Description==<br />
<br />
This call begins the process of creating withdrawal transactions to satisfy validated [[outBailment]] messages.<br />
<br />
After receiving this call, the wallet attempts to construct blockchain transactions to satisfy the requested ouputs using the [[Transaction Construction Algorithm (voting pools)|transaction construction algorithm]].<br />
<br />
==Status==<br />
<br />
;Version 1 Draft<br />
:This specificiation is still under development<br />
<br />
==Arguments==<br />
<br />
; version<br />
: Currently required to be 1. May be incremented for future expansions to the voting pool specification.<br />
<br />
; roundID<br />
: A positive integer representing the [[Consensus Process (voting pools)|consensus round]] for which the withdrawal is associated<br />
<br />
; inputstart<br />
: An [[Wallet_(blockchain)#Address_Identification|address identifier]] identifying where the [[Input Selection Algorithm (voting pools)|input selection algorithm]] should begin searching for eligible inputs<br />
<br />
; inputstop<br />
: An [[Wallet_(blockchain)#Series_Identification|series identifier]] identifying where the [[Input Selection Algorithm (voting pools)|input selection algorithm]] should stop searching for eligible inputs. Since each wallet can not know when the other wallets in the pool have thawed a new series, the auditors must collect this information themselves and pass it explicitly to make sure transaction generation is deterministic.<br />
<br />
; dustthreshold<br />
: A positive integer representing the minimum valid input size for the input selection algorithm, in the fundamental accounting unit for the currency (for Bitcoin, one [[satoshi]])<br />
<br />
; changestart<br />
: An [[Wallet_(blockchain)#Address_Identification|address identifier]] identifying the first change address to be used<br />
<br />
; outputs<br />
: An [[outputs (Voting Pool Wallet API)| output list]] containing the outputs to be created during the current consensus round.<br />
<br />
==Return Values==<br />
<br />
===Data===<br />
<br />
; status<br />
: A [[withdrawal status | withdrawal status list]] containing accounting information and transaction IDs corresponging to each output in the the output list<br />
<br />
; signatures<br />
: A [[siglist|signature list]] for the inputs in the created transactions to be shared with other members of the voting pool.<br />
<br />
===Errors===<br />
<br />
; unknown version<br />
: The wallet does not support the supplied version number.<br />
; invalid roundID<br />
: the supplied roundID is not a positive integer<br />
; duplicate roundID<br />
: the supplied roundID has already been passed to a previous startwithdrawal call with a different set of arguments<br />
; inputstart invalid pool<br />
: The given pool is not defined in the wallet.<br />
; inputstart invalid series<br />
: The given series is not defined in the wallet.<br />
; inputstart invalid branch<br />
: The given branch is not defined in the wallet.<br />
; inputstart invalid index<br />
: The index supplied is not a positive integer between 0 an 2<sup>31</sup>.<br />
; inputstart frozen series<br />
: The series indicated is not hot<br />
; inputstop invalid pool<br />
: The given pool is not defined in the wallet.<br />
; inputstop invalid series<br />
: The given series is not defined in the wallet.<br />
; invalid dustthreshold<br />
: The dusthreshold is not a positive integer between 0 and 2100000000000000<br />
; changestart invalid pool<br />
: The given pool is not defined in the wallet.<br />
; changestart invalid series<br />
: The given series is not defined in the wallet.<br />
; changestart invalid branch<br />
: The given branch is not defined in the wallet.<br />
; changestart invalid index<br />
: The index supplied is not a positive integer between 0 an 2<sup>31</sup>.<br />
; changestart series not active<br />
: The [[charter output]] for the pool is not located at the 0<sup>th</sup> [[change address]] for the given series, or the next series.<br />
<br />
[[Category:Voting Pool Wallet API]]</div>Justusranvierhttp://opentransactions.org/wiki/index.php?title=Startwithdrawal&diff=3115Startwithdrawal2014-11-07T10:19:57Z<p>Justusranvier: /* Errors */</p>
<hr />
<div>==Description==<br />
<br />
This call begins the process of creating withdrawal transactions to satisfy validated [[outBailment]] messages.<br />
<br />
After receiving this call, the wallet attempts to construct blockchain transactions to satisfy the requested ouputs using the [[Transaction Construction Algorithm (voting pools)|transaction construction algorithm]].<br />
<br />
==Status==<br />
<br />
;Version 1 Draft<br />
:This specificiation is still under development<br />
<br />
==Arguments==<br />
<br />
; version<br />
: Currently required to be 1. May be incremented for future expansions to the voting pool specification.<br />
<br />
; roundID<br />
: A positive integer representing the [[Consensus Process (voting pools)|consensus round]] for which the withdrawal is associated<br />
<br />
; inputstart<br />
: An [[Wallet_(blockchain)#Address_Identification|address identifier]] identifying where the [[Input Selection Algorithm (voting pools)|input selection algorithm]] should begin searching for eligible inputs<br />
<br />
; inputstop<br />
: An [[Wallet_(blockchain)#Series_Identification|series identifier]] identifying where the [[Input Selection Algorithm (voting pools)|input selection algorithm]] should stop searching for eligible inputs. Since each wallet can not know when the other wallets in the pool have thawed a new series, the auditors must collect this information themselves and pass it explicitly to make sure transaction generation is deterministic.<br />
<br />
; dustthreshold<br />
: A positive integer representing the minimum valid input size for the input selection algorithm, in the fundamental accounting unit for the currency (for Bitcoin, one [[satoshi]])<br />
<br />
; changestart<br />
: An [[Wallet_(blockchain)#Address_Identification|address identifier]] identifying the first change address to be used<br />
<br />
; outputs<br />
: An [[outputs (Voting Pool Wallet API)| output list]] containing the outputs to be created during the current consensus round.<br />
<br />
==Return Values==<br />
<br />
===Data===<br />
<br />
; status<br />
: A [[withdrawal status | withdrawal status list]] containing accounting information and transaction IDs corresponging to each output in the the output list<br />
<br />
; signatures<br />
: A [[siglist|signature list]] for the inputs in the created transactions to be shared with other members of the voting pool.<br />
<br />
===Errors===<br />
<br />
; unknown version<br />
: The wallet does not support the supplied version number.<br />
; invalid roundID<br />
: the supplied roundID is not a positive integer<br />
; duplicate roundID<br />
: the supplied roundID has already been passed to a previous startwithdrawal call<br />
; inputstart invalid pool<br />
: The given pool is not defined in the wallet.<br />
; inputstart invalid series<br />
: The given series is not defined in the wallet.<br />
; inputstart invalid branch<br />
: The given branch is not defined in the wallet.<br />
; inputstart invalid index<br />
: The index supplied is not a positive integer between 0 an 2<sup>31</sup>.<br />
; inputstart frozen series<br />
: The series indicated is not hot<br />
; inputstop invalid pool<br />
: The given pool is not defined in the wallet.<br />
; inputstop invalid series<br />
: The given series is not defined in the wallet.<br />
; invalid dustthreshold<br />
: The dusthreshold is not a positive integer between 0 and 2100000000000000<br />
; changestart invalid pool<br />
: The given pool is not defined in the wallet.<br />
; changestart invalid series<br />
: The given series is not defined in the wallet.<br />
; changestart invalid branch<br />
: The given branch is not defined in the wallet.<br />
; changestart invalid index<br />
: The index supplied is not a positive integer between 0 an 2<sup>31</sup>.<br />
; changestart series not active<br />
: The [[charter output]] for the pool is not located at the 0<sup>th</sup> [[change address]] for the given series, or the next series.<br />
<br />
[[Category:Voting Pool Wallet API]]</div>Justusranvierhttp://opentransactions.org/wiki/index.php?title=Startwithdrawal&diff=3114Startwithdrawal2014-11-07T10:19:18Z<p>Justusranvier: /* Errors */</p>
<hr />
<div>==Description==<br />
<br />
This call begins the process of creating withdrawal transactions to satisfy validated [[outBailment]] messages.<br />
<br />
After receiving this call, the wallet attempts to construct blockchain transactions to satisfy the requested ouputs using the [[Transaction Construction Algorithm (voting pools)|transaction construction algorithm]].<br />
<br />
==Status==<br />
<br />
;Version 1 Draft<br />
:This specificiation is still under development<br />
<br />
==Arguments==<br />
<br />
; version<br />
: Currently required to be 1. May be incremented for future expansions to the voting pool specification.<br />
<br />
; roundID<br />
: A positive integer representing the [[Consensus Process (voting pools)|consensus round]] for which the withdrawal is associated<br />
<br />
; inputstart<br />
: An [[Wallet_(blockchain)#Address_Identification|address identifier]] identifying where the [[Input Selection Algorithm (voting pools)|input selection algorithm]] should begin searching for eligible inputs<br />
<br />
; inputstop<br />
: An [[Wallet_(blockchain)#Series_Identification|series identifier]] identifying where the [[Input Selection Algorithm (voting pools)|input selection algorithm]] should stop searching for eligible inputs. Since each wallet can not know when the other wallets in the pool have thawed a new series, the auditors must collect this information themselves and pass it explicitly to make sure transaction generation is deterministic.<br />
<br />
; dustthreshold<br />
: A positive integer representing the minimum valid input size for the input selection algorithm, in the fundamental accounting unit for the currency (for Bitcoin, one [[satoshi]])<br />
<br />
; changestart<br />
: An [[Wallet_(blockchain)#Address_Identification|address identifier]] identifying the first change address to be used<br />
<br />
; outputs<br />
: An [[outputs (Voting Pool Wallet API)| output list]] containing the outputs to be created during the current consensus round.<br />
<br />
==Return Values==<br />
<br />
===Data===<br />
<br />
; status<br />
: A [[withdrawal status | withdrawal status list]] containing accounting information and transaction IDs corresponging to each output in the the output list<br />
<br />
; signatures<br />
: A [[siglist|signature list]] for the inputs in the created transactions to be shared with other members of the voting pool.<br />
<br />
===Errors===<br />
<br />
; unknown version<br />
: The wallet does not support the supplied version number.<br />
; invalid roundID<br />
: the supplied roundID is not a positive integer<br />
; duplicate roundID<br />
: the supplied roundID has already been passed to a previous startWithdrawal call<br />
; inputstart invalid pool<br />
: The given pool is not defined in the wallet.<br />
; inputstart invalid series<br />
: The given series is not defined in the wallet.<br />
; inputstart invalid branch<br />
: The given branch is not defined in the wallet.<br />
; inputstart invalid index<br />
: The index supplied is not a positive integer between 0 an 2<sup>31</sup>.<br />
; inputstart frozen series<br />
: The series indicated is not hot<br />
; inputstop invalid pool<br />
: The given pool is not defined in the wallet.<br />
; inputstop invalid series<br />
: The given series is not defined in the wallet.<br />
; invalid dustthreshold<br />
: The dusthreshold is not a positive integer between 0 and 2100000000000000<br />
; changestart invalid pool<br />
: The given pool is not defined in the wallet.<br />
; changestart invalid series<br />
: The given series is not defined in the wallet.<br />
; changestart invalid branch<br />
: The given branch is not defined in the wallet.<br />
; changestart invalid index<br />
: The index supplied is not a positive integer between 0 an 2<sup>31</sup>.<br />
; changestart series not active<br />
: The [[charter output]] for the pool is not located at the 0<sup>th</sup> [[change address]] for the given series, or the next series.<br />
<br />
[[Category:Voting Pool Wallet API]]</div>Justusranvierhttp://opentransactions.org/wiki/index.php?title=Finalize_Transaction&diff=3110Finalize Transaction2014-11-04T11:14:42Z<p>Justusranvier: /* Initial Conditions */</p>
<hr />
<div><div style="float: right"><include iframe src="https://www.lucidchart.com/documents/embeddedchart/79c726f4-9d4e-4a3c-bd20-6556099d24ab" width="300" height="1004" frameborder="0" scrolling="yes" /></div><br />
<br />
==Initial Conditions==<br />
<br />
* An unfinished transaction is ready for processing.<br />
** The transaction may or may not have have an output<br />
** The transaction is valid<br />
*** Not too big<br />
*** Inputs are sufficient to cover outputs and required fees<br />
** A change output does not yet exist in the transaction<br />
*** A change output may be added without causing the transaction to exceed size limits OR no change will be required (as in the case of a split output)<br />
<br />
==Sequence==<br />
<br />
# If the transaction contains no outputs and no inputs, then it may be discarded.<br />
# The change amount is calculated by: Σ(txin) - ( Σ(txout) + fees )<br />
## If the change amount is greater than zero:<br />
### Add a change output of the appropriate value<br />
### Increment the <code>nextchangestart</code> object in the withdrawal status list<br />
# Calculate an [[ntxid]] for the transaction for tracking purposes.<br />
# Loop through every (non-change) output in the transaction and update the [[withdrawal status]] object for the corresponding output.<br />
## The withdrawal status object contain an entry for every output in the transaction, where each entry has an <code>outpoints</code> object containing a nil <code>ntxid</code>, an <code>index</code> matching the output position index, and a matching <code>amount</code>.<br />
## Update the <code>ntxid</code> value from nil to the ntxid for the transaction.<br />
# Add the fees from this transaction to the <code>fees</code> property of the withdrawal status object.<br />
# Move the transaction to the finished transaction list.<br />
<br />
[[Category:Transaction Construction Algorithm (voting pools)|05]]</div>Justusranvierhttp://opentransactions.org/wiki/index.php?title=Split_Output&diff=3109Split Output2014-11-04T11:14:04Z<p>Justusranvier: </p>
<hr />
<div><div style="float: right"><include iframe src="https://www.lucidchart.com/documents/embeddedchart/c72ce59c-65c0-4a90-943a-c669bac5a737" width="300" height="1004" frameborder="0" scrolling="yes" /></div><br />
<br />
This procedure is used when, either due to a large output or small inputs, the inputs required to satisfy a single output can not fit within transaction size limits.<br />
<br />
The <code>outBailment</code> will be split across two or more transactions.<br />
<br />
==Initial Conditions==<br />
<br />
* The transaction being constructed contains one output, and many inputs.<br />
* The transaction did not exceed any size limits until the most recent input was added.<br />
<br />
==Sequence==<br />
<br />
# Remove the most-recently added input.<br />
# Update the value of the output in the transaction to be the sum of the inputs minus the required transaction fee.<br />
# Make a copy of the [[Outputs (Voting Pool Wallet API)|outputs]] object corresponding to this outBailmentID.<br />
# Update the <code>amount</code> field of the copied output by subtracting the value determined in step 4.<br />
# Push this new output to the output stack.<br />
# Update the <code>status</code> field for this outBailmentID in the [[withdrawal status]] object to "partial-".<br />
# Perform the [[Finalize Transaction]] Procedure.<br />
# [[Initialize New Transaction|Initialize]] a new transaction.<br />
<br />
[[Category:Transaction Construction Algorithm (voting pools)|12]]</div>Justusranvierhttp://opentransactions.org/wiki/index.php?title=Finalize_Transaction&diff=3108Finalize Transaction2014-11-04T11:09:54Z<p>Justusranvier: </p>
<hr />
<div><div style="float: right"><include iframe src="https://www.lucidchart.com/documents/embeddedchart/79c726f4-9d4e-4a3c-bd20-6556099d24ab" width="300" height="1004" frameborder="0" scrolling="yes" /></div><br />
<br />
==Initial Conditions==<br />
<br />
* An unfinished transaction is ready for processing.<br />
** The transaction may or may not have have an output<br />
** The transaction is valid<br />
*** Not too big<br />
*** Inputs are sufficient to cover outputs and required fees<br />
** A change output does not yet exist in the transaction<br />
*** A change output may be added without causing the transaction to exceed size limits<br />
<br />
==Sequence==<br />
<br />
# If the transaction contains no outputs and no inputs, then it may be discarded.<br />
# The change amount is calculated by: Σ(txin) - ( Σ(txout) + fees )<br />
## If the change amount is greater than zero:<br />
### Add a change output of the appropriate value<br />
### Increment the <code>nextchangestart</code> object in the withdrawal status list<br />
# Calculate an [[ntxid]] for the transaction for tracking purposes.<br />
# Loop through every (non-change) output in the transaction and update the [[withdrawal status]] object for the corresponding output.<br />
## The withdrawal status object contain an entry for every output in the transaction, where each entry has an <code>outpoints</code> object containing a nil <code>ntxid</code>, an <code>index</code> matching the output position index, and a matching <code>amount</code>.<br />
## Update the <code>ntxid</code> value from nil to the ntxid for the transaction.<br />
# Add the fees from this transaction to the <code>fees</code> property of the withdrawal status object.<br />
# Move the transaction to the finished transaction list.<br />
<br />
[[Category:Transaction Construction Algorithm (voting pools)|05]]</div>Justusranvierhttp://opentransactions.org/wiki/index.php?title=Add_Next_Output&diff=3107Add Next Output2014-11-04T11:01:58Z<p>Justusranvier: /* Sequence */</p>
<hr />
<div><div style="float: right"><include iframe src="https://www.lucidchart.com/documents/embeddedchart/3e9b2758-338e-40f7-8fe2-e036fda68157" width="600" height="800" frameborder="0" scrolling="yes" /></div><br />
<br />
==Initial Conditions==<br />
<br />
The output stack contains at least one output.<br />
<br />
There is a transaction in progress which is ready to accept new outputs. This transaction is either empty or it contains 1 or more outputs.<br />
<br />
If the transaction already contains outputs, then it also contains sufficient inputs to cover those outputs and any required transaction fees without exceeding size limits. This is because it must have already successfully passed through this procedure before.<br />
<br />
==Sequence==<br />
<br />
# Locate the entry for this output in the [[Withdrawal status|withdrawal status]] object by finding the corresponding outBailmentID.<br />
# Validate the output address.<br />
## If it is invalid, update <code>status</code> entry for this output to "invalid" and exit from this procedure.<br />
## If it is valid, add it to the transaction.<br />
### Add a new entry to the <code>transaction</code> array for this output:<br />
###* <code>ntxid</code>: nil<br />
###* <code>index</code>: next unused<br />
###* <code>amount</code>: copied from [[Outputs (Voting Pool Wallet API)|outputs]] list.<br />
# Check that the transaction does not exceed [[Initialize_New_Transaction#Size checking|size limits]]. If it does, follow the [[Oversize Transaction]] procedure.<br />
# Compare the sum of the inputs to the sum of the outputs and required transaction fee to determine if more inputs are required.<br />
## If no more inputs are required, then update the <code>status</code> for this output to "success".<br />
# If more inputs are required, then check to see if any more are available.<br />
## According to the initial conditions, the input stack can not be empty on the first run through this loop.<br />
## If the input stack is empty at this point, then the output has added at least one input beyond what was needed to satisfy the prior output (if there was a prior output)<br />
## If the input stack is empty, then the output can only be partially fulfilled. Follow the [[Split Output]] procedure.<br />
# Add the next input from the stack, and continue the loop at step 2.<br />
<br />
The loop will continue until either:<br />
<br />
* The transaction contains sufficient input value to satisfy the output plus transaction fees<br />
* The transaction exceeds size limits<br />
* There is not enough input value, but no more inputs are available<br />
<br />
[[Category:Transaction Construction Algorithm (voting pools)|04]]</div>Justusranvierhttp://opentransactions.org/wiki/index.php?title=Initialize_New_Transaction&diff=3106Initialize New Transaction2014-11-04T11:01:08Z<p>Justusranvier: /* Sequence */</p>
<hr />
<div><div style="float: right"><include iframe src="https://www.lucidchart.com/documents/embeddedchart/506ed019-070c-44d6-b5e4-994169ab0704" width="150" height="250" frameborder="0" scrolling="yes" /></div><br />
<br />
==Initial Conditions==<br />
<br />
* There are no pending transactions in the process of being constructed, either because this is the first transaction of the algorithm or because a previous pending transaction has been moved to the finished transaction list.<br />
<br />
==Sequence==<br />
<br />
# Create a minimal transaction skeleton with a header and no inputs or outputs.<br />
## We expect the transaction to have one change output, but it can not be added yet since it should appear last.<br />
## The change output must be included in the skeleton for transaction size calculations.<br />
<br />
After creating the transaction skeleton, and after any action which alters it, the new transaction size (bytes) and minimum required transaction fee must be recalculated.<br />
<br />
===Size checking===<br />
Size checking is performed by creating a copy of the transaction, adding a dummy change output, and verifying that the transaction fits within all applicable limits.<br />
<br />
[[Category:Transaction Construction Algorithm (voting pools)|03]]</div>Justusranvierhttp://opentransactions.org/wiki/index.php?title=Initialize_New_Transaction&diff=3105Initialize New Transaction2014-11-04T11:00:05Z<p>Justusranvier: </p>
<hr />
<div><div style="float: right"><include iframe src="https://www.lucidchart.com/documents/embeddedchart/506ed019-070c-44d6-b5e4-994169ab0704" width="150" height="250" frameborder="0" scrolling="yes" /></div><br />
<br />
==Initial Conditions==<br />
<br />
* There are no pending transactions in the process of being constructed, either because this is the first transaction of the algorithm or because a previous pending transaction has been moved to the finished transaction list.<br />
<br />
==Sequence==<br />
<br />
# Create a minimal transaction skeleton with a header and no inputs or outputs.<br />
## We expect the transaction to have one change output, but it can not be added yet since it should appear last.<br />
## The change output must be included in the skeleton for transaction size calculations.<br />
<br />
After creating the transaction skeleton, and after any action which alters it, the new transaction size (bytes) and minimum required transaction fee must be recalculated.<br />
<br />
Size checking is performed by creating a copy of the transaction, adding a dummy change output, and verifying that the transaction fits within all applicable limits.<br />
<br />
[[Category:Transaction Construction Algorithm (voting pools)|03]]</div>Justusranvierhttp://opentransactions.org/wiki/index.php?title=Transaction_Construction_Algorithm_(voting_pools)&diff=3102Transaction Construction Algorithm (voting pools)2014-10-22T14:55:07Z<p>Justusranvier: Redirected page to Category:Transaction Construction Algorithm (voting pools)</p>
<hr />
<div>#REDIRECT [[:Category:Transaction Construction Algorithm (voting pools)]]</div>Justusranvierhttp://opentransactions.org/wiki/index.php?title=Category:Transaction_Construction_Algorithm_(voting_pools)&diff=3101Category:Transaction Construction Algorithm (voting pools)2014-10-22T14:52:48Z<p>Justusranvier: Created page with "==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 determinis..."</p>
<hr />
<div>==Introduction==<br />
<br />
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.<br />
<br />
==Procedure==<br />
<br />
===Overview===<br />
<br />
<div style="float: right"><include iframe src="https://www.lucidchart.com/documents/embeddedchart/eb960c32-71d4-4cfc-8f49-63a82b343608/0" width="300" height="1004" frameborder="0" scrolling="yes" /></div><br />
<br />
====Initial Conditions====<br />
<br />
The [[startwithdrawal]] API call has been received by the wallet, and all the arguments have been checked for errors.<br />
<br />
====Sequence====<br />
<br />
The basic flow of the procedure is:<br />
<br />
# [[Preparation|Gather accounting information]] from the API call arguments<br />
# [[Output List Initialization|Validate and sort]] the output list<br />
# [[Initialize New Transaction|Start]] a new transactions<br />
# [[Add Next Output|Add outputs]] to the transaction until either all outputs are added or all inputs are used.<br />
# [[Finalize Transaction|Verify]] all generated transactions are ready for signing.<br />
# [[Update Signatures|Create a list]] of all signatures which the wallet is capable of generating.<br />
# [[Update Status|Create a status list]] containing the deposition of every output the caller specified.<br />
# Return the status list and signature list to the caller.<br />
<br />
Each step in this chart is more fully described on the pages listed below.<br />
<br />
{{clear}}<br />
<br />
[[Category:Voting Pool Technical Specifications]]</div>Justusranvierhttp://opentransactions.org/wiki/index.php?title=Oversize_Transaction&diff=3100Oversize Transaction2014-10-22T14:43:57Z<p>Justusranvier: </p>
<hr />
<div><div style="float: right"><include iframe src="https://www.lucidchart.com/documents/embeddedchart/4abd7b4f-1079-48d7-af9d-d892433cd65a" width="300" height="400" frameborder="0" scrolling="yes" /></div><br />
<br />
An oversize transaction may occur while attempting to add inputs to satisfy an output which has been added to a transaction as part of the [[Add Next Output]] step.<br />
<br />
Even with the worst case of high <code>m</code> and/or <code>n</code> values, inputs will never be large enough that a transaction can be oversized while attempting to add the first input to a transaction.<br />
<br />
Oversize transactions will have one change output, at least one non-change output, and many inputs.<br />
<br />
If an oversize has two or more non-change outputs, then Add Next Output was successful for the previous output. In this case, the transaction was valid before attempting to add the current output, so the current output should be removed from the current transaction and moved to the next one.<br />
<br />
Otherwise, the transaction has become too large while adding its first non-change output. This can happen due to a series of small inputs, or a large output, or a combination of the two. In this case the [[outBailment]] can not be satisfied with a single transaction and must be split across multiple transactions.<br />
<br />
==Initial Conditions==<br />
<br />
* The Add Next Output procedure has created a transaction that exceeds size limits, in one of the following circumstances:<br />
** Immediately upon adding an output to the transaction<br />
*** The transaction contains other outputs which were added successfully. All inputs currently in the transaction are required to satisfy the previous output(s) before the output that failed.<br />
** After adding the first input to the transaction to satisfy an output<br />
*** The transaction contains other outputs which were added successfully. All inputs currently in the transaction are required to satisfy the previous output(s) before the output that failed.<br />
** After having added at least one input to the transaction to satisfy an output without causing an oversize condition.<br />
*** At least one of the inputs in this transaction are only required to satisfy the current output, not any previous outputs (if any exist).<br />
<br />
==Procedure==<br />
<br />
# Count the number of non-change outputs in the transaction.<br />
# If the number exceeds one, follow the [[Rollback Last Output]] procedure.<br />
# If the number is one, follow the [[Split Output]] procedure.<br />
<br />
[[Category:Transaction Construction Algorithm (voting pools)|10]]</div>Justusranvierhttp://opentransactions.org/wiki/index.php?title=Rollback_Last_Output&diff=3099Rollback Last Output2014-10-22T14:41:23Z<p>Justusranvier: </p>
<hr />
<div><div style="float: right"><include iframe src="https://www.lucidchart.com/documents/embeddedchart/81fbb6f6-b150-4a06-915e-7633b05da9af" width="300" height="600" frameborder="0" scrolling="yes" /></div><br />
<br />
This procedure is used if a transaction has exceeded the size limit, and can be brought back under the limit by removing the most-recently added output and the inputs needed to support it from the transaction <br />
<br />
The removed inputs and outputs will be added to the beginning of a new transaction.<br />
<br />
This procedure will remove one more input than is required to bring the transaction below size limits, and then add exactly one more. This will always result in a valid transaction because the only way to reach this procedure is by having successfully completed at least one [[Add Next Output]] cycle for the current transaction prior to adding an output or input that pushes the transaction over the size limit.<br />
<br />
==Initial Conditions==<br />
<br />
* An oversize transaction contains one or more outputs and their supporting inputs which do not exceed transaction size limits, and one output which does not.<br />
* The number of inputs which are solely dedicated to satisfying the most recently-added output (not required for previous outputs) may be zero or more.<br />
<br />
==Sequence==<br />
<br />
# Remove the most-recently added output from the transaction and return it to the output stack.<br />
#* This will cause the output to be the first one added to the next transaction.<br />
# Remove the most-recently added input from the transaction and return it to the input stack.<br />
# If the sum of input values exceeds the sum of output values by an amount greater than the required transaction fee:<br />
#* Continue removing inputs one at a time until the sum of the input values falls below the needed output + transaction fee value.<br />
# Add the next input from the stack to the transaction.<br />
# Perform the [[Finalize Transaction]] procedure.<br />
# [[Initialize New Transaction|Initialize]] a new transaction.<br />
<br />
[[Category:Transaction Construction Algorithm (voting pools)|11]]</div>Justusranvierhttp://opentransactions.org/wiki/index.php?title=Split_Output&diff=3098Split Output2014-10-22T14:40:38Z<p>Justusranvier: </p>
<hr />
<div><div style="float: right"><include iframe src="https://www.lucidchart.com/documents/embeddedchart/c72ce59c-65c0-4a90-943a-c669bac5a737" width="300" height="1004" frameborder="0" scrolling="yes" /></div><br />
<br />
This procedure is used when, either due to a large output or small inputs, the inputs required to satisfy a single output can not fit within transaction size limits.<br />
<br />
The <code>outBailment</code> will be split across two or more transactions.<br />
<br />
==Initial Conditions==<br />
<br />
* The transaction being constructed contains one change output, one non-change output, and many inputs.<br />
* The transaction did not exceed any size limits until the most recent input was added.<br />
<br />
==Sequence==<br />
<br />
# Remove the change output from the transaction.<br />
# Decrement the value of the <code>nextchangestart</code> property of the [[withdrawal status]] object.<br />
# Determine if the transaction still exceeds size limits.<br />
## If yes, then remove the most-recently added input.<br />
# Update the value of the output in the transaction to be the sum of the inputs minus the required transaction fee.<br />
# Make a copy of the [[Outputs (Voting Pool Wallet API)|outputs]] object corresponding to this outBailmentID.<br />
# Update the <code>amount</code> field of the copied output by subtracting the value determined in step 4.<br />
# Push this new output to the output stack.<br />
# Update the <code>status</code> field for this outBailmentID in the [[withdrawal status]] object to "partial-".<br />
# Perform the [[Finalize Transaction]] Procedure.<br />
# [[Initialize New Transaction|Initialize]] a new transaction.<br />
<br />
[[Category:Transaction Construction Algorithm (voting pools)|12]]</div>Justusranvierhttp://opentransactions.org/wiki/index.php?title=Insufficient_Inputs&diff=3097Insufficient Inputs2014-10-22T14:39:18Z<p>Justusranvier: </p>
<hr />
<div><div style="float: right"><include iframe src="https://www.lucidchart.com/documents/embeddedchart/9b471e6e-0a62-408a-ad0e-a5d7c491aa43" width="150" height="500" frameborder="0" scrolling="yes" /></div><br />
<br />
This procedure is followed when the [[Output List Initialization]] step estimated that that the input list was sufficient to fulfill the valid outputs but, due to change and/or transaction fees, one or more outputs can not be fulfilled.<br />
<br />
==Initial Conditions==<br />
<br />
* [[Add Next Output]] has been completed successfully at least once.<br />
* An empty transaction skeleton has been created.<br />
* At least one output remains in the stack, but the input stack is empty.<br />
<br />
==Sequence==<br />
<br />
* Pop all outputs from the output stack and update their <code>status</code> property in the [[withdrawal status]] list to "partial-".<br />
<br />
No further action is necessary. After completing this procedure the algorithm moves on to the [[Finalize Transaction]] procedure which will discard the empty transaction skeleton which would have otherwise contained the outputs which were processed in this procedure.<br />
<br />
[[Category:Transaction Construction Algorithm (voting pools)|13]]</div>Justusranvierhttp://opentransactions.org/wiki/index.php?title=Insufficient_Inputs&diff=3096Insufficient Inputs2014-10-22T14:36:52Z<p>Justusranvier: Created page with "<div style="float: right"><include iframe src="https://www.lucidchart.com/documents/embeddedchart/9b471e6e-0a62-408a-ad0e-a5d7c491aa43" width="150" height="500" frameborder="0..."</p>
<hr />
<div><div style="float: right"><include iframe src="https://www.lucidchart.com/documents/embeddedchart/9b471e6e-0a62-408a-ad0e-a5d7c491aa43" width="150" height="500" frameborder="0" scrolling="yes" /></div><br />
<br />
This procedure is followed when the [[Output List Initialization]] step estimated that that the input list was sufficient to fulfill the valid outputs but, due to change and/or transaction fees, one or more outputs can not be fulfilled.<br />
<br />
==Initial Conditions==<br />
<br />
* [[#Add Next Output|Add Next Output]] has been completed successfully at least once.<br />
* An empty transaction skeleton has been created.<br />
* At least one output remains in the stack, but the input stack is empty.<br />
<br />
==Sequence==<br />
<br />
* Pop all outputs from the output stack and update their <code>status</code> property in the [[withdrawal status]] list to "partial-".<br />
<br />
No further action is necessary. After completing this procedure the algorithm moves on to the [[#Finalize Transaction|Finalize Transaction]] procedure which will discard the empty transaction skeleton which would have otherwise contained the outputs which were processed in this procedure.<br />
<br />
[[Category:Transaction Construction Algorithm (voting pools)|11]]</div>Justusranvierhttp://opentransactions.org/wiki/index.php?title=Split_Output&diff=3095Split Output2014-10-22T14:35:45Z<p>Justusranvier: Created page with "<div style="float: right"><include iframe src="https://www.lucidchart.com/documents/embeddedchart/c72ce59c-65c0-4a90-943a-c669bac5a737" width="300" height="1004" frameborder="..."</p>
<hr />
<div><div style="float: right"><include iframe src="https://www.lucidchart.com/documents/embeddedchart/c72ce59c-65c0-4a90-943a-c669bac5a737" width="300" height="1004" frameborder="0" scrolling="yes" /></div><br />
<br />
This procedure is used when, either due to a large output or small inputs, the inputs required to satisfy a single output can not fit within transaction size limits.<br />
<br />
The outBailment will be split across two or more transactions.<br />
<br />
==Initial Conditions==<br />
<br />
* The transaction being constructed contains one change output, one non-change output, and many inputs.<br />
* The transaction did not exceed any size limits until the most recent input was added.<br />
<br />
==Sequence==<br />
<br />
# Remove the change output from the transaction.<br />
# Decrement the value of the <code>nextchangestart</code> property of the [[withdrawal status]] object.<br />
# Determine if the transaction still exceeds size limits.<br />
## If yes, then remove the most-recently added input.<br />
# Update the value of the output in the transaction to be the sum of the inputs minus the required transaction fee.<br />
# Make a copy of the [[Outputs (Voting Pool Wallet API)|outputs]] object corresponding to this outBailmentID.<br />
# Update the <code>amount</code> field of the copied output by subtracting the value determined in step 4.<br />
# Push this new output to the output stack.<br />
# Update the <code>status</code> field for this outBailmentID in the [[withdrawal status]] object to "partial-".<br />
# Perform the [[Finalize Transaction]] Procedure.<br />
# [[Initialize Transaction|Initialize]] a new transaction.<br />
<br />
[[Category:Transaction Construction Algorithm (voting pools)|10]]</div>Justusranvierhttp://opentransactions.org/wiki/index.php?title=Rollback_Last_Output&diff=3094Rollback Last Output2014-10-22T14:34:52Z<p>Justusranvier: Created page with "<div style="float: right"><include iframe src="https://www.lucidchart.com/documents/embeddedchart/81fbb6f6-b150-4a06-915e-7633b05da9af" width="300" height="600" frameborder="0..."</p>
<hr />
<div><div style="float: right"><include iframe src="https://www.lucidchart.com/documents/embeddedchart/81fbb6f6-b150-4a06-915e-7633b05da9af" width="300" height="600" frameborder="0" scrolling="yes" /></div><br />
<br />
This procedure is used if a transaction has exceeded the size limit, and can be brought back under the limit by removing the most-recently added output and the inputs needed to support it from the transaction <br />
<br />
The removed inputs and outputs will be added to the beginning of a new transaction.<br />
<br />
This procedure will remove one more input than is required to bring the transaction below size limits, and then add exactly one more. This will always result in a valid transaction because the only way to reach this procedure is by having successfully completed at least one [[Add Next Output]] cycle for the current transaction prior to adding an output or input that pushes the transaction over the size limit.<br />
<br />
==Initial Conditions==<br />
<br />
* An oversize transaction contains one or more outputs and their supporting inputs which do not exceed transaction size limits, and one output which does not.<br />
* The number of inputs which are solely dedicated to satisfying the most recently-added output (not required for previous outputs) may be zero or more.<br />
<br />
==Sequence==<br />
<br />
# Remove the most-recently added output from the transaction and return it to the output stack.<br />
#* This will cause the output to be the first one added to the next transaction.<br />
# Remove the most-recently added input from the transaction and return it to the input stack.<br />
# If the sum of input values exceeds the sum of output values by an amount greater than the required transaction fee:<br />
#* Continue removing inputs one at a time until the sum of the input values falls below the needed output + transaction fee value.<br />
# Add the next input from the stack to the transaction.<br />
# Perform the [[Finalize Transaction]] procedure.<br />
# [[Initialize Transaction|Initialize]] a new transaction.<br />
<br />
[[Category:Transaction Construction Algorithm (voting pools)|09]]</div>Justusranvierhttp://opentransactions.org/wiki/index.php?title=Oversize_Transaction&diff=3093Oversize Transaction2014-10-22T14:34:15Z<p>Justusranvier: Created page with "<div style="float: right"><include iframe src="https://www.lucidchart.com/documents/embeddedchart/4abd7b4f-1079-48d7-af9d-d892433cd65a" width="300" height="400" frameborder="0..."</p>
<hr />
<div><div style="float: right"><include iframe src="https://www.lucidchart.com/documents/embeddedchart/4abd7b4f-1079-48d7-af9d-d892433cd65a" width="300" height="400" frameborder="0" scrolling="yes" /></div><br />
<br />
An oversize transaction may occur while attempting to add inputs to satisfy an output which has been added to a transaction as part of the [[Add Next Output]] step.<br />
<br />
Even with the worst case of high <code>m</code> and/or <code>n</code> values, inputs will never be large enough that a transaction can be oversized while attempting to add the first input to a transaction.<br />
<br />
Oversize transactions will have one change output, at least one non-change output, and many inputs.<br />
<br />
If an oversize has two or more non-change outputs, then Add Next Output was successful for the previous output. In this case, the transaction was valid before attempting to add the current output, so the current output should be removed from the current transaction and moved to the next one.<br />
<br />
Otherwise, the transaction has become too large while adding its first non-change output. This can happen due to a series of small inputs, or a large output, or a combination of the two. In this case the [[outBailment]] can not be satisfied with a single transaction and must be split across multiple transactions.<br />
<br />
==Initial Conditions==<br />
<br />
* The Add Next Output procedure has created a transaction that exceeds size limits, in one of the following circumstances:<br />
** Immediately upon adding an output to the transaction<br />
*** The transaction contains other outputs which were added successfully. All inputs currently in the transaction are required to satisfy the previous output(s) before the output that failed.<br />
** After adding the first input to the transaction to satisfy an output<br />
*** The transaction contains other outputs which were added successfully. All inputs currently in the transaction are required to satisfy the previous output(s) before the output that failed.<br />
** After having added at least one input to the transaction to satisfy an output without causing an oversize condition.<br />
*** At least one of the inputs in this transaction are only required to satisfy the current output, not any previous outputs (if any exist).<br />
<br />
==Procedure==<br />
<br />
# Count the number of non-change outputs in the transaction.<br />
# If the number exceeds one, follow the [[Rollback Last Output]] procedure.<br />
# If the number is one, follow the [[Split Output]] procedure.<br />
<br />
[[Category:Transaction Construction Algorithm (voting pools)|08]]</div>Justusranvierhttp://opentransactions.org/wiki/index.php?title=Update_Status&diff=3092Update Status2014-10-22T14:33:20Z<p>Justusranvier: Created page with "<div style="float: right"><include iframe src="https://www.lucidchart.com/documents/embeddedchart/b4dcbb56-3b87-4f56-b249-dfd4276c7cc4" width="300" height="800" frameborder="0..."</p>
<hr />
<div><div style="float: right"><include iframe src="https://www.lucidchart.com/documents/embeddedchart/b4dcbb56-3b87-4f56-b249-dfd4276c7cc4" width="300" height="800" frameborder="0" scrolling="yes" /></div><br />
<br />
==Initial Conditions==<br />
<br />
* Every outBailmentID in the [[Outputs (Voting Pool Wallet API)|output]] list provided has a non-nil <code>status</code> value in the [[withdrawal status]] object.<br />
<br />
==Sequence==<br />
<br />
# Update the status for any split outBailments which exist:<br />
## Split outBailments have more than one item in their <code>transactions</code> array and have an existing <code>status</code> value of "success".<br />
## Change the <code>status</code> for all split outBailments from "success" to "split".<br />
# Update the status for any partial outBailments which exist:<br />
## Partial outBailments have existing <code>status</code> value of "partial-".<br />
## Calculate the total missing value needed to satisfy the partial outputs.<br />
## The missing value of an outBailment is the originally-requested size of the outBailment minus the sum of all outputs created to satisfy it (if any exist).<br />
### Obtain a list of eligible inputs from the next un-thawed series and calculate their total value.<br />
### If the eligible value of the next un-thawed series is greater than the total missing value, then the next un-thawed series is the target series.<br />
#### If not, repeat the above process while keeping a running total of eligible value until a target series is located.<br />
### Append the number of the target series to the <code>status</code> value for every partial series.<br />
# Update the <code>nextinputstart</code> value.<br />
## If the input stack is empty, <code>nextinputstart</code> is the first [[address identifier]] for the next un-thawed series.<br />
## If the input stack is not empty, <code>nextinputstart</code> is the [[address identifier]] for the next input in the stack.<br />
<br />
[[Category:Transaction Construction Algorithm (voting pools)|07]]</div>Justusranvierhttp://opentransactions.org/wiki/index.php?title=Update_Signatures&diff=3091Update Signatures2014-10-22T14:32:40Z<p>Justusranvier: Created page with "<div style="float: right"><include iframe src="https://www.lucidchart.com/documents/embeddedchart/97025b62-3720-4810-ae85-5ae678031aed" width="600" height="1100" frameborder="..."</p>
<hr />
<div><div style="float: right"><include iframe src="https://www.lucidchart.com/documents/embeddedchart/97025b62-3720-4810-ae85-5ae678031aed" width="600" height="1100" frameborder="0" scrolling="yes" /></div><br />
<br />
==Initial Conditions==<br />
<br />
* The finished transaction list contains zero or more finalized transactions <br />
* The transactions are valid in all respects except for missing signatures<br />
<br />
==Sequence==<br />
<br />
* If the finished transaction list is empty, the rest of the procedure can be skipped.<br />
* Loop through each transaction.<br />
** Within each transaction, loop through every input.<br />
*** Within each input, loop through every pubkey in the [[redeem script]].<br />
**** If the wallet possesses the private key corresponding to the pubkey, create the appropriate signature.<br />
***** Add the signature to the transaction.<br />
***** Add the signature to the [[siglist|signature list]] in the appropriate position.<br />
* Move all transactions in the finished transaction list to the pending transaction database, where they will wait for additional signatures from other voting pool members.<br />
<br />
[[Category:Transaction Construction Algorithm (voting pools)|06]]</div>Justusranvierhttp://opentransactions.org/wiki/index.php?title=Finalize_Transaction&diff=3090Finalize Transaction2014-10-22T14:29:42Z<p>Justusranvier: Created page with "<div style="float: right"><include iframe src="https://www.lucidchart.com/documents/embeddedchart/79c726f4-9d4e-4a3c-bd20-6556099d24ab" width="300" height="1004" frameborder="..."</p>
<hr />
<div><div style="float: right"><include iframe src="https://www.lucidchart.com/documents/embeddedchart/79c726f4-9d4e-4a3c-bd20-6556099d24ab" width="300" height="1004" frameborder="0" scrolling="yes" /></div><br />
<br />
==Initial Conditions==<br />
<br />
* An unfinished transaction is ready for processing.<br />
** The transaction may or may not have have a useful (non-change) output<br />
** The transaction is valid<br />
*** Not too big<br />
*** Inputs are sufficient to cover outputs and required fees<br />
** A change output may exist in the transaction<br />
*** If a change output exists, it has a nil position and a nil value.<br />
<br />
==Sequence==<br />
<br />
# If the transaction only contains a change output and no inputs, then it may be discarded.<br />
# The change amount is calculated by: Σ(txin) - ( Σ(txout) + fees )<br />
## If the change amount is greater than zero:<br />
### Set the value of the output<br />
### Set the position of the output to the next unused value after the last non-change output.<br />
## If the change amount is zero, then the change output is removed from the transaction.<br />
# Calculate an [[ntxid]] for the transaction for tracking purposes.<br />
# Loop through every (non-change) output in the transaction and update the [[withdrawal status]] object for the corresponding output.<br />
## The withdrawal status object contain an entry for every output in the transaction, where each entry has an <code>transactions</code> object containing a nil <code>ntxid</code>, an <code>index</code> matching the output position index, and a matching <code>amount</code>.<br />
## Update the <code>ntxid</code> value from nil to the ntxid for the transaction.<br />
# Add the fees from this transaction to the <code>fees</code> property of the withdrawal status object.<br />
# Move the transaction to the finished transaction list.<br />
<br />
[[Category:Transaction Construction Algorithm (voting pools)|05]]</div>Justusranvierhttp://opentransactions.org/wiki/index.php?title=Add_Next_Output&diff=3089Add Next Output2014-10-22T14:28:56Z<p>Justusranvier: Created page with "<div style="float: right"><include iframe src="https://www.lucidchart.com/documents/embeddedchart/3e9b2758-338e-40f7-8fe2-e036fda68157" width="600" height="800" frameborder="0..."</p>
<hr />
<div><div style="float: right"><include iframe src="https://www.lucidchart.com/documents/embeddedchart/3e9b2758-338e-40f7-8fe2-e036fda68157" width="600" height="800" frameborder="0" scrolling="yes" /></div><br />
<br />
==Initial Conditions==<br />
<br />
The output stack contains at least one output.<br />
<br />
There is a transaction in progress which is ready to accept new outputs. This transaction is either empty or it contains 1 or more outputs.<br />
<br />
If the transaction already contains outputs, then it also contains sufficient inputs to cover those outputs and any required transaction fees without exceeding size limits. This is because it must have already successfully passed through this procedure before.<br />
<br />
==Sequence==<br />
<br />
# Locate the entry for this output in the [[Withdrawal status|withdrawal status]] object by finding the corresponding outBailmentID.<br />
# Validate the output address.<br />
## If it is invalid, update <code>status</code> entry for this output to "invalid" and exit from this procedure.<br />
## If it is valid, add it to the transaction.<br />
### Add a new entry to the <code>transaction</code> array for this output:<br />
###* <code>ntxid</code>: nil<br />
###* <code>index</code>: next unused<br />
###* <code>amount</code>: copied from [[Outputs (Voting Pool Wallet API)|outputs]] list.<br />
# Check that the transaction does not exceed size limits. If it does, follow the [[Oversize Transaction]] procedure.<br />
# Compare the sum of the inputs to the sum of the outputs and required transaction fee to determine if more inputs are required.<br />
## If no more inputs are required, then update the <code>status</code> for this output to "success".<br />
# If more inputs are required, then check to see if any more are available.<br />
## According to the initial conditions, the input stack can not be empty on the first run through this loop.<br />
## If the input stack is empty at this point, then the output has added at least one input beyond what was needed to satisfy the prior output (if there was a prior output)<br />
## If the input stack is empty, then the output can only be partially fulfilled. Follow the [[Split Output]] procedure.<br />
# Add the next input from the stack, and continue the loop at step 2.<br />
<br />
The loop will continue until either:<br />
<br />
* The transaction contains sufficient input value to satisfy the output plus transaction fees<br />
* The transaction exceeds size limits<br />
* There is not enough input value, but no more inputs are available<br />
<br />
[[Category:Transaction Construction Algorithm (voting pools)|04]]</div>Justusranvierhttp://opentransactions.org/wiki/index.php?title=Initialize_New_Transaction&diff=3088Initialize New Transaction2014-10-22T14:28:00Z<p>Justusranvier: Created page with "<div style="float: right"><include iframe src="https://www.lucidchart.com/documents/embeddedchart/506ed019-070c-44d6-b5e4-994169ab0704" width="150" height="450" frameborder="0..."</p>
<hr />
<div><div style="float: right"><include iframe src="https://www.lucidchart.com/documents/embeddedchart/506ed019-070c-44d6-b5e4-994169ab0704" width="150" height="450" frameborder="0" scrolling="yes" /></div><br />
<br />
==Initial Conditions==<br />
<br />
* There are no pending transactions in the process of being constructed, either because this is the first transaction of the algorithm or because a previous pending transaction has been moved to the finished transaction list.<br />
<br />
==Sequence==<br />
<br />
# Create a minimal transaction skeleton with a header and one change output.<br />
## The change output will be the last output of the transaction, but the number of other outputs in this transaction is not yet known.<br />
## The change output must be included in the skeleton for transaction size calculations.<br />
## The position index for the change output is nil.<br />
## The first non-change output for the transaction will be placed at position index 0.<br />
<br />
After creating the transaction skeleton, and after any action which alters it, the new transaction size (bytes) and minimum required transaction fee must be recalculated.<br />
<br />
[[Category:Transaction Construction Algorithm (voting pools)|03]]</div>Justusranvierhttp://opentransactions.org/wiki/index.php?title=Output_List_Initialization&diff=3087Output List Initialization2014-10-22T14:27:15Z<p>Justusranvier: Created page with "<div style="float: right"><include iframe src="https://www.lucidchart.com/documents/embeddedchart/56b10d7d-bbd4-4590-8200-c837c5ad953c" width="450" height="800" frameborder="0..."</p>
<hr />
<div><div style="float: right"><include iframe src="https://www.lucidchart.com/documents/embeddedchart/56b10d7d-bbd4-4590-8200-c837c5ad953c" width="450" height="800" frameborder="0" scrolling="yes" /></div><br />
<br />
==Initial Conditions==<br />
<br />
The [[startwithdrawal]] API call has been received by the wallet, and all the arguments have been checked for errors.<br />
<br />
==Sequence==<br />
<br />
# Pass the <code>inputstart</code>, <code>inputstop</code>, and <code>dustthreshold</code> parameters to the [[Input Selection Algorithm (voting pools)|input selection algorithm]] to obtain an ordered list of eligible inputs.<br />
# Perform a first pass check to determine if the requested outputs exceed the size of the eligible inputs. Note that this check is only definitive in the case where the output sum is greater than the input sum. At this stage of the algorithm, the input sum exceeding the output sum does not prove that all outputs will be successfully created.<br />
## Take the sum of both lists.<br />
## If the sum of the outputs exceeds the sum of the inputs, remove outputs in descending size order until this is no longer true. Note this may result in the output list being an empty set.<br />
### Removed outputs are given a status of "partial-" at this stage. This status will be updated at the end of the procedure to include the series number which must be made hot to satisfy the outBailment.<br />
# If the output list is non-empty, sort it by <code>SHA256(server id, transaction number)</code> where the server id and transaction number come from the outBailmentID.<br />
## Express the server id and transaction number as strings, and concatenate them prior to hashing<br />
# Move both the input lists and outputs lists into separate stacks by pushing them in reverse list order. The first input and first output should be on the top of their respective stacks.<br />
<br />
[[Category:Transaction Construction Algorithm (voting pools)|02]]</div>Justusranvierhttp://opentransactions.org/wiki/index.php?title=Preparation&diff=3086Preparation2014-10-22T14:26:24Z<p>Justusranvier: Created page with "<div style="float: right"><include iframe src="https://www.lucidchart.com/documents/embeddedchart/0dd5f7d6-8511-4440-a535-32ad8508d146" width="150" height="502" frameborder="0..."</p>
<hr />
<div><div style="float: right"><include iframe src="https://www.lucidchart.com/documents/embeddedchart/0dd5f7d6-8511-4440-a535-32ad8508d146" width="150" height="502" frameborder="0" scrolling="yes" /></div><br />
<br />
==Initial Conditions==<br />
<br />
The [[startwithdrawal]] API call has been received by the wallet, and all the arguments have been checked for errors.<br />
<br />
==Sequence==<br />
<br />
# 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]].<br />
# Prepare an empty list for holding transactions as they are constructed and before they are signed.<br />
# Prepare an empty array to hold the transaction signatures which will be returned to the caller as the <code>[[siglist| signatures]]</code> value.<br />
# Prepare an <code>withdrawal status</code> object.<br />
## <code>roundID</code>: copied from <code>roundID</code> argument<br />
## <code>nextinputstart</code>: nil<br />
## <code>nextchangestart</code>: nil<br />
## <code>fees</code>: 0<br />
## <code>outputs</code>: should contain an entry for every output passed:<br />
### <code>outBailmentID</code>: copied from <code>outBailmentID</code> entry in <code>outputs</code> argument<br />
### <code>status</code>: empty string<br />
### <code>transactions</code>: nil<br />
<br />
[[Category:Transaction Construction Algorithm (voting pools)|01]]</div>Justusranvierhttp://opentransactions.org/wiki/index.php?title=Withdrawal_status&diff=3085Withdrawal status2014-10-21T14:46:04Z<p>Justusranvier: /* Status Codes */ department of redundancy department</p>
<hr />
<div>The [[startwithdrawal]] API call returns a list of accounting and status information corresponding to the transactions which it has created.<br />
<br />
The list is formated as a JSON object.<br />
<br />
==Schema==<br />
<br />
<include src="https://raw.githubusercontent.com/Open-Transactions/rfc/draft/json/schema/withdrawalstatus-01.json" /><br />
<br />
==Example==<br />
<br />
<include src="https://raw.githubusercontent.com/Open-Transactions/rfc/draft/json/data/withdrawalstatus-01.json" /><br />
<br />
==Status Codes==<br />
<br />
The status codes for an <code>outputs</code> object are as follows:<br />
<br />
; success<br />
: The amount requested by the originating nym's outBailment message was completely satisfied using a single transaction<br />
; split<br />
: The amount requested by the originating nym's outBailment message was completely satisfied using two or more transaction<br />
; partial-<n><br />
: The amount requested by the originating nym's outBailment message could not be completely satisfied due to a lack of hot inputs. Series up to <n> must be thawed to completely fulfil this outBailment. The transactions array for this entry may contain zero or more transactions.<br />
; invalid<br />
: The output address supplied by the outBailment is not valid.<br />
<br />
<br />
[[Category:Voting Pool Technical Specifications]]</div>Justusranvier