Skip to content

Auditing

Jump to bottom Edit New page
FellowTraveler edited this page Mar 25, 2013 · 31 revisions

OUTLINE:

Scenario: Issuer has gold in his warehouse, and he is also operating the transaction server.

Scenario: Issuer has gold in his warehouse, but a separate entity operates the transaction server.

A. Do the issuer and transaction server actually have the incentive to collude?

B. Do the issuer and transaction server have the ABILITY to collude? (regardless of incentive.)

Scenario: Issuer has Bitcoin in his cold wallet, and he is also operating the transaction server.

Scenario: Issuer has Bitcoin in his cold wallet, but a separate entity operates the transaction server.

Thoughts on THE AUDITING PROTOCOL (for GOLD issuers)

THE AUDITING PROTOCOL (for BITCOIN VOTING POOL)

Scenario: The 'Issuer' is actually a Voting Pool of transaction servers, with Bitcoin stored in the pool (on the blockchain.)

THE LAST SHIELD: Distribution of Risk.

IN SUMMARY

PROTOCOL EXAMPLE DETAILS

CONSEQUENCES

CONTENTS:

Scenario: Issuer has gold in his warehouse, and he is also operating the transaction server.

In this case, we are concerned about four things:

  1. Does the Issuer actually have the gold in his warehouse? (Only a physical audit can tell...)
  2. Is the Transaction Server (operated by the Issuer) able to lie on my receipt? (No, not even if malicious.)
  3. Does the total of all the receipts, match the amount on the issuer's receipt? (This is where inflation occurs. Our auditing protocol needs to verify this.)
  4. Does the amount of the issuer's receipt, match or exceed the amount from the physical audit? (The result from the physical audit must be compared to the result from the OT receipt audit.)

VULNERABILITY: Ultimately even if the physical audits are clean, the issuer COULD one day just disappear with the gold itself. (That risk always exists as long as the issuer has physical possession.) The best reduction of this risk is based on good governance: being choosy about issuers, based on: separation of powers, auditing protocols, gold storage policies, insurance, bonding, jurisdiction, etc. As well as employing a distribution of risk across multiple issuers (basket currencies, etc.)

INCENTIVE: An issuer could potentially have a perverse incentive, both to inflate the currency on the receipts, as well as to misreport the amount of physical gold in the warehouse. The issuer also has good incentives (transaction and storage fees, trust being of value in the marketplace, etc.)

SUMMARY: As long as the gold is physically audited, and there is a secure auditing protocol for OT receipts, and as long as OT's crypto is secure, then the only vulnerability is the disappearance of the physical gold. Only client-side distribution of risk across multiple issuers can reduce this further.

Scenario: Issuer has gold in his warehouse, but a separate entity operates the transaction server.

Potential dangers:

  1. Does the Issuer actually have the gold in his warehouse? (Only a physical audit can tell...)
  2. Is the Transaction Server able to lie on my receipt? (No, not even if malicious.)
  3. Does the total of all the receipts (for that currency) on the transaction server, match the amount on the issuer's last signed receipt? (This is where inflation occurs. Our auditing protocol needs to verify this.)
  4. Does the amount of the issuer's last signed receipt, match or exceed the amount of the physical audit of the gold held by the issuer? (The result from the physical audit must be compared to the result from the OT receipt audit.)

VULNERABILITY: The same vulnerability exists as above (that the issuer has physical possession of the gold.)

INCENTIVE: The issuer has an incentive to earn storage fees. The issuer also has a perverse incentive to disappear with the gold.

The transaction server, meanwhile, does have an incentive to continue earning transaction fees. (Note that since many different currencies can be issued on a single transaction server, his fees from all currencies can come into jeopardy if he loses trust based on a failed audit for only one of those currencies.)

The transaction server does NOT have a perverse incentive to steal the gold, because he is not holding any of the gold.

INFLATION

The transaction server DOES have a perverse incentive to inflate the currency (which auditing is supposed to prevent.) This is because he can spend it even without physical possession of the gold.

The issuer therefore DOES have an incentive to audit the transaction server. This is because the transaction server solely benefits from inflation, whereas the issuer solely ends up stuck with the bill.

COLLUSION

Amiller has proposed that the issuer and transaction server: (A) Have incentive to collude and (B) have the ability to defraud users (through their collusion.)

Let's examine these a bit closer:

A. Do the issuer and transaction server actually have the incentive to collude?

Consider the scenario:

If Issuer Ivan issues 100,000 grams of gold onto Server Sarah's transaction server, then he is normally supposed to have 100,000 physical grams of gold in his warehouse, as backing for those 100,000 units. Users must trust (and verify) that he does; they have an incentive to be choosy about issuers based on this.

Let's say that Server Sarah is malicious, and she inflates an additional 50,000 grams of gold (that don't really exist.) So now, even though Issuer Ivan only has 100,000 physical grams of gold in his warehouse, he is on the hook for receipts totaling 150,000 grams of gold -- 50,000 grams of which don't even exist. But he owes them, and his ability to attract customers is purely based on their confidence in their ability to someday retrieve their gold from him in physical form.

Normally, Issuer Ivan's incentive is not to be "on the hook" for gold he doesn't have. Especially if Server Sarah is the one benefiting from this fraud, instead of him. Why should Ivan be on the hook for that money, if he doesn't even get to spend it?

To tempt him, and based on Amiller's advice, Server Sarah offers half the inflated loot to Issuer Ivan. "We'll split it!" she purrs seductively.

The result of their union? What did each of the two benefit?

  1. Server Sarah gets to spend 25,000 grams of inflated gold she did not earn.
  2. Issuer Ivan is now on the hook for 150,000 grams of gold, including the 25K grams he got from Sarah (as payoff for ignoring the dirty audit.) Yet he only has 100,000 grams of gold in his warehouse.
  3. Both must permanently avoid audits in the future. This scheme assumes that no other entities have access or incentive to audit those same receipts.

Did they really split anything at all? Did Issuer Ivan benefit? He is still on the hook for the full 150,000--not only the 25,000 that he received as loot, but also the 25,000 that Sarah spent as well.

Issuer Ivan has now taken on an additional 50,000 grams of debt, in order to spend 25,000. Why? And he only has 100,000 grams in his warehouse, not the 150,000 he actually owes. Meaning he is at risk also to lose trust on the market, and thus lose all his yearly storage fees that an issuer would normally earn. (Server Sarah has this same risk, except with all of her issuers, not just one.) Ivan also would be considered guilty of a crime, since Sarah's inflation is not even possible without Ivan's collusion.

…All so that Server Sarah gets to go and spend her own 25,000 grams of gold that she did not earn, and does not own, and that Issuer Ivan is now on the hook for. Of course, Ivan got to spend 25,000 grams too, but he is also now legally on the hook for them (as well as Sarah's.)

Therefore I must ask: What is the incentive for the issuer to collude? He is already holding all of the gold! Why give any to Sarah at all--why not just disappear with the gold directly? I see this scenario as actually just a direct transfer of 25,000 grams of gold, from Issuer Ivan to Server Sarah for absolutely nothing in return! Except more debt to Issuer Ivan, and potential loss of all his future income as well, as well as potential for criminal charges. (I say criminal charges because unlike with Bitcoin, Ivan has to store physical gold and thus he is probably a legal entity in some jurisdiction.)

So my question is: Are we so SURE that Issuer Ivan really has an incentive to collude with Server Sarah?

The user already must trust the issuer who holds his gold--he already must "buyer beware" when it comes to issuers in general. A well-designed wallet cough should even distribute risk across multiple issuers automatically. But I don't see how the separation of powers here (of the issuer and transaction server into two separate entities) creates any incentive for the issuer to collude with the transaction server.

The transaction server does have incentive to inflate, which is what auditing should prevent, but I just don't see that the issuer has any incentive to collude with him in doing so but rather, has the opposite incentive: to prevent him from doing so.

(Please show me if I'm missing something here.)

(This picture shifts slightly with Bitcoin, as I will address towards the bottom.)

B. Do the issuer and transaction server have the ABILITY to collude? (regardless of incentive.)

  • We already know that the transaction server cannot lie on the receipt of any legitimate user. (This is because the user must sign the receipt and the server cannot forge the user's signature.) For the same reason, the server cannot lie on the issuer's receipt.

  • However, the transaction server could lie on the receipt of a dummy account. (Where he controls both sides.) This is what the auditing protocol is meant to prevent.

  • The transaction server can keep the dummy receipts hidden, but he cannot spend the inflated funds without having them flow into a normal account, where they instantly become visible to auditing. (Therefore auditing works even if the dummy account itself remains hidden to the audit.)

  • Since the Issuer has an incentive to audit the transaction server, the transaction server has a perverse incentive to collude with the issuer, since this would enable the transaction server to inflate the currency. The issuer could just lie, pretending there was no inflation, even when an audit clearly shows inflation.

(No other crime is possible, anyway: colluders cannot prevent inflated funds from flowing into other accounts, and they cannot pick-and-choose between receipts, since the overall total cannot change without failing the audit. And colluders cannot forge the signatures of any legitimate users. Therefore inflation is the only crime left, absent just freezing the entire directory--which would cause all the user wallets to fail when trying to use that server. And even inflation is still only possible if there are no other auditors.)

BUT IT IS PHYSICALLY POSSIBLE: Clearly there is still at least the possibility that the issuer (whether he operates the transaction server or not) could lie and pretend the OT receipt audit was clean, when it actually was not. This means that preventing such a possibility mandates having third-party auditors who have both access to the receipts and incentive to audit them, as amiller has pointed out.

NO INCENTIVE: I believe there is no incentive for the issuer to collude in the first place, as explained in the previous section, since he is "on the hook" for the total of all the receipts. He is the one stuck unable to produce the gold.

PREVENTION: ...but physically preventing him from doing so, would necessitate that the receipts not only be shared between the issuer and transaction server, but that other auditors must have access to audit those receipts as well.

Furthermore, as Amiller has pointed out, others must have an incentive to audit those receipts, or no one actually will. (I believe I've shown above that the issuer DOES have an incentive to audit the receipts, and furthermore DOES NOT have any incentive to collude with the transaction server, but if we want to prevent the very possibility of collusion, then we must have other auditors with access and incentive to audit those receipts.)

Scenario: Issuer has Bitcoin in his cold wallet, and he is also operating the transaction server.

Scenario: Issuer has Bitcoin in his cold wallet, but a separate entity operates the transaction server. (This scenario will likely never actually happen! See explanation below.)

These Bitcoin scenarios are similar to the previous two gold scenarios, with one important distinction:

While the physical gold audit requires offline governance, the "physical" audit of the Bitcoins on the blockchain can be performed programmatically. This is a significant advantage over physical gold, but it doesn't change the fact that the issuer ultimately still has to be trusted not to steal those coins.

Otherwise the incentives are the same:

  1. The transaction server has an incentive to maintain trust and earn transaction fees, not just from one issuer but from all issuers.
  2. The transaction server, if there is a separate issuer, also has a perverse incentive to inflate the currency. (Which would be caught on an audit, and so he has an incentive not to get caught--therefore this perverse incentive gets smaller, the more other currencies are issued on that server. For example, if there are 300 currencies issued there, he has less incentive to risk his reputation than if there is only 1.)
  3. The transaction server is not capable of committing any other crime except inflation, and that crime is only possible with collusion from the issuer, whom we already know we must trust (to hold our Bitcoins.)
  4. The issuer has no incentive to collude with the transaction server to commit inflation (the only possible crime.)

ANOTHER IMPORTANT DIFFERENCE: The gold issuer normally has an incentive to maintain trust, to earn storage fees. But a Bitcoin issuer cannot earn storage fees, since for storage, people will just store their BTC directly on the blockchain. He cannot offer storage value, only risk. (Whereas physical gold actually has to be stored somewhere and guarded, which is a service of real value.)

THEREFORE: There will not actually be any BTC issuers on OT, except those who operate their own server! And those will do it for the transaction fees, not for storage fees.

THIS MEANS that the first BTC scenario WILL happen, but that the second BTC scenario will NOT ever happen.

This means that so far, the only realistic scenario for issuing BTC on an OT server is: A server operator who issues his own BTC-based currency in order to earn transaction fees. He cannot lie on any of his receipts (i.e. the total amount he owes to everybody) but he CAN commit inflation, and he will get away with it unless others are willing/able to audit his receipts. But he cannot lie about the actual amount of BTC stored on the blockchain, since that is visible to all, programmatically.

But I believe that this scenario will cease to exist as well, once voting pools are operational, because voting pools solve everything with a neat bow-tie, as I will explain.

Thoughts on...

THE AUDITING PROTOCOL (for GOLD issuers)

  1. We already know that whenever the server performs a transaction, he must give the user a receipt. This is because the user's wallet will not be able to perform its next transaction unless it is able to verify its intermediary files against the last signed receipt. Another way of saying this is that the receipt IS the transaction. Furthermore, the receipt IS the account as well.

  2. I propose that if the users have to get their receipt from a specific place, and if the auditor has access to that same place, then inflated funds cannot be spent into any normal user account without those funds appearing on an audit.

  3. All the auditor has to do is, watch that specific place, preferably in real time, and make sure that all the receipts, including the issuer's receipt, balance to 0. And he only ever has to do that with a "current snapshot" of the latest receipts (not needing any historical receipts for the users.) He could also do a running count (in real time), which is even more preferable. Either way, if the receipts ever fail to balance, the server is summarily dumped and the receipts in the snapshot are just re-issued onto a new transaction server.

  4. This specific place (for receipt exchange) doesn't have to be secure like a blockchain, since the security is provided by the signatures on the receipts, and not by the storage place itself. The transaction server, AND the auditor--even in collusion--cannot forge the receipts of normal users, and even if they could, the grand total would be wrong unless they could forge them all. They also cannot replace a receipt with an older version of itself, since its request number would visibly go backwards. Also, they must keep the receipts current, or the wallets will stop working. They could try to freeze the "public face" of a receipt (continuing to show some older receipt, even when a newer one is now available.) But this would cause the related wallet to fail -- and in order for the grand total to balance, colluders would thus have to freeze all receipts (they could not pick-and-choose, so all wallets would thus stop working.)

  5. This specific place for receipt exchange doesn't have to store a complete history like a blockchain does. We only need these receipts around for "just long enough." For transactional purposes, any given receipt only needs to be there just long enough for the user to retrieve it. For auditing purposes, it needs to be there long enough for a "snapshot audit" of the receipts, and then it can be erased. (This audit can happen in real time.) The transaction server, also, while it doesn't need to store all receipts, DOES need to store "the last signed receipt" for all users, just to cover its own ass. (Meaning the server cannot ever destroy its own copy of this "last signed receipt" until a new one exists to replace it with.)

  6. The "specific place" for receipt exchange could be a network-attached folder at a specific URL, listed in the server contract. (Or listed in the asset contract.) Preferably this place would be a key-value DHT, but it wouldn't have to be. However, I believe a DHT is Voucher-Safe's solution, so it merits attention. Also, since the security is provided by the receipts themselves, it seems that malicious DHT nodes could only potentially disrupt/prevent an audit from succeeding (as opposed to fraudulently causing a dirty audit to succeed.) The same is true if the receipts are stored in a simple folder--a lying transaction server could freeze the receipts (thus freezing all the wallets) or he could disappear, but both of those actions would just cause the audit to fail. He could not falsify receipts.

  7. Transaction receipts can be stored in one folder per currency, and with sequential numbering. Note that OT already stores transaction receipts by receipt hash in a single folder, so this is a modification of that. This sequence number is something new (not a request number or a transaction number, but a number specifically for each currency's receipts, sequential to the order that they are created.) This sequence number makes it very easy for any interested parties to keep tabs on all the receipts for a given currency, to make sure they have seen them all without gaps, and to see the order that they are created. The transaction server cannot forge the receipts (each containing user-signed portions, with request numbers and transaction numbers) and it cannot freeze receipts without freezing the advancement of the sequence number and thus also freezing all the wallets.

  8. This sequence number could be included in the server-signed portion of the receipt. Beware that the server has the ability to sign a different version of the same receipt but with a different sequence number, since it would not appear in the user-signed portion of the receipt but rather, in the server-signed portion of the reply, but this is also incriminating for a malicious server since the server would have to sign both versions in order to do this, and if both copies were to ever surface, the crime would be obvious. (Versus individual receipts which are only clean or dirty based on whether the OVERALL TOTAL proves inflation, whereas in this case, if the two of those receipts were to appear at any time, they would be incriminating, regardless of the total of all the other receipts from some snapshot.) In the case of Bitcoin this would be a problem: which receipt of the two is the correct one? Do we have "double spending"? But on OT it doesn't matter: the server has failed the audit. Dump it and re-issue the last valid snapshot onto a new server. You cannot really have double-spending on OT, since all parties have signed all transactions. The worst you can have is inflation.

  9. Chain the receipts: The hash of the previous receipt for the same currency could also be included in the server-signed portion of the receipt, along with the sequence number. The server could, as in note (8), create a separate, false version of the receipt, since that hash would only appear in the server-signed portion of the receipt, not the user-signed portion. But since changing a hash, changes the contents of the next receipt (since it contains a hash of the current one), then it would necessarily change the hash of that receipt as well, and thus change the contents of the receipt with the next higher sequence number, and thus change its hash, and so on all the way up through the entire sequence... the server would be forced to falsify the entire chain. The whole point is to force a single fraud, by design, to become a global fraud in detectability.

  10. Also, reverse chain: Building on (8) and (9), each user can include the sequence number of his LAST successful transaction receipt--as well as its hash--in his next request. So that the USER-SIGNED portion of the next receipt, which is unforgeable, for each successful transaction contains the sequence ID and hash of the previous one. Again, the idea is to make it impossible to forge one receipt without having to forge all the others, and in this case, in places where forging is not even possible, since the user's private key is unknown, and the reverse chain is stored in the user-signed portion of the receipt.

  11. Remember, this isn't some permanent chain, we only need these receipts for specific processes, and then we can discard them. (That's the whole idea of OT.) On the blockchain, you can sign to transfer funds to one address, and then you can falsely double-spend the same funds to another address, and ultimately one transfer is not any more "right" than the other (other than the one that counts: the one with the longest chain.) But in OT, all you have is your last signed receipt. You can sign to transfer funds, but the thing you are signing includes the new balance, and in fact will become your new "last signed receipt." On OT you cannot double-spend, you can only inflate.

  12. Ideally all the user wallets who care about a given currency, will participate in a DHT where the receipts can be posted temporarily for exchange. The receipts cannot be forged. Malicious nodes might be able to disrupt access or freeze, but they cannot falsify the audit. And ultimately any auditor can ask a server directly for the contents of receipts X, Y, Z... (the next expected sequential numbers) and if the receipts fail to be produced, then have all transactions stopped? This is why I say it's probably fine just for the servers to make the receipts available as a read-only filesystem, which the users and auditors have access to. But I still like the idea of some sort of DHT...

(Not finished.)

Thoughts on...

THE AUDITING PROTOCOL (for BITCOIN VOTING POOL)

Scenario: The 'Issuer' is actually a Voting Pool of transaction servers, with Bitcoin stored in the pool (on the blockchain.)

HOW VOTING POOLS WORK

  1. Alice bails 100 BTC onto an OT server. But instead of sending the BTC to the server directly, she sends them to all the BTC addresses of the servers in the pool. (Such that only a blockchain-based vote of those same servers, X-out-of-Y, can get any coins out of the pool.)

  2. Once the OT server sees Alice's bailment on the pool, she is issued BTC-units inside the server. From here, she can use them normally. For example, she can send a cheque to Bob.

  3. At some later time, Bob decides to pull his BTC out of the server. He has 5 BTC in his account. He sends the bailout request to his own server, who countersigns it, and then both send a copy to the other members of the pool.

  4. The other pool members, who audit the OT server, then verify the signatures on the receipt, and vote on the blockchain to authorize Bob's out-bailment. (Then Bob receives his coins at his personal BTC address.)

In one capacity, each pool member acts as a transaction server, in competition with the others--yet in another capacity, each acts as a BTC-unit issuer, based on his allotment of the common pool, which he is concerned to protect from the others--yet in another capacity, each is subject to third-party auditing from all the others.

INCENTIVE TO AUDIT

All pool members have an incentive to audit the others (to prevent other pool members from inflating), since otherwise the inflaters would be enabled to bail-out real BTC from the pool--coins that they didn't actually own--and even get a vote in their favor to do it. (If they don't actually own the coins they are taking, that means those coins are actually coming out of YOUR portion instead -- which is why you, as another pool member, have an incentive to prevent it through auditing.)

These pool members could collude. For example, 20-out-of-30 pool members could fraudulently vote on the blockchain to transfer themselves coins they don't really own, just as 51% of the mining power could be used to steal everyone's BTC on the blockchain itself. (Nothing's perfect.)

Since they share a common interest in the integrity of the pool (the protection for each of his own assets), and since they are in the business of trust (membership in the pool providing a greater degree of trust and safety for the BTC-units issued by any pool member) then it could be foolish to approach their business competitors to propose collusion. If they could convince 20, it would be one thing, but anything less, and they are merely exposed as fraudsters by their own business competitors, who are acting in their own interests to protect their own assets.

Assuming that the receipts are publicly available, the other pool members may not even have the option to "allow" inflation by one of their members, even if they had 20 colluders, since this information could be discovered by other entities such as one of their users. The pool members have an incentive to continue earning transaction fees, not only from the Bitcoins being traded in their pool, but from all the other currencies as well. There could be dozens of other currencies issued onto those transaction servers, currencies which the Bitcoins are presumably trading against.

NOTE: the unique combination of properties that this scenario provides... The "physical BTC" is programmatically verifiable on the blockchain. (No need for a real-world physical audit.) No single pool member can steal the coins, or even get to his own coins, without an X-out-of-Y vote to get to them. No crime other than inflation is possible, and even that isn't possible without keeping the receipts hidden from all other entities. And instead of one issuer with an incentive to audit a given transaction server, you have 30 issuers (the other pool members) with that same incentive to audit it. And the pool members are normally in business competition with each other--business competition where trust is the market, and any of them can benefit by catching a competitor lying.

For pool members to vote falsely in favor of your fraudulent out-bailment, they would have to do so by raiding their own allotments of the pool--robbing themselves to pay a fraudster who receives the sole benefit. And they would do so with the full knowledge that absent collusion, if you vote wrong, you will be the only pool member who voted wrong, impotently--with 29 others going in the opposite direction. Unless their calculations for their own votes were wrong, they will want to know why you are lying in your vote.

The other pool members COULD still collude, and vote themselves coins from the pool. Even if they cannot forge an OT receipt, they can still use X-out-of-Y on the blockchain to directly take coins from the pool. So you have, say, 20 pool members who vote the wrong way...

...Just as the blockchain itself could "vote" 51% the wrong way.

...Just as an issuer could collude, against his own interests, with a transaction server to turn a blind eye to inflation, sticking himself with the bill. (Assuming the receipts are not made publicly available.)

The last, best protection for a user against those potentialities is to have a wallet that distributes his risk across multiple pools. The philosophy of Open-Transactions comes down to this: a user-centric distribution of risk. Federated servers, basket currencies, these tools are all used for the distribution of risk.

One last thought: Hiding amounts homomorphically. It may be possible to use homomorphic cryptography to hide the amounts on the receipts (protecting the privacy of the users), while still publicly posting those receipts for audit. Another work-around here is to use cash-only instruments (this is like what Voucher-Safe does.) This way, even if the receipts are public, they are useful for auditing yet without revealing transaction amounts or account balances.

IN SUMMARY

Scenario: Issuer has gold in his warehouse, and he is also operating the transaction server.

===> In this scenario, you must be choosy about the issuer based on physical audits of the gold, and based on other governance issues such as insurance, jurisdiction, etc. The issuer cannot lie on your receipt, and he can only commit inflation if all receipts are kept hidden permanently thereafter (otherwise he can get caught, since he cannot inflate without also having to sign it, and the new funds are always detectable unless/until they are removed again from circulation.)

Scenario: Issuer has gold in his warehouse, but a separate entity operates the transaction server.

===> In this scenario, the transaction server may have 50 other issuers using his server, and the issuer likewise may have issued his currency onto other transaction servers.

===> The transaction server may have a perverse incentive to inflate a currency, but this would be permanently detectable, and would thus require the secrecy of all receipts, and would require collusion from the issuer to "turn a blind eye" to his own audits.

===> The issuer does not have an incentive to collude, and the issuer does have an incentive to audit the transaction server.

A. Do the issuer and transaction server actually have the incentive to collude?

===> I argue no. This appears purely as a wealth transfer from Issuer Ivan to Server Sarah, with great potential costs to both.

===> Basically: If Issuer Ivan issues 100,000 grams onto Server Sarah, then he is the one who owes the 100,000 grams and must be able to produce the physical gold. If Sarah inflates an additional 50,000 grams, then she is the one who benefits, while Ivan is the one who pays. And even if she splits it with him, he is still the one stuck with the total bill, while she gets to spend half, and he will be on the hook for that, too.

===> So in effect it's nothing more than a wealth transfer from Ivan to Sarah for no reason, and at great risk to both of them, in terms of future transaction and storage fees--from other currencies as well, and not just the one in question.

B. Do the issuer and transaction server have the ABILITY to collude? (regardless of incentive.)

===> They cannot collude to do "anything they want," but they can collude to INFLATE.

===> But even this is only possible if they keep the receipts secret, and if there are no other entities with the ability or incentive to perform a spot audit. Inflation is permanently detectable, since the funds would have to be taken back out of circulation in order to hide the crime from any future audit.

===> Any other attempted crimes (outside of inflation) are not possible and would only result in failing an audit or freezing all the user wallets. Receipts cannot be forged, even with collusion.

Scenario: Issuer has Bitcoin in his cold wallet, and he is also operating the transaction server.

===> This scenario has the benefits that the reserves are publicly auditable (on the blockchain) and that the issuer cannot lie on your receipt.

===> But it still requires you to trust the server operator with your Bitcoins, which is "buyer beware" and which I believe will cease to exist once voting pools are available.

Scenario: Issuer has Bitcoin in his cold wallet, but a separate entity operates the transaction server.

===> This scenario will likely never actually happen! The reason is because the issuer adds no value in the case of Bitcoin storage, since a user can just store it directly on the blockchain without any fee, so there is no reason to pay an issuer a storage fee.

===> In contrast, the storage and guarding of physical gold is a real value-add, which must be paid for.

Therefore BTC-based currencies will only ever be issued either through an issuer who operates his own transaction server, or through a voting pool, in my opinion. (The voting pool being the long-term winner.) We will not see successful scenarios where a trusted BTC issuer has issued his currency onto a transaction server operated by some separate entity. At first, some BTC issuers will be successful by operating their own transaction server, but then these will be overtaken by voting pools in the long-term, for obvious reasons.

Thoughts on THE AUDITING PROTOCOL (for GOLD issuers)

===> We can make it impossible to escape an audit, easy to get caught in violation of one, and extremely difficult to try.

===> The only possible crime is inflation, and even that is not possible if there are other entities with the incentive to audit the receipts. Inflation is permanently detectable and all receipts would have to be kept secret to prevent an outside audit. (Note that users all have their own receipts, so that sort of secrecy is impossible.)

===> All that is necessary is to have a place where users can retrieve their receipts, even if only a network-attached, read-only folder hosted by the server itself. (If a DHT were used, that would be cool, too.) Malicious DHT nodes or fileservers could disrupt services, but could not falsify results, and disrupted services could be simply moved.

===> UPON FURTHER THOUGHT AND REFLECTION, the "network-attached" folder itself may not even be necessary! Currently, users just receive their receipts directly from the transaction server, in reply to their requests. We could just maintain that system. Then on top of that, allow any "interested parties" to subscribe to real-time broadcasts of the same receipts (in sequential order.) This will require more thought...

THE AUDITING PROTOCOL (for BITCOIN VOTING POOL)

Scenario: The 'Issuer' is actually a Voting Pool of transaction servers, with Bitcoin stored in the pool (on the blockchain.)

===> Just as a transaction server cannot commit inflation without collusion from the issuer for that currency (who has no incentive to do so, and who in fact would get stuck with the bill, and has an opposite incentive to audit the transaction server), much in the same way, a pool member cannot commit inflation without the collusion of the other pool members, who would stand to lose their own Bitcoins as a result. One auditor gets turned into thirty auditors.

===> Amiller's requirement that the server be subject to audits from third-parties--with incentive--is met by the other pool members. The transaction server would be subject to audits from all of the pool members, each doing so to protect their own BTC and each in competition with the others.

===> It's true that a majority of the servers in the pool could still collude--that if they were able to get enough voters together, they could steal your BTC directly off of the blockchain. (Even then, they could not falsify your OT receipt!)

===> But so what? It's also possible for a 51% attack to steal your coins...but there are also other incentives, other forces, working in the opposite direction, such that the blockchain still provides pretty good security. And I would say that it's actually the same forces that are at play with the voting pool--perhaps not as secure as the blockchain itself but still considerably more secure than trusting a single server operator with your coins -- which means it is what people will use instead of trusting a single server with their coins.

THE LAST SHIELD: Distribution of Risk.

===> Ultimately the last line of defense is a wallet that, from a user-centric perspective, distributes risk across multiple pools, multiple asset types, multiple transaction servers, etc. There is never a complete elimination of risk, in any system or blockchain. There are only strategies for managing it and reducing its impact. Ultimately a smart wallet must provide this for its user.

===> All of the various strategies above are different angles of that same philosophy--different problems being attacked in their own specific domains from the perspective of reduction and distribution of risk. With OT we are "going meta" because we are using any-and-all of them wherever we can gain any benefit, from a user-centric perspective.

PROTOCOL EXAMPLE DETAILS

  1. All users directly receive their receipt in each server reply. This receipt has a sequence number on the server-signed portion, for that currency. All wallets normally verify this receipt against the account balance (an intermediary file) before performing any transaction. This is because each receipt must contain a signed balance agreement.

  2. The account balances for any given currency are stored in the accounts folder. The receipts for a given currency will be stored sequentially in a folder and automatically erased after 30 days. The receipts could be stored in the clear, or they could be stored in the clear but with homomorphically blinded amounts, or they could be stored encrypted in an RSA envelope to multiple keys (the USER and AUDITOR keys for example.)

  3. The same receipts could also be broadcasted in real time via ZMQ to any subscribers. (E.g. auditors.)

  4. The same receipts could also be queried at any time from the server (within the 30 day period) based on the currency ID combined with the sequence number. (We should also allow this query based on the hashed receipt ID.)

  5. (Optional) Just to be really overzealous, the user wallets could be coded to automatically randomly send one receipt out of every hundred, or out of every thousand, directly to the issuer, to a location described in the currency contract. Why? Because if the transaction server cannot hide funds flowing from dummy accounts into normal accounts, then he might try to just hide normal accounts. This would be quite a juggling act for him, but it becomes impossible with this step in place since he cannot prevent all the thousands of user wallets from randomly occasionally directly showing the auditor their receipt (with the server's signature on it)--which proves the existence of their account, and gives the auditor examples to verify.

  6. An auditor starts by loading up all of the receipts for a given currency, at a given snapshot in time. There should be only one account with a below-negative balance, and all the others should have a 0 or higher balance. If you add all of the balances together, they should equal zero. All of them should contain user-signed requests enclosed in server-signed responses. All of them should verify (for example a balance agreement inside a receipt should not contain inbox records that change the account balance based on a specific transaction number, unless that transaction number is also shown as signed-out to that user, on the same receipt.) We probably have the ability here to verify a lot deeper than we will need.

  7. From here, if the auditor is subscribed to the ZMQ broadcast, then he will see each next receipt in sequence order, and process them in order thereafter, in real-time. For example, if receipt #455 is the latest one in the snapshot, he will want to process #456 next, and then #457, etc. Each should move funds from one account to another, and thus result in a 0 balance overall. And each receipt should involve only accounts which actually appear in the accounts folder, according to the snapshot. (i.e. the auditor is specifically looking to catch receipts which do not have a corresponding account balance file in the account folder.)

  8. If a dummy account sends inflated funds to a real account, the real account will have to sign to accept them, and his receipt will show up on the audit. The auditor will see (from that receipt) that the real account is signing to accept funds from an account that apparently doesn't exist. (At this point the transaction server has failed the audit.)

  9. In addition to listening to the broadcast, the auditor can also compare notes with other subscribers, as well as compare notes against random receipts sent to him by users (optional.) He can also randomly create accounts and send "ping" transactions through, to see the sequence number incrementing and to compare it against the sequence number that appears in the receipt folder, and that is retrieved via server query. The result of the query can be hashed to see if the receipt hash matches the expected one for that sequence number. The auditor can also query the previous receipt in the sequence, AND the previous receipt for THAT USER, and compare the sequence numbers and hashes to make sure none of them have been changed. For example, if a user randomly sends receipt #367 to the auditor, and it has a certain hash, then the auditor can expect that when he saw that same receipt, or when he queries the server for a copy of it, that it will have the same hash. (Again, we can probably verify deeper here than we will actually end up having to.)

  10. Remember, one falsification is permanently detectable, and it only takes one for the transaction server to be dumped. As long as the balance always equals zero, and the accounts are all known from the snapshot, and the balance agreements verify with the user's signature, then inflation cannot happen. (Amiller asks: what are the consequences if inflation is discovered? More on this below...)

  11. Let's assume the transaction server is hosting the receipt folder. Thus, the auditor can't be guaranteed to be able to put a signed warning in that folder, because the (potentially malicious) transaction server is the one hosting it, and he might just block it, or erase it, so the users never see the warning.

  12. But if the auditor is expected to put a signed "A-Okay" into a sibling folder on a regular basis, then it is automatically suspicious if that receipt fails to materialize. The schedule can be described in the currency contract, and the user wallets can verify their own receipts for themselves, based on that schedule.

  13. It's also automatically suspicious if you straight-out ask the server for the latest signed audit receipt, yet he is unable to produce one according to the terms expecting from the currency contract. It would be easy to have a an OT wallet that regularly and automatically verifies its own receipts' audit status, according to the terms described in the currency contract, by simply asking the transaction server to produce the auditor's signed copy. In fact, the auditor's "last signed A-Okay" could be automatically attached to all server replies. That way it's immediately obvious to any wallet if something's fishy, even before any transaction is performed.

  14. On one hand, the currency contract might describe a real-time audit, with a user wallet expecting to be able to verify its own receipts' audit status in near real-time.

  15. On the other hand, the currency contract could instead describe, say, a daily audit, and/or a day or two delay on out-bailments, with mandatory daily limits on how many units the issuer will redeem to any one user. This way no one can ever GET AWAY with inflation, before the time of the next audit.

CONSEQUENCES

Amiller asks: what are the consequences when the audit fails? Is the transaction server arrested? Is he forced to make a public apology?

  1. In the case of a BTC voting pool, each transaction server is audited by each pool member. If the transaction server fails an audit (and thus every audit thereafter), that pool member will thus vote against any bailments out of the pool for that transaction server. So the first consequence is loss of access to the coins in the pool.

  2. Secondly, if the auditors have not posted their notice (which the potentially malicious transaction server can be responsible to host and provide upon demand) according to the schedule expected from the currency contract, then the user wallets can be programmed to distrust the transaction server and notify the issuer when this happens, and request their funds be re-issued onto a different transaction server.

  3. In the case of a voting pool, a vote can be held by the other pool members (they are the "issuer" in that case), in order to recover the coins from the malicious server's pool allotment and into the pool allotment of a valid transaction server, so the related units can be re-issued back to the user.

  4. Thus another consequence to the transaction server is the near-immediate loss of all users of that currency, and loss of all future revenues from transaction fees denominated in that currency, and potentially (likely) loss of all future revenues from all other currencies.

  5. As long as the audit is in real-time, or as long as the out-bailments are limited and the audits are nightly, then the transaction server cannot get away with anything, he can only get caught and then lose all future revenues.

SIDE EFFECTS

Receipts having to be public means others can see them. Which means we need to delve deeper into homomorphic crypto.

But then again with a voting pool, it might only be necessary that receipts are auditable by the pool members, since the BTC stored in the pool are already publicly auditable via the blockchain itself.

Add a custom footer
Add a custom sidebar
Clone this wiki locally