Open Transactions - User contributions [en]

Main Page

2014-10-15T11:56:59Z

Ttll: typo

==Open-Transactions==

The Open-Transactions project is a collaborative effort to develop a robust, commercial-grade, fully-featured, '''free-software toolkit''' implementing the [[OTX|OTX protocol]] as well as a full-strength '''financial cryptography''' [[List_of_Classes|library]], API, CLI, and prototype server. The project is managed by a worldwide community of volunteers that use the Internet to communicate, plan, and develop the Open-Transactions toolkit and its related documentation.

The biggest corporate sponsor of Open-Transactions development is [[Monetas]].

===Financial Cryptography===

Financial cryptography means using using strong cryptographic techniques to create secure financial instruments, such as digital signing to create non-repudiable contracts, and encryption to create unlinkable digital cash. In OT, transactions are unforgeable, receipts are destructible, and balances cannot be falsified or changed without user consent. OT is able to prove all balances, as well as which instruments are valid, and which transactions have closed, without storing any history except the last signed receipt.

Open-Transactions implements financial instruments as Ricardian Contracts; contracts which can be understood both by humans and manipulated by software.

All contracts in Open-Transactions use the same basic structure: all parties involved sign an agreement which is notarized by an independent third party witness. This technique is known as [[Triple-Signed Receipts]]. Furthermore, transactions are formed and signed on the client side, before being notarized by any server. This prevents the server from falsifying receipts, since the server can't forge the client's signature.

This basic structure can be built upon to create many types of financial instruments.

===Financial Instruments===

Financial instruments are any representation of a financial agreement between two or more parties.

The simplest financial instrument is a deposit agreement. A custodian of some asset (legal tender, or maybe gold) stores it on behalf of a depositor and agrees to redeem it on demand when presented with proof of a valid claim on the asset.

Other types of financial instruments include securities, of which there can be many variations. A security is an instrument that entitles the bearer to a certain revenue stream, either because it represents a loan or perhaps because it represents equity in a business.

Financial instruments in Open-Transactions have an issuer, who creates the contracts and is responsible for fulfilling the terms, and one or more bearers. Financial instruments are liabilities of the issuer owed to the bearers.

===Working with Financial Instruments===

Open-Transactions is designed to provide the highest security possible for both the issuers and bearers of financial instruments. Servers in Open-Transactions act as notaries which can witness and confirm balances, but can not change them. Every party associated in a financial instrument can prove their balance to any other party and no party can alter the balance of any other party without their agreement.

Open-Transactions represents quantities of a given financial instrument as deposit agreements, which are signed by the bearer and a notary.

Portions of a balance may be transferred between users via several asset-independent transaction types, including:

; Transfers
: An atomic movement of funds from one account to a different account, like a bank account-to-account transfer.
; Cheques
: A payment which is not deducted from the sender's account until the recipient claims it.
; Vouchers
: A payment which is deducted from the senders account at the time of creation.
; Invoices
: A payment request which the recipient can opt to pay from any of his accounts.
; Cash
: Anonymous cryptographic tokens which can be securely redeemed by the recipient without revealing the sender.
; Market offers
: Open agreements to exchange a given quantity of one instrument type for a given quantity of another instrument type.
; Smart Contracts
: Customizable agreements between multiple parties, containing user-defined scripted clauses, hooks, and variables.

==Use Cases==

===Encouraged use cases===

Encouraged uses cases are officially supported by Open-Transactions.

====Deposit accounting====

Entities that hold assets on behalf of depositors can use Open-Transactions to issue promissory notes as negotiable instruments.

Examples of such depositories includes:

* Precious metals
* Central bank currencies
* Cryptocurrencies

====Payments====

Users of OT negotiable instruments can authorize recurring payments to pay for services which operate on a billing cycle.

====Bearer Securities====

The negotiable instruments created by Open-Transactions can be used as the basis for financial products such as loans

===Discouraged use cases===

Discouraged use cases are not supported by Open-Transactions, either because they violate the security requirements, or because they conflict with the philosophical goals of the project.

In many cases, discouraged use cases may be achievable, but users are required to create and support their own smart contracts.

====Third party balance editing====

The only entity in Open-Transactions that can edit a balance is the holder of that balance receipt. Open-Transactions does not and will not include any functionality to bypass this design decision.

==More Information==

* [[About|About Open-Transactions]]
* [[Installation]]
* [[opentxs|Using the command-line tool]]
* [[API|Using the API]]
* [[otserver|Using the server]]
* [https://github.com/Open-Transactions/Moneychanger Moneychanger (Qt-based Desktop Client)]

This product includes software developed by Ben Laurie for use in the [https://github.com/benlaurie/lucre Lucre] project.

Credit for the OT logo goes to: [http://www.michpalmer.com/ moltenmich]

=== Mailing list and IRC ===

Mailing list: ot-dev@opentransactions.org

[http://opentransactions.org/mailman/listinfo/ot-dev_opentransactions.org Subscribe to mailing list]

IRC channel: '''#opentransactions''' on irc.freenode.net

=== Downloads ===

[http://github.com/Open-Transactions/opentxs Source code on github]

[https://bitcointalk.org/index.php?topic=77301.msg859040#msg859040 Windows binary installer ]

=== Sponsors and Contributors ===

The OT community gratefully acknowledges the support and contributions of the following individuals and businesses to OT development: Chris Odom, Cameron Garnham, [[Monetas]].

Auditor (voting pools)

2014-10-08T06:12:34Z

Ttll: capitalization, link to audit streams

== Introduction ==

When an [[auditor]] operates as part of a [[Voting Pools|voting pool]], additional requirements apply on top of its existing functionality.

== Responsibilities ==

The Auditor listens to the [[Notary (voting pools)#Audit Stream|Audit Streams]] broadcast by all the [[Notary (voting pools)|Notaries]] and independently verifies them for correctness. The same stream which carries regular OT transaction information also contains the OT receipts for Bitcoin withdrawal requests from the pool. The auditor initiates or authorizes a blockchain withdrawal transaction via the wallet if and only if the audit for that service is clean (verified correct).

The auditor is responsible for maintaining an independent copy of the same deposit database as the transaction server. It also tracks withdrawals from the time at which it receives an OT receipt, containing a withdrawal request, until the corresponding Bitcoin transaction is fully confirmed on the blockchain.

All messages which must travel between the transaction server and the blockchain wallet pass through the auditor.

In order to create withdrawal transactions, wallets must be able to select inputs and change outputs, and calculate the minimum required transaction fee deterministically. In order to achieve determinism, the sequence of withdrawals must be globally consistent. Before sending any withdrawal request to the wallet, the auditors are responsible for achieving consensus on a serialization order for withdrawals.

[[Category:Voting Pool Components]]

Notary (voting pools)

2014-10-08T06:10:25Z

Ttll: use new terminology, add section

==Introduction==

When a [[Notary]] is operates as part of a [[Voting Pools|voting pool]], it additional requirements apply on top of its existing functionality.

==Responsibilities==

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.

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.

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.

The Notary is also responsible for passing [[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.

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)

== Audit Stream ==

The Notary must broadcast five types of messages in an indexed and hash-chained sequence which form an Audit Stream.

The five types of messages are:
# Update to an inbox
# Update to an outbox
# Update to an account balance file
# Update to a Nym box file
# All Notary replies to transaction requests.

[[Category:Voting Pool Components]]

Notary (voting pools)

2014-10-07T19:20:39Z

Ttll:

==Introduction==

When a [[Notary]] is operates as part of a [[Voting Pools|voting pool]], it additional requirements apply on top of its existing functionality.

==Responsibilities==

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.

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.

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.

The Notary is also responsible for passing [[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.

The transaction server 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)

The Notary must broadcast five types of messages in an indexed and hash-chained sequence which form an Audit Stream.

The five types of messages are:
# Update to an inbox
# Update to an outbox
# Update to an account balance file
# Update to a nym box file
# All server replies to transaction requests.

[[Category:Voting Pool Components]]

Notary (voting pools)

2014-10-07T19:13:59Z

Ttll:

==Introduction==

When a [[notary]] is operates as part of a [[Voting Pools|voting pool]], it additional requirements apply on top of its existing functionality.

==Responsibilities==

The transaction server 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.

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.

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.

The transaction server is also responsible for passing [[PaymentRequests]] from the audit server 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.

The transaction server 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)

The transaction server must broadcast five types of messages in an indexed and hash-chained sequence which form an audit stream.

The five types of messages are:
# Update to an inbox
# Update to an outbox
# Update to an account balance file
# Update to a nym box file
# All server replies to transaction requests.

[[Category:Voting Pool Components]]

Auditing (voting pools)

2014-10-07T19:11:17Z

Ttll: Redirected page to Auditor (voting pools)

#REDIRECT [[Auditor (voting pools)]]

Deposit Address (voting pools)

2014-10-07T19:07:39Z

Ttll:

==Introduction==

In order to fufill the design criteria of [[:Category:Voting Pools|voting pools]], blockchain deposit addresses must be created in a deterministic manner such that any entity with the [[Asset Contract (voting pools)|asset contract]] can predict the sequence of addresses and enumerate the holdings of the pool for auditing purposes.

==Procedure==

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

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

<code>y3(5)</code>

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

===Script===

Multisig output scripts are created in the general form:

<code>OP_m {pubkey}...{pubkey} OP_n OP_CHECKMULTISIG</code>

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

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

The resulting ordering is the [[standard order]].

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

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

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

===Example===

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

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

<code>OP_2 y1(1) z1(1), w1(1) OP_3 OP_CHECKMULTISIG</code>

<code>OP_2 y1(2) z1(2), w1(2) OP_3 OP_CHECKMULTISIG</code>

<code>OP_2 y1(3) z1(3), w1(3) OP_3 OP_CHECKMULTISIG</code>

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

<code>OP_2 w1(1) z1(1), y1(1) OP_3 OP_CHECKMULTISIG</code>

<code>OP_2 w1(2) z1(2), y1(2) OP_3 OP_CHECKMULTISIG</code>

<code>OP_2 w1(3) z1(3), y1(3) OP_3 OP_CHECKMULTISIG</code>

[[Category:Voting Pool Technical Specifications]]