Any colored-coin issuer can fully-obey KYC / AML.
Are you sure about it?
Something tells me that the simple fact that a colored coin issuer can't control where his coins go to already makes it impossible for them to implement such restrictions on most jurisdictions.
Wasn't that the very reason ecash was dropped by banks?
A colored coin issuer can demand KYC info from anyone converting in/out directly through that issuer.
Therefore the issuer is compliant. (Consult an attorney -- that's my opinion, and it's not legal advice.)
This is no different than MtGox is today: users are giving each other BTC all the time outside of MtGox -- but only the ones who cash out through a MtGox bank wire actually have to cough up their identification info.
Similarly, people could be giving each other colored coins all the time -- but only the ones who actually cash out through the colored coin issuer will actually have to cough up their identification info. (The coins that circulate outside their reach are comparable to dollars which circulate outside the reach of the Fed.)
... So for example, users could utilize local meetups...
...Or as I have proposed, users could use OT escrow in combination with SEPA to directly redeem...
Open-Transactions is always going to be about a wallet-centric solution, not a provider-centric solution. We want provider independence.
But to get fiat in and out, you'd have to go to your fiat-holder and then everything would be tracked as it is today.
As long as the issuer performs redemptions "of last resort" then technically,
you could move fiat in/out through any other user.You'd still need to trust your fiat-holder not to commit fraud or disappear with your money, but, for sure, that'd be a harder coup to play than disappearing with your bitcoins.
So, we would no longer need to worry with "trade engine lags" and alike, and we would no longer need to store our BTC in a shared wallet. Any other big advantage?
Question: Wouldn't a p2p marketplace for escrows which do not hold your fiat be even better than that? The escrows only need to intervene when there's a dispute. But traders are still responsible for transferring funds to one-another, as in OTC. BTC-funds would be locked in 2-of-3 addresses, waiting for the fiat transfer to complete. No "bank-account to hold them all". If you have an API to access your bank account (think merchants) you can even automate everything, as the look-up for escrows could be based on deterministic criteria.
This is similar to what I have proposed. Stick the BTC in a multi-sig voting pool for safety, and then use Open-Transactions escrow and Open-Transactions markets for the actual exchanges.
(Except in my proposal, everything is automated.)
From there, Bitmessage provides discovery layer. But there's no reason why OT itself couldn't have its own broadcast net, nor why we couldn't use something like IRC to serve that same purpose.
The only problem is this doesn't sound very user friendly. How can it all be turned into a simple web app?
Well in my proposal, I wrote:
The above protocols can be implemented inside OT wallet GUIs, such that they are automated and transparent to users.Why does that not sound very user-friendly?
People have often complained that OT was "too complicated" -- but I guarantee you they are wrong. (These complaints predate the high-level API.)
For example, see the
high-level API -- most financial actions can be done in a single line of code. Developers couldn't ask for easier.
And see the
screenshots for the upcoming iPhone app -- Users couldn't ask for easier.
I was trying to be nice by giving everyone a few years head start on creating their own OT clients... That doesn't mean easy clients aren't possible, because I personally haven't released one yet. It just means I wanted to allow others the chance to release them first. (So I could focus on the core library...)
Bitmessage sounds a bit unscalable, the white paper says you are attempting to decrypt every single message that comes in over the wire with all of your local keys... That would quickly get wasteful and cpu intensive
I should point out that most of the solution was latent inside Open-Transactions itself. I'm actually surprised no one else thought of it before -- I mentioned the idea on my FAQ years ago.
Bitmessage is very useful as the discovery layer -- but there's no reason why you couldn't swap in a different discovery layer.
For example, the same solution is basically just as easy to do by using IRC as the discovery layer.
I'm really tired of people confusing IOUs with value.
With cryptocurrency, you can move the Value online, but with fiat currencies, all OT and ripple can move is an IOU for that currency/commodity, and then you've created a central point of failure as people collect their IOUs.
I can't speak for Ripple (I haven't seen their code) but OT doesn't contain central points of failure.
Open-Transactions is user-centric, not provider-centric.
