- 1 Abstract, Authors List, Keywords
- 2 Introduction
- 3 Voting Pool Overview
- 3.1 High-Level Overview, Identification of Components
- 3.2 Voting Pool Trust Model and Audit Streams
- 3.3 Communication-Layer: Network Topology, ZMQ, Bitmessage
- 3.4 Distribution of Tasks & Trust, Server Providers / Hosts, Server Discovery
- 3.5 Voting Pool Member Management, Automated & Human Layers
- 3.6 How to Become a Member of a Voting Pool
- 4 Wallet Providers
- 5 Design Criteria
- 6 Security Model
Abstract, Authors List, Keywords
Open Transactions is a financial cryptography library and software system featuring client user-interfaces where users can create, store, and transfer digital assets, instruments, and contracts via transaction servers. We describe a "voting pool" protocol for using consensus votes to process cryptocurrency transactions on the Open Transactions network. In the voting pool scheme, digital currencies can be deposited into multi-signature wallets where a spend transaction can only be initiated by a consensus vote signed by a group of independent auditors. Voting pools provide end-users with greater trust because they decentralize control over the deposited funds, ensuring that no individual server operator can transfer user funds without the complicity of a majority of the other voting pool members. Voting pools also provide unique security features such as shared multi-signature hot-and-cold wallet rotation and trusted multi-signed payment requests for deposit addresses. Voting pools allow end-users to deposit, trade, and withdraw cryptocurrencies on the Open Transactions network with greater trust than on any system that doesn't implement voting pools.
Keywords: cryptography, cryptocurrency, Diffie-Hellman, key exchange, currency, FOREX, contracts, Chaumian cash, bitcoin, financial, transactions, multi-signature, encryption, trust, servers, consensus, voting, games theory
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 transaction servers. 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.
Bitcoin is a digital asset ledger the 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.
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.
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.
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.
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.
Voting pools are an open standard intended to be a universal replacement for bespoke systems that handle customer cryptocurrency deposits.
Voting Pool Overview
High-Level Overview, Identification of Components
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 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.
The transaction server and the bitcoin wallet communicate via an 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.
In order to manage the actual bitcoins held by the pool, each transaction server has a corresponding Bitcoin wallet. The wallet software manages a hierarchical, deterministic, multisig structure, and can differentiate between standard cryptocurrency balances and colored balances. robust enough to handle the high deposit and withdrawal volumes experienced by a popular service and including the security requirement to hold most funds in cold storage,
Voting Pool Trust Model and Audit Streams
The basic design promise of voting pools is: Any denial of service attack which can cause customers to lose access to their Bitcoin deposits must involve more than
(n minus m)
members of an
m-of-n voting pool. Any attack that can result in a permanent loss of customer funds must involve more than
m members to be successful.
Communication-Layer: Network Topology, ZMQ, Bitmessage
The transaction servers are accessible to membership groups or to the public, processing transactions in general everyday-use for markets and exchanges. Transaction servers act on user, script, or client-generated transaction requests (API function calls) sent to them through the zmq layer or through BitMessage, a communications protocol and anonymizing proxy network. The interaction between end-users/clients and transaction servers does not require the use of any anonymizing network, but transaction servers do support anonymous end-user/client requests as long as they are properly signed.
Transactions servers and audit servers make up an inter-communicating mesh network where broadcasts may happen to all members directly via BitMessage. Audit servers are physically separate from the transaction servers and they communicate over a messaging system (Tor, Bitmessage, or equivalent) that obscures the location of the audit servers. This prevents an attacker who manages to compromise a publicly-facing transaction server from identifying the audit servers in order to attempt an attack on the audit server network (see: OT security and attack scenarios).
Audit servers have a direct communication path with the bitcoin wallet, where the audit servers and the bitcoin wallet providers communicate through a private broadcast network. When cryptocurrency transactions are ready to be pushed to a blockchain, the bitcoin wallets communicate to other bitcoin nodes via Tor, I2P, or other anonymizing proxy networks. Again, the use of anonymizing networks is used here to prevent an attacker from identifying the location of the audit server and/or bitcoin wallet based on their broadcast transactions.
Distribution of Tasks & Trust, Server Providers / Hosts, Server Discovery
Voting Pool Member Management, Automated & Human Layers
How to Become a Member of a Voting Pool
In order to achieve the desired security and robustness goals for voting pools, the following criteria are enforced:
- Customers should be strongly discouraged from reusing deposit addresses. The voting pool itself must never intentionally reuse a bitcoin address.
- 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.
- Withdrawal transaction input selection must be deterministic in order to minimise the cost of coordinating transaction signing.
- 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.
- It must be possible to alter the voting pool by adding, removing, or replacing members in a coordinated and secure fashion.
The goal of the voting pool security model is that users of deposit-accepting services should never experience a loss of deposited funds.
We can group the various ways in which this goal might not be met into two general categories:
- Type 1 Event (Theft/Loss)
- 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.
- Type 2 Event (Denial of Service)
- A user temporarily loses some or all of their ability to use their funds, but no third party has gained control over them.
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.
Voting Pool Security Theorem
If the probability of
m+1(Type 1 Event) or
n-m+1(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
m-of-nvoting pool than they would be at risk if the service is not a member of a voting pool.
Voting pools can guarantee the integrity of user deposits if, in any given situation, at least
mpool members are well-behaving for Type 1 events and at least
n-mpool members are well-behaving for Type 2 events.