Sorry to keep asking, but I still miss one crucial point.
No problem. Excellent questions!
For all this to work, if Alice wants to buy bitcoins with dollars, at some point she'll have to put some money into the OT+BM ecosystem...
…and get money back out again. I assume by this you mean
"legacy cash money in hand" and/or
"legacy money in the legacy bank."--- Keep in mind that most transfers will happen
inside the OT system, or on the blockchain…
--- That is, while bailing legacy cash in/out of the system is possible, that should not happen for
each and every transaction….
--- Also keep in mind that once you bailout BTC or colored coins from an OT server, then it has passed outside the sphere of OT, and you can cash it out in whatever conventional way that you normally would, based on the existing market for Bitcoin services. (This would be an option as well.)
--- …Therefore I restricted my Bitmessage examples to only cases where the two parties
both are transacting
within OT. (The reason being that we can then assume that OT's powers apply -- such as markets and escrow.)
That having been said, here are various options I can imagine for bailing legacy funds into/out of the system …
=> Bitcoin ATMs. These were at the Bitcoin 2013 Conference in various configurations, and so the option is rapidly approaching to use them.
=> Through your social network: This was always what enamored me of the Ripple idea originally -- that instead of using a centralized exchange, you can just
"go through your friends." And if your
friend will hand you some cash in return for a
Ripple transfer, then similarly he should be willing to hand you some cash in return for an
OT or
blockchain transfer. (And vice-versa.)
=> Geolocation: Apple has recently publicized the concept of people providing ATM service for each other. Your iPhone just finds someone nearby who hands you $60. (At the same time, $62.50 is charged to your iTunes account.)
The same could clearly work for colored coins in a P2P app. (Even the open-source community could easily build such an app using OT -- though Monetas itself possibly could not, depending on the status of Apple's patent.)
=> SEPA transfer: In Europe, bank users can quickly and easily send transfers to each other's accounts through the SEPA API, and verify whether such transfers have been made.
=> Meetups: There are already local Bitcoin meet-ups; thus it seems like a viable method of exchange for cash.
=> Gateways:
(Ripple seems to have popularized this nomenclature, so I'm going to use it here.) This is any business that users are willing to trust for the purposes of sending/receiving bank wires, SEPA transfers, ACH transfers, etc.
===> The main difference here is that in the case of Open-Transactions, your funds would not be stored as an IOU from the gateway. Many have said that on this forum, but that is not actually the case. On OT, you are buying/selling BTC and colored coins, instead of issuing IOUs.
(Issuers
do have the ability on OT to issue IOUs, but that is not the solution I've suggested in this thread.
Rather, I've suggested to store the actual coins in voting pools so that an OT server can transact them without having to be trusted not to steal them.)===> In the case of OT, the
"gateway" becomes a
"trader". Instead of holding IOUs from a gateway,
you are purchasing or selling BTC or colored coins from a trader. And that Trader is NOT an OT server -- but another OT user, like you!
And since this transaction is occurring
inside an OT server:
- it will be instant, instead of requiring blockchain confirmations.
- It can be performed on a market, where orders are automatically matched according to their criteria.
- It can be performed through the use of escrow -- and the terms of that escrow can be customized by the parties (since the escrow itself is implemented as a smart contract -- and users can customize their own smart contracts.)
- Via Bitmessage, wallets can coordinate cross-server wiring of funds, as well as cross-server order matching, and cross-server discovery of other wallets willing to make transfers in/out of the legacy banking system, by way of OT escrow.
===> In any case, whether you are obtaining IOUs from a gateway (Ripple), or whether you are buying/selling BTC and colored coins from a trader (OT), either way, I assume that such businesses will be willing to take/pay cash at their physical locations, and bank wires otherwise. (Otherwise, why are they even in this business?) Therefore, you can move legacy funds in/out through such businesses.
Personally, I prefer cash-in-hand over IOUs, which is why OT places such a high value on the ability to
customize your escrow terms.=> Bank Wires: One example of why I prefer cash-in-hand: If you purchase precious metals for physical delivery, you will discover that orders
can be shipped based on a bank wire, yet the same business is
not willing to ship based on a credit card purchase (due to chargeback risk.)
Therefore bank wires are a valid method for getting money in/out of the bank account, albeit slow and expensive.
=> Bitcoin Exchanges: exchanges are one way to trade Bitcoins for national currency and get a bank wire, so it deserves to be on this list. Any BTC traded on an OT server could presumably be bailed-off of OT and cashed-in through a Bitcoin exchange (with the laws in that jurisdiction applying.)
=> The original issuer: In the case of colored coins, there is some issuer in some jurisdiction who originally created--and has agreed to redeem--those colored coins. Presumably he could be paid (and pay others) through BTC or through bank wires or cheques.
NOTE:
Most actual users shouldn't have to deal with this guy directly. Another note: Once users have uploaded these coins into multi-sig voting pools, they can then devise basket currencies to hold and transact with.
This enables users to distribute the risk of a single currency across many issuers.=> Prepaid card / bank card: It seems that a prepaid card could be given to the user, with funds placed onto the card easily enough based on whether the user had paid the card issuer on OT.
- Escrow probably not necessary in this case, and card issuers can demand to be pre-paid.
How can she be sure the person she wires her fiat money to (let's call him Bob) doesn't disappear, or claims he never received it, or otherwise screws her over?
She cannot, although the above examples are all different. This is why I place such a high premium on escrow, reputation, risk limits, and cash streaming protocols.
From what I've read, Bob has to put in some crypto currency as collateral, so that if he disappears with the money, he'll actually end up losing more than he took from Alice. Is this right? If yes, how can Bob be sure that whoever he pays collateral to, won't disappear with that?
If the money is stashed inside a smart contract on OT, then the OT server is incapable of forging any receipts internally, nor is it capable of stealing BTC or colored coins from the multi-sig voting pool those coins should be stored in. Therefore the holder (OT server) cannot disappear with those coins.
You might ask, but which party to that smart contract is ultimately going to get the funds, in the event of a dispute?
OR, what happens if Alice claims she wired her dollars to Bob's bank account, but she actually never did. Who's going to decide if Alice or Bob is right?
This is totally determined by the smart contract itself. And since these can be customized (through scripted clauses), then ultimately the open source community will have to decide for themselves, for the various cases, what is an acceptable distribution of risk.
For example, let's say that Jorg is receiving colored coins all day, in return for SEPA transfers. He might deal with scammers all the time, which is why he demands a smart contract where the funds go into escrow and he can verify their existence (safely stashed there) before initiating the SEPA transfer.
Also, let's say that his terms specify that once he notifies the smart contract of the initiation of the SEPA transfer, he is guaranteed that he will receive the escrowed colored coins after X hours, unless Alice files a dispute.
…And in THAT case, say the smart contract terms require the decision to then be rendered by Judge Judy (as the sample escrow contract in OT actually does.) And then things will either be proved to her, or they won't. (And if you don't trust Judge Judy's adjudication skills, then don't use a trader who insists on using Judy's contract.)
Jorg might have to operate based on a whitelist or even a blacklist -- but at $X per transfer, he'll be operating.
And remember, he's not issuing IOUs -- he's just buying and selling BTC and colored coins. He's also not operating an OT server, since he is actually just another user, like you.
Uhm, how can the OT+BM (or any non-banking) system put any constraints, control, or monitoring on wire transfers which occur only between banks? I mean Alice can say her SEPA funds are in the air, but who knows if they really are?
I'm not sure how this escrow thing works. Is that based on trust (and how is that assigned?) or some smart novelty that eliminates the need of trust?
Here is an article on
Open-Transactions smart contracts.--- To whatever degree that SEPA API calls are possible to
automate verification of transfers, then I'm sure those will end up being used.
--- To whatever degree transfer protocols are possible based on parties providing
manual notifications to the smart contract of certain payment events, those will be happening as well.
--- To whatever degree that
"Judge Judy" has to get involved and make a human decision,
in the case of disputes, then smart contracts will have to support that mechanism. (The escrow sample contract that comes with OT, already does this.)
---- To whatever degree that whitelists, blacklists, and other
reputations systems become necessary, (monkeysphere ?)
--- …as well as to whatever degree
risk limits and
cash streaming protocols will be used,
they will be, -- wherever they enable new transactions that people could not previously perform.
