[BIZ] [IDEA] [RFC] International cash transfer via a Bitcoin-based network

[ovidiusoft]

I thought a little about what should be the internal exchange rate used by the network. I believe that it should be spot or close to it. Here's why I think so:

Case 1. Network exchange rate is significantly lower than spot. The agents (nodes) will prefer not to accept cash from customers (that would force them to sell their coins to the network at a lower rate) and will sell their coins to a normal exchange.

The following exploitation is also possible: bad-agent's friend goes to another node and deposits fiat cash. He then proceeds to cash in the redeem code via the bad-agent. They now have the initial amount of cash (equivalent in coins). This can be repeated until all coins in their proximity have been attracted to bad-agent, who can then sell them at spot rate (significantly higher than what the network offers). They don't even need to start with a large amount of fiat cash, they can do this repeatedly.

Case 2. Network exchange rate is significantly higher than spot. The agents will prefer not to redeem codes from customers (that would force them to buy coins from the network at a higher rate). If they need coins, they can buy them from a normal exchange.

The following attack is possible: bad-agent uses what cash he has to buy cheap coins from a normal exchange. He then registers a cash in operation from a customer amounting to that number of coins, who then sends to the network. He then goes and redeems the code to another node, getting back more cash that he initially bought the coins for (from the normal exchange).

Conclusion: exchange rate should be close to spot. Maybe the network might even have a slightly narrower spread than popular exchanges - agents will get the best exchange deals from the network, and the network makes a little profit from the spread.

Comments?

[1713948897]

1713948897

[1713948897]

1713948897

[1713948897]

1713948897

[1713948897]

1713948897

[1713948897]

1713948897

[1713948897]

1713948897

[nelisky]

I believe a simple solution is to have an "agreement process", a hand shake on the transfers. So you have a client wanting to send €100 to my geographic region, we agree to do this (regardless of exchange, you say you'll receive the €100, I say I'll pay the €100 which I must already have) and that's that.

You ask me for a redeem code (which in fact closes the deal) and I give you the code + the bitcoin amount to be paid, based on bitcoincharts weighted averages (24h? USD because it has the most volume?) which you'll then proceed to send to me.

What I do with the coins is then my own responsibility, and if the market is going down I'll sell my own coins before you send yours, or if the other way around I'll set a stop order for the rate we agree upon, whatever.

The only caveat is I can be completely wrong and make a bad move, loosing most of my coins / cash. A rogue agent could decide to cut the losses and not deliver the transaction, disappearing from the act. So we need a 'warranty fund' to protect the sending agent and the client, which would be the initial deposit you spoke of, I assume.

Could work...

[brendio]

tl;dr: I thought about a similar idea to this some time ago, but in the end dismissed it as all the risk mitigation methods end up costing as much or more than the fees of the current providers you are trying to undercut.

I have two examples of how I think it could work:

Scenario 1: Sending agent receives $100 from client. Current ask price for Bitcoin is $5. Agent sends 20 BTC to receiving agent from agents BTC reserve. Agent may or may not choose to buy 20 BTC on an exchange to replenish reserve, depending on whether agent has balancing BTC receipts and their personal risk management strategy or view of BTC price charts.

Receiving agent receives 20 BTC. Current bid price for Bitcoin is $4.90. Receiving agent either sells received bitcoins or those from their reserve to net $98. Add agents fees of 0.5% at each end plus an exchange commission of say another 0.5% at each end and the recipient receives $96. Suddenly the total cost to send is up around 4% and making paypal look not too bad in comparison.

Scenario 2: Instead of the agents buying and selling bitcoin, the sender buys 20 BTC and a $5 put option. Both the 20 BTC and the put option are transferred to the recipient. If the BTC price decreases below $5, the recipient can exercise the option to receive $100 for the 20 BTC. If the BTC price is higher, they sell on market. The problem is the cost of the put option would likely be upwards of 5%.

Conclusion: I do not see a way around agents needing to add on at least the size of the spread at the order volume required, or an amount for an insurance premium to hedge against adverse bitcoin price movements.

[nelisky]

Conclusion: I do not see a way around agents needing to add on at least the size of the spread at the order volume required, or an amount for an insurance premium to hedge against adverse bitcoin price movements.

If we can assume agents are honest, we can at least assure a zero liability system;
- Agent A (sender) tells Agent B (receiver) to lock $100
- Agent B sells $100 of btc from market and tells A how many coins that took (X)
- Agent A receives $100 from client and sends X coins to Agent B
- Agent B gives $100 to other client

So now Agent A is +$100 and -X BTC, Agent B is -$100 and +X BTC. Say coins increase in price, Agent A can request X coins back from B at $100 and net will be 0 (except for the transfer of the $100, which may be factored as a fee)

Why do this? Why wouldn't B just sell the coins instead? Because this is not a "make money fast" scheme, this is a value transfer service. And you that because you know it works both ways. There should be an expiration on this agreement, of course, so if within 30 days A doesn't decide to exercise the buy option, that's that.

[ovidiusoft]

Replying to last 3 posts, in no particular order.

There is one assumption that I don't like in the scenarios and solutions you described: the fact that a customer pre-chooses the end node of the transfer. It's a restriction that I would like to avoid, if possible. Obviously, in most cases a single node will be available in a certain region (especially if we're talking about cash in hand). But that's not the case when dealing with local/SEPA bank transfers, for example - then we might talk about hundreds of nodes and the network might not know which one will pay up.

A little different than what nelisky wrote, my deposit/redeem process goes like this:

* sender gets a redeem code from the network. He can get it online or directly from a local agent. The code is stored on the network as 'empty'.
* sender deposits money (cash in hand, bank transfer or anything else) to a node (he could choose the node or the network might suggest one). The node confirms this by editing the redeem code and sending the corresponding BTC to a network collect address (not to another node). The code is now stored as 'full' by the network.
* sender gives code to recipient. Remember that at this time, the network has no idea where the recipient is.

* recipient checks the redeem code (online or directly at a local agent). The network will suggest a list of local agents (if the client is already in a location, hopefully the same node will be suggested, if it has enough cash) or automagically choose a node that satisfies the conditions (for example, if the client wants a local bank transfer, the network might have hundreds of nodes in that country).
* once a node receives a redeem code, it sends the appropriate sum to the customer and marks the code as 'paid'. The network will then send the correct BTC sum to that node's address and purge the code (maybe just keep the number to avoid collisions, but erase any attached data).

Notice that I intentionally didn't link the two nodes and I passed the BTC amount through a network collector address. This will allow the receiving customer to choose nodes or payment methods as he sees fit. It will also allow the code to be stored and redeemed at any later time (simple scenarion: I'm going to a European road trip, I make 10 small deposits that I will later cash in in random places in Europe, when I need money).

And this is where the problems begin . Exposing the customer to BTC rate fluctuations would be unfair. On the other hand, a few days between deposit and redeem is a loooooong time in Bitcoin world, and anything can happen to the exchange rate.

In a perfect world, each node would exchange to and from the network at spot exchange rates at the moment of deposit and redeem, because in theory, with enough volume, the network as a whole can afford it (I am also assuming that on the middle and long runs, the exchange rate will go up). Alas, we don't live in a perfect world, so I like nelisky's zero liability system, but using the network as a intermediary.

We need a hedging expert pronto

[semyazza]

To throw .02BTC in this sounds dangerously familiar to Hawala networks which are becoming illegal in many countries after 9/11.  The only difference is you are pre-negotiating the settlement of debt with Bitcoins.

[nelisky]

Hmmm, at the risk of repeating what has already been said, and pretending it was my own idea;

A simple option using, for example, mtgox (though we could leverage risk by using multiple exchange sites) would be to just buy the exact amount of fiat currency with bitcoins and then transfer that amount to the account of the other agent, or a central hub account. That cash would then be converted back to bitcoins at the date of the client withdrawal which, using the sites internal transfer, would mean no cash was actually flowing in and out, we would always and only get bitcoins moved:

- Client visits agent A and gives $100 to transfer
- A buys $100 worth of coins using his personal stash (on mtgox for this example)
- A gives bittransfer code to client
- Other client visits agent B and provides bittransfer code
- B asks A for 'the dough' giving him the code
- A sends mtgox voucher for $100 to B
- B converts to bitcoins at his leisure
- B gives $100 to Other client

A central hub could remove the dependency of original agent being awake and online. In fact, each exchange could easily behave as a central exchange using a feature like mtgox vouchers. I mean, we could use it *right now* by simply creating vouchers and giving them to the clients, while at the same time 'cashing in' vouchers for clients receiving money.

I would love to be able to 'brand' this, though, just to make sure the cash ins and cash outs stay in the agent network. For that to happen we'd need to ask exchanges to have a special voucher creation with a static prefix that only a specific group of people was allowed to both create and redeem.

[ovidiusoft]

A central hub could remove the dependency of original agent being awake and online. In fact, each exchange could easily behave as a central exchange using a feature like mtgox vouchers. I mean, we could use it *right now* by simply creating vouchers and giving them to the clients, while at the same time 'cashing in' vouchers for clients receiving money.
I would love to be able to 'brand' this, though, just to make sure the cash ins and cash outs stay in the agent network. For that to happen we'd need to ask exchanges to have a special voucher creation with a static prefix that only a specific group of people was allowed to both create and redeem.

I like it - it's simple and has the advantage that we can easily bootstrap it over the existing exchanges. We might not even need to customize the vouchers, if we keep them on a "our own" list inside the network and we only deal with our own redeem codes in relation to the customer.

[nelisky]

So there are two barriers that I can think of to just go ahead with that solution:

- Trust... We are keeping the vouchers inside the network, so A gets a voucher from mtgox and issues a redeem code to the client. How does agent B get that voucher without the intervention of agent A? A central DB needs to be developed to allow getting vouchers from redeem codes. It's simple, though, I can cook something up relatively quickly.

- Exchange rates... we are dealing with currencies other than USD, and maybe even receiving one currency and delivering another. These rates don't usually fluctuate as wildly as bitcoin, but they do fluctuate, so care needs to be taken when dealing with other currencies (other than USD, that is).

[ovidiusoft]

- Trust... We are keeping the vouchers inside the network, so A gets a voucher from mtgox and issues a redeem code to the client. How does agent B get that voucher without the intervention of agent A? A central DB needs to be developed to allow getting vouchers from redeem codes. It's simple, though, I can cook something up relatively quickly.

We can assume we have the full trust of the customer - he just gave us his money

- Exchange rates... we are dealing with currencies other than USD, and maybe even receiving one currency and delivering another. These rates don't usually fluctuate as wildly as bitcoin, but they do fluctuate, so care needs to be taken when dealing with other currencies (other than USD, that is).

It would be cool if we could create vouchers in all and any currencies, but I guess we can start with USD and let the end node exchange at his local exchange rate at the time of redeem. It's a risk that the client will have to take anyway with all the existing transfer systems and I see no way of avoiding it.

[nelisky]

- Trust... We are keeping the vouchers inside the network, so A gets a voucher from mtgox and issues a redeem code to the client. How does agent B get that voucher without the intervention of agent A? A central DB needs to be developed to allow getting vouchers from redeem codes. It's simple, though, I can cook something up relatively quickly.

We can assume we have the full trust of the customer - he just gave us his money

My point was between agents, the client side is covered as you point out. What I meant is if the mtgox voucher is created by agent A, when agent B gets the redeem code agent A gave to the client and needs the attached mtgox voucher code, he either needs to contact agent A or have some DB managing that. Just putting the mtgox vouchers on an open (to agents) pool and expect everyone to behave and only use the codes they actually are entitled to use is, at best, over optimistic.

- Exchange rates... we are dealing with currencies other than USD, and maybe even receiving one currency and delivering another. These rates don't usually fluctuate as wildly as bitcoin, but they do fluctuate, so care needs to be taken when dealing with other currencies (other than USD, that is).

It would be cool if we could create vouchers in all and any currencies, but I guess we can start with USD and let the end node exchange at his local exchange rate at the time of redeem. It's a risk that the client will have to take anyway with all the existing transfer systems and I see no way of avoiding it.

Yes, or the exchange rate used can be slightly higher than the interbank, just like exchange bureaus do (but no need to charge 10% plus or minus like these do).

[ovidiusoft]

I don't like the news that I'm reading regarding MtGox and TradeHill versus Europe. Having the nodes depend on a 3rd party to process the redeem codes doesn't seem like a good idea anymore. So I would suggest we move back to the idea of doing it all inside our own network of nodes. I know that it will make the bootstrap process harder, but I believe that it's necessary.

From a legal point of view, my latest idea is to have a central company created in a friendly legislature. This company will issue bonds that will be sold to customers. The bonds will not be nominal, so they can be send to another person and they could be redeemed from any other agent. The agents will be representatives of the central company. If this is possible and I'm not full of hot air, it would solve the VAT problem (as bonds are not normal sales, but loans).

Let's say that customer Bill wants to send 100 USD to his friend Jean in France. He goes to his local BitTransfer agents, pays 100 USD and receives a redeem code for 100 bond units issued by BitTransfer. He also pays the local agent's fees, which will be invoiced according to local laws. He goes home and sends his redeem code to Jean, who will then contact his local BitTransfer agent and get from him 100 USD converted to Euros at spot exchange rate, minus local agent's fees, which will be invoiced according to local laws.

What do you think, would that work?

[nelisky]

I'm positive that will not work, at least not legally. The bearer bonds you speak of are a great idea, although getting a company going somewhere bearer bonds are still allowed will be expensive. The thing is when a client gives you $100 and you give them the code you are selling them the code, unless we try to make this a "transport" service, where the client pays us to grab the $100 bill and move it to the recipient.

Thing is, every time fiat money gets moved as a service you are acting as a money service. That's a bank's job, plain and simple. The alternatives are selling things (and rebuying on the other side) or work in some other place more relaxed in the money tracking and taxes.

I do love the bearer bonds principle, though.

[slush]

I was thinking about similar idea almost year ago. I was in touch with some WU agents, asking them how it works internally. However I gave up the idea when I found that every agent in this decentralized network built on top of Bitcoin need to be registered as a currency exchange and do some AML reporting and so on (at least here in Europe). Doing this *legally* is very hard and expensive business.

[ovidiusoft]

I was thinking about similar idea almost year ago. I was in touch with some WU agents, asking them how it works internally. However I gave up the idea when I found that every agent in this decentralized network built on top of Bitcoin need to be registered as a currency exchange and do some AML reporting and so on (at least here in Europe). Doing this *legally* is very hard and expensive business.

What if every agent is actually an employee or a shareholder of a central company? (And yes, I do realize that being an employee opens another can of worms).

[slush]

What if every agent is actually an employee or a shareholder of a central company? (And yes, I do realize that being an employee opens another can of worms).

Then this company does not need bitcoin, because it will be yet another Western Union.

Doing this network decentralized is in the direct oposite of doing it legal.

[nelisky]

Wonder how Linden Labs goes about the Linden Dollars... I mean, it's in game, there's a central body, but in the end, is it a token as in some kind of good or is it money services? Do they have to comply with anything special?

[brendio]

Just wondering out load whether something like Open Transactions is a better fit than bitcoin for your service. I think it would help cut out a lot of the slippage associated with exchange fiat to bitcoin and then back to fiat. BitTransfer would issue electronic USD currency and agents could buy this with bitcoin. When client gives agent A $100, agent A gives them BitTransfer issued currency in OT. Client sends this to friend. Friend takes BT currency to agent B and gets $100 is return (minus fees).

[ovidiusoft]

Just wondering out load whether something like Open Transactions is a better fit than bitcoin for your service. I think it would help cut out a lot of the slippage associated with exchange fiat to bitcoin and then back to fiat. BitTransfer would issue electronic USD currency and agents could buy this with bitcoin. When client gives agent A $100, agent A gives them BitTransfer issued currency in OT. Client sends this to friend. Friend takes BT currency to agent B and gets $100 is return (minus fees).

Looks interesting, but it has the problem that it only solves the technical issues, not the legal or trust ones. I started this topic exactly because I want a publicity stunt for Bitcoin - so it needs to be legal and hard to take down.

On the other hand, this interesting topic just popped out: https://bitcointalk.org/index.php?topic=49854.0 .

The other legal solution that I can think of is some e-currency/e-wallet service like MoneyBookers and others, but using Bitcoins "on the inside". I like MoneyBookers because they have local bank accounts in all the countries they work on, so costs and hassle are minimum for the users. Unfortunately, it means it has to be centralized and specially registered... not what I had in mind (also considering the Bitcoin e-wallet companies' history), but it would still be useful and adaptable to our initial goals. Biggest problem of all will be huge startup costs I would do it, but we need an investor with big pockets...

[nelisky]

What about a reversed pawn shop approach? Don't know if there is any legal case to be made or I'm just doing some mental gimmicks but a pawn shop takes your stuff and pays you for it. It didn't *buy* you stuff (disclaimer; I never used a pawn shop, so I just assume this is the way it works). Thus you agree to let me hold your VCR, I agree you hold my $10. No transaction was performed per se.

Now, you come back and say you want the VCR back, I say "well, give me back my $10, plus $1 for my trouble". Lets ignore the +$1 for now, as this is profit and marks the whole thing as a business deal.

But say you can't come to the shop for some reason, so you give your girlfriend the paper slip I gave you to prove you are in fact the owner of the VCR (I mean, I can't remember everyone's face, right?), so your GF hands me the slip and the $10, I give her the VCR.

You see where I'm going... what if we could pawn fiat money? Maybe that is not legal, as legal tender is never owned by any person, we are just allowed to use it, so pawning something you don't own is a no-no for sure. But if we reverse the chain of events and you give me $100 back for the 'good idea (tm)' you will be pawning later in the day at some other location, and the some other person, holding the "receipt slip" goes in to some other branch and pawns the 'good idea (tm)' for $100, net profit is $0, and maybe we could get away with it?