FellowTraveler
commented
12 years ago FYI, your thoughts are essentially mine on this issue. I have a bunch of discombobulated notes I haven't posted yet, but they basically amount to the same thoughts.
All instruments backed with funds (even cash) have the backing funds stored in an internal server account. For example, if the server has issued 4000 clams in cash notes, that means there is a server account somewhere with 4000 clams in it. (That way even if the cash algorithm is broken, the hacker couldn't steal more cash than the server had actually issued in cash.)
Also, there is already an intermediary file containing the "current balance" of every account.
Taken together, these facts mean that audits as you described are easy to do, and probably involve something more on the level of a UNIX script, than any actual code changes to OT. (Especially now that OT itself, the entire OT API is now scriptable.)
1) You pointed out that making the balances public enables audits, but also destroys privacy. Notice that Voucher-Safe solves this issue by running cash-only, so that audits are possible yet privacy is preserved. (OT could also be run cash-only.) Clearly Voucher-Safe is doing this for legal reasons, to protect the issuer legally from what happened to e-gold. 2) You pointed out that balances could be made public. Actually, as long as they are all available to the issuer, I don't think they have to be public (you are forced to trust the issuer anyway.) 3) You pointed out that users should keep receipts between authoritative audits, which I agree with. The issuer could then roll-back to the most recent audit, if the server is caught cheating on the next one. This will require bailouts to have a delay placed on them. For example if there is a 24-hour audit, there might be a 48-hour bailout period. 4) I believe a real-time audit is also possible. I think the ultimate solution will involve a combination of technologies like Namecoin, Freenet, Tahoe-Lafs, I2P, etc.
Interested in contributing to the project? A nice GUI client, perhaps?
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.