|
|
| (One intermediate revision by the same user not shown) |
| Line 1: |
Line 1: |
| − | ==Introduction==
| + | #REDIRECT [[Notary (voting pools)]] |
| − | | |
| − | When a [[transaction server]] 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 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.
| |
| − | | |
| − | [[Category:Voting Pool Components]]
| |
