|
|
| Line 1: |
Line 1: |
| − | == Introduction ==
| + | #REDIRECT [[:Category:Voting Pools]] |
| − | | |
| − | Open-Transactions (OT) is a financial cryptography library that implements triple entry accounting with destructible receipts. OT allows for creditors to issue liabilities in the form of digitally signed and notarized receipts whose balances are tradable as a currency and 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 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 crypto-currencies) form a unique case. Since crypto-currencies 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 crypto-currencies, 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 crypto-currency 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, crypto-currencies 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 crypto-currency 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.
| |
| − | | |
| − | 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.
| |
| − | | |
| − | Voting pools are an open standard intended to be a universal replacement for bespoke systems that handle customer crypto-currency deposits. The first implementation of voting pools will be for Bitcoin, and throughout the rest of this document “Bitcoin” should be considered a synonym for crypto-currencies in general.
| |
| − | | |
| − | == Components of a Voting Pool ==
| |
| − | | |
| − | Voting pools bridge two worlds - OT and Bitcoin. OT is responsible for tracking the exact BTC-denominated balances of every user of a service, as well as the service’s balance. The OT transaction server is the portion of a voting pool which is closest to the users themselves. 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.
| |
| − | | |
| − | In order to manage the actual bitcoins held by the pool, each transaction server will need a corresponding Bitcoin wallet. The wallet must understand a hierarchical, deterministic, multisig structure and be robust enough to handle the high deposit and withdrawal volumes experienced by a popular service, including the security requirement to hold most funds in cold storage.
| |
| − | | |
| − | 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.
| |
| − | | |
| − | In order for voting pools to function, the transaction server must be publicly accessible. For this reason the audit servers must be physically separate from the transaction servers and they must 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 attack them and steal from the pool’s hot wallets.
| |
| − | | |
| − | The audit server must have a direct communication path with the bitcoin wallet. The wallet should connect to the rest of the Bitcoin network via Tor, I2P or equivalent in order to prevent an attacker from identifying the location of the audit server and bitcoin wallet based on their broadcast transactions.
| |
| − | | |
| − | 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.
| |
| − | | |
| − | === Security Model ===
| |
| − | | |
| − | '''Goal''': 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.
| |
| − | | |
| − | Note: Type 0 Events will be used throughout the rest of this document to describe all other abnormal conditions 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-n'' voting pool than they would be at risk if the service is not a member of a voting pool.
| |
| − | | |
| − | The design of voting pools assumes that in any given situation at least ''m'' pool members are well-behaving for Type 1 events and at least ''n-m'' pool members are well-behaving for Type 2 events.
| |
| − | | |
| − | Voting pools can guarantee the integrity of user deposits if this condition is met.
| |
| − | | |
| − | ===Transaction Server Responsibilities===
| |
| − | | |
| − | The transaction server must keep track of all BTC-denominated balances via OT receipts. In addition to a separate account(s) for each customer, the server must track a service account to hold the BTC-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 (bitcoin-denominated) 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, cryptographically prevents the co-mingling of funds.
| |
| − | | |
| − | The transaction server is also responsible for passing Bitcoin PaymentRequests (defined below) from the audit server to the customer, crediting customer balances after the successful receipt of a bitcoin 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.
| |
| − | | |
| − | ===Audit Server Responsibilities===
| |
| − | | |
| − | The audit server listens to the audit streams broadcast by all the transaction servers 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 audit server initiates or authorizes a Bitcoin withdrawal transaction via the wallet if and only if the audit for that service is clean (verified correct).
| |
| − | | |
| − | The audit server 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 Bitcoin wallet pass through the audit server.
| |
| − | | |
| − | 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 audit servers are responsible for achieving consensus on a serialization order for withdrawals.
| |
| − | | |
| − | ===Bitcoin Wallet Responsibilities===
| |
| − | | |
| − | The Bitcoin wallet tracks and manipulates bitcoin balances on the blockchain. The wallet notifies the audit server of received deposits, constructs outgoing transactions, and monitors the state of all relevant incoming and outgoing transactions.
| |
| − | | |
| − | An audit server requires access to a wallet provider for every crypto-currency its operator wishes to accept deposits for, and this wallet must support the Voting Pool Wallet API.
| |
| − | | |
| − | Wallets should understand both hierarchical determinism and multisig capability, and also output coloring.
| |
| − | | |
| − | ===OT Client Responsibilities===
| |
| − | | |
| − | In order for users to deposit bitcoins into the voting pool, the OT Client must be capable of parsing, verifying, and if necessary forwarding to another Bitcoin client, BIP70 payment requests. This is necessary to ensure a malicious server can not send a fake deposit request that results in a customer sending funds to an address not controlled by the pool.
| |
| − | | |
| − | All users of services which are part of a voting pool must have an OT client running on their device in order to use the service. The service front end can communicate transparently with the OT Client via a local websocket interface.
| |
| − | | |
| − | The OT client will be capable of operating in the background with the bare minimum necessary interaction in order to provide the lowest possible disturbance of the front end service’s user experience (UX).
| |
| − | | |
| − | [[Category:Voting Pools]] | |
