Notary (voting pools) - Revision history

Justusranvier: /* Responsibilities */

2014-11-12T12:59:06Z

‎Responsibilities

Ttll: use new terminology, add section

2014-10-08T06:10:25Z

use new terminology, add section

Ttll at 19:20, 7 October 2014

2014-10-07T19:20:39Z

Ttll at 19:13, 7 October 2014

2014-10-07T19:13:59Z

Haarts: /* Responsibilities */

2014-09-24T06:47:58Z

‎Responsibilities

Haarts at 06:42, 24 September 2014

2014-09-24T06:42:18Z

Justusranvier at 13:53, 23 September 2014

2014-09-23T13:53:32Z

Justusranvier: Justusranvier moved page Transaction Server (voting pools) to Notary (voting pools): update terminology

2014-09-23T13:52:15Z

Justusranvier moved page Transaction Server (voting pools) to Notary (voting pools): update terminology

Justusranvier: Initial page creation

2014-04-17T19:48:36Z

Initial page creation

New page

==Introduction==

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]]

@@ Line 11: / Line 11: @@
 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 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.
 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)

@@ Line 13: / Line 13: @@
 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 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.
@@ Line 21: / Line 23: @@
 # Update to an outbox
 # Update to an account balance file
-# Update to a nym box file
+# Update to a Nym box file
-# All server replies to transaction requests.
+# All Notary replies to transaction requests.
 [[Category:Voting Pool Components]]

@@ Line 1: / Line 1: @@
 ==Introduction==
-When a [[notary]] is operates as part of a [[Voting Pools|voting pool]], it additional requirements apply on top of its existing functionality.
+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.
+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.
@@ Line 11: / Line 11: @@
 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 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 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 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:

@@ Line 11: / Line 11: @@
 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 (defined below) 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 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)

@@ Line 9: / Line 9: @@
 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, cryptographically prevents the co-mingling of funds.
+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 (defined below) 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.

← Older revision	Revision as of 13:52, 23 September 2014
(No difference)