My questions are in what I sent to the Open Transactions team a day or two ago:
An issuer creates something that is tradable, but such tradable things should be redeemable.
Indeed. This is true for all currencies except for purely virtual, blockchain-based currencies like BTC and LTC. (No real-world redemption is necessary for such tokens because the token itself is all there is.)
Whereas if a digital currency is "backed" with anything (gold-based, dollar-based, etc) then it becomes inescapable that there must be some form of "issuer" who is holding the gold.
...Which implies counter-party risk.
Open-Transactions was originally meant for such gold-based currencies. The idea was never to eliminate the risk of the issuer, which is impossible, but rather, to devise mechanisms for the distribution of that risk in order to create a
user-centric system. This is the same concept, BTW, as the
provider-independent Tahoe-LAFS project."Tahoe-LAFS is the first Free Software/Open Source storage technology to offer provider-independent security. Provider-independent security means that the integrity and confidentiality of your files is guaranteed by mathematics computed on the client side, and is independent of the servers, which may be owned and operated by someone else."The original idea with Open-Transactions was to implement this same concept for money.
In the video, the examples were game tokens and grams of silver. Redemption obviously means that the holder gives the tradable digital issue back to the issuer in return for... something (game tokens or silver, in this case). Any reasonable issue is going to identify that for which the digital currency can be redeemed in the contract that defines the issue. My question is what happens when the issuer fails to honor that contract?
If someone is holding your physical gold, and then he refuses to give you the gold back, then you have lost your gold. This, as I said, is absolutely inescapable except for purely blockchain-based currencies like BTC.
...So what can you do? There's always the
"Jim Bell" solution, or the
"crappy court system" solution. Or the
"insurance" solution. Or the
"reputations tracking" solution.
What I settled on with OT was
basket currencies. That is, to distribute the risk of a single currency across multiple issuers, such that the loss of a single issuer does not result in the total destruction of value, of that currency.
Another piece to this is
jurisdictional arbitrage. Which is to say, these multiple issuers should all be located in different jurisdictions. To their credit, the Ripple team is exploiting this mechanism also, in their own way.
What I would expect to happen is that the holder of the issued currency sues the issuer in civil court and presents the evidence of the contract in order to have the court decide in their favor. However, because the system is based on Nyms instead of names, the holder can expect it to be impossible to find the issuer.
I would think that the issuers are more likely to be publicly-known (by their choice), while the users would be the ones more likely to hide their identities.
If you give your gold to an anonymous entity, you are taking a much larger risk than if that entity is publicly-known. Of course, it is your choice to do so, and the free market will have to take its course.
So I ask: why would you choose an issuer who is anonymous, over one who has an agent available to receive service of process?
The solution to this problem is publication, so is there a mechanism in OT through which a Nym can be tagged as having failed to honor one of its contracts?
There is no such mechanism within OT itself, however, this is outside of the scope of OT.
A certain Nym ID is the same across all OT servers. Thus, there's nothing preventing tracking mechanisms from popping up -- reputation-tracking websites for example, or some form of
web-of-trust. But I think it would be better to use software especially suited for this purpose -- perhaps Monkeysphere?
One point though: The OT crypto is currently implemented using OpenSSL, which is able to verify identities through their certificate authority / PKI.
However, all the OT crypto is used through an abstract interface, the OTCrypto class, which is then implemented to use OpenSSL calls in a subclass called OTCrypto_OpenSSL.
It would not be difficult to make another subclass called, say, OTCrypto_GPG, and you could thus entirely swap out OT's crypto (currently based on OpenSSL) to use GPG instead.
I believe web-of-trust is available through GPG? So that might be one solution that could be built directly into OT itself, with little trouble. Then it could potentially verify the Nym's credentials via web-of-trust instead of CA / PKI.
But otherwise, as I said, it's probably better to track this outside of OT, using some other software which is especially designed to implement such functionality.
(After reading the thread, I have to add: Any colored coin tied to that issuer, either for the currency itself or for a basket currency that has it as a component, will change in value depending on the perceived likelihood of such an "Issuer default". And it's never a yes/no black and white thing until the moment that everybody capitulates to the fact that the issued currency is valueless. Until then, it will go up and down.)
The risk of issuer-default is inescapable for any "backed" currency. We cannot entirely eliminate risk; we can only devise better and better systems for the distribution of that risk in a wallet-centric way.
You are entirely correct about this, of course. The market will have to make certain decisions and they will take things such as jurisdiction into account. (As well as posted bonds, insurance, auditing protocols, reputation, etc.)
===>
See this article.I have some other questions too, one of which is this: If the private key for a Nym is compromised, does OT have a mechanism that (any) holder(s) of that private key can use to mark it as compromised?
I have recently added "credentials" to Nyms, meaning that Nyms can have master credentials, which are able to sign sub-credentials, which are then used for actual transaction signing. I have not yet added API calls for revoking sub-credentials, however they are coming.
If your master credential is based purely on a key pair, and then you lose the private key, well -- you are screwed. (Some would say this is a feature.)
However the idea is that your master credential could instead be based on a cert, issued by a traditional certificate authority. This way you could just get the cert revoked and have a new one issued in such a situation. (The risk, of course, then becomes the certificate authority itself, whom you must trust not to take over your Nym and steal all your money.)
A third concept (my favorite one) is to
use the blockchain itself to replace the certificate authority. A certain Bitcoin address could send a transfer (say a satoshi, to anyone) and store a hash in that transfer.
(The hash of a master credential...) This way, if you ever wish to revoke that master credential, you just send a new transfer with a new credential hash in it. (The verification process would just look at the hash contained in the
most recent transfer for that BTC address.)
This might seem like "turtles all the way down," since the power over that identity just gets transferred to a new private key (your Bitcoin wallet) which again, must be protected against loss. But it does provide a
universally-verifiable medium for credentials and revoking.
You might ask, why not use Namecoin instead of Bitcoin, for storing these credential hashes? The answer is because Namecoin names
expire, since they must be human-readable. In my case, I don't need human-readable -- just unique. Therefore, I prefer to use a system which does not expire. (Namecoin is still very useful as a DNS replacement, however.)
So my ultimate answer is, I plan to use Bitcoin itself to replace the Certificate Authority.
Is there a mechanism that allows the assets of a Nym to be available to some kind of "Nym heir," so that the mechanism through which the Nym is marked as compromised will cause its assets to become available to a different Nym?
Currently nothing like this is built-in, but it would be easy to add. You could also secret-share your BTC private key (used for issuing new credentials, in the above example) and then give the shares to various trusted family members. After all, as you noted, you wouldn't want to die and leave your wife destitute and starving on the street.
