FellowTraveler/Open-Transactions — Issue #61: Define Audit Protocol
Author: bytemaster
Created: 2011-12-01 05:42:08+00:00
State: open

What is your idea for solving the audit problem whereby users and issuers can verify that a server is not manufacturing IOUs without the issuer's consent?

Alternative A:

1) All issuer accounts are public. Thus the last signed receipt can be inspected by all.
2) All balances in the issuer's currency are public and may be inspected anonymously and compared.

A user can then anonymously verify that the server is publishing their balance, and can report a problem to the issuer if their balance is not on the public balance sheet. The user would provide the issuer with their last signed receipt from the server and the issuer could immediately validate the user's claims.

With the balances open to all you would lose privacy and track transactions simply by looking for offsetting balance changes.

To solve this the published list would need to randomly divide each user's balance among 2 or more randomly changing entries in the public list. Every time their balance changes a different random division would be used and therefore the public list can no longer allow 3rd parties to track all transactions.

The issuer would maintain a copy of this public balance sheet and in the event that the server disapeared "forever" or was found 'fradulent' could still honor receipts. This can be tricky, because the issuer has to pick one 'point in time' to freeze the server's accounts and redeem signed receipts and if the user has destroyed his account history, he may no longer have the proper receipt that will be honored by the issuer absent the server.

To solve this problem, the issuer would periodically sign and date the balance DB they consider 'authoritative'. Users would then keep all balance agreements from the last 'authortative' account from the issuer as well as their latest from the server. Any time the issuer 'updates' the authoritative list, the user can discard older balance agreements.

Assuming 1 million accounts, each with two int64_t balance + int64_t key, then this 'master record' would be less than 31MB.

31 MB could be randomly downloaded by any number of different people, multiple times per day. In the event of a server failure, the issuer would request account holders provide it with the most recent account db. The issuer would have to determine at which point in time the fraud/failure occurred and this would require some significant investigative effort, but with the information scattered among 1 million users the issuer should be able to honor all but the most recent transactions.
----------------------------------------------------------------------------------------------------

Alternative B:

Ultimately, users only care about the issuer and not the server. If the issuer is gone, users are SOL. So ultimately, users would want a signed balance agreement with the issuer with the ability to coordinate an atomic transaction that deducts from server.user_account adds to issuer.user_account.

( ( ( (Transfer 100 issuer_USD from server.user_iusd_account to issuer.user_iusd_account signed user) signed issuer ) signed server ) signed issuer ) )

Seems like there needs to be multiple trx numbers + signatures to prove that all parties did the right thing and have proper evidence of the balance change. The issuer's account with the server would need to be incremented to reflect the withdrawal such that once all accounts 'bail out' to the issuer, the issuer is left with a 0 balance on the server.

The issuer need only keep accounts and not enable trades, markets etc.