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

[ovidiusoft]

Warning: Long post ahead. Please excuse any grammar errors or misused terms, english is not my native language.

I have been thinking of this for some time, and I believe the time is right to bring it to the public discussion table. The intended audience is Bitcoin *and* fiat currency investors. This is probably going to be a high risk, medium size investment (and by medium I don't mean 10 BTC, like some might believe, but 1000 BTC / 3-5000 USD/EUR). This is also not going to be a get rich quick, 3 months ROI business. It's also not going to be anonymous or concentrate power into the hands of 1-2 guys. It doesn't have anything to do with mining or alternatives to Bitcoin. Sorry.

Now, that 90% of the readers just moved to another topic, let's get to it.

I don't believe Bitcoin will replace fiat currencies in the next 10 years. It might not do it in our life time, even. I do believe that Bitcoin solved a few major problem we have with the banking system: speed, reliability, costs. So let's take what Bitcoin won't do and what it already does and make a service out of it: International cash transfers.

Let's imagine a few scenarios:

Scenario 1. Your 16 year old son is on vacation somewhere in Europe. He's going to visit the nice castles and visit with some friends. Except he's not. He got to that country, but he's actually going to drink for 2 days and call you when he lost his wallet with his cards and cash. He doesn't have a place to stay, what to eat, and it's a saturday!

Your son suggests to send him some stuff called "Bitcoins" than only exist on the Internet and on computers. He says he can buy food (and drinks, your intuition says) with them, and also find a place to live, until he can get his passport back so he can return to his next 5 years of being grounded.

You're not good at computers, but he tells you to go to a specific address (just 3 miles away!) and use a ATM-like machine (it has BitTransfer written all over it). You insert some cash, enter his Bitcoin address and go home. 60 minutes later you son calls you to say he's now fed and on his way to a hostel. You sleep well.

Scenario 2. You're a successful GLBSE investor and your Bitcoin wallet has a lot of coins in it. You check out the exchange rate and it's now 25 USD/BTC. You feel good. You also think about your granny, who now lives alone and her pension fund (read: Ponzi scheme) is not doing as well as your Bitcoin investments. You decide to send her a little help.

You start your browser, open the BitTransfer (TM ) website and fill a little form. You send some BTC to the address on the screen and you know that in a few hours the USD equivalent will be transferred to your granny's debit card. You call her and tell her you love her.

Scenario 3. Bill couldn't find decent work in his country so he decided to work for a few years in another country. It's hard work, but he makes 3-4 times the average wage in his country. His wife and kids miss him, but they understand that this is necessary. All he can do for them, except video-chat daily, is to send them most of his paycheck. At least they can live a decent life now.

He gets paid cash, he goes to the nearest WU and sends the money home. His wife then goes out to her local WU and gets local currency. Every time he does that, he thinks that the 40-50 Euros in fees could buy a new pair of winter boots for his son. Oh well, he'll have to use the ones he has, even if they don't fit that well anymore.

Today is different, he just found out about BitTransfer from a colleague. He gets his salary and goes to a BitTransfer office down town. He gives out his money to the clerk and receives a code. They even send the same code by SMS to his wife's cell phone, including the address of the nearest BitTransfer office in her town. Just 20 minutes later she calls him on the phone. She's happy - she received more money than usual. She tells Bill not to call her at home in the next few hours - she'll be out to buy their oldest son a new pair of winter boots.

***

Ok, that was dramatic on purpose. But these scenarios are all real, and I'm sure you had one or another happen to you or your friends. If you want to send small amounts of cash from one part of the world to another it's going to be slow, painful or expensive. Or, most common, all of the above.

Well, not if we can do something about it.

I'm thinking of a network of nodes that will act more or less like a WU office. The nodes can be real offices with clerks, ATM machines or automatic systems linked to bank accounts and Bitcoin addresses.

A node will accept these from a customer: fiat currency (at least local, but major foreign currencies might also be accepted), Bitcoins and redeem codes. I'll talk about Scenario 3 from above, because it's the most complicated and also I believe it's going to be the most common. I imagine a process like this:

* The node maintains some Bitcoin and fiat currency ballances. How many of each will depend based on real world usage. Some nodes might be used more for sending money, so they don't need to have a lot of fiat cash, others, on the contrary, will be used to get cash so they need to have more fiat cash available.

* The customer walks in with cash and asks to send money to a specific area (city).

* The node clerk reserves a BitTransfer redeem code and sends the appropriate amount of Bitcoins to "the network" (more about this later), after subtracting his comission (and local expenses, if that's the case).

* The clerk takes the money from the customer and gives him the redeem code. Also, if needed, he informs the customer on the nodes in destination town, sends the code by email or sms and so on.

In another part of the world, this happens:

* The customer walks in and provides the clerk with a redeem code.

* The clerk checks that the code is valid and gives the client his money, after substracting his comission (and local expenses, if that's the case) (the network comission was already substracted by the network).

* The redeem code is invalidated by the network and the corresponding Bitcoin transfer is sent to the paying node.

Now on to the more technical part:

I believe that we should do our best to make sure that we are running a legit business, while at the same time making the network resistent to legal threats (it's safe to assume that one time or another someone will want to take us down) and bad nodes.

So the network should run on servers distributed throughout the world. The servers should be operated by a company opened in a safe part of the world. Anonymous company in Seychelles or the likes seems like a good idea.

Server side, I know enough about security to understand that we can't secure everything, but having the servers check on each other and using strong cryptography is common sense. Fortunately, because nodes only exchange Bitcoins with the network, we don't need to store a lot of data on the network itself. We can use pre-generated green addresses and (maybe) keep the wallets offline.

Nodes should not be trusted by default either. One can easily imagine a scenario where a rogue node asks a redeem code from the network, but doesn't give that cash to the customer and lies to him (code not valid, network is down, please come back tomorrow, etc). Or a scenario where he accepts cash from a customer but doesn't register the operation on the network and makes up a redeem code.

Some of these risks can de covered by first getting Bitcoins from the node and only then providing the redeem code; by not sending the Bitcoins to the node until we have some sort of confirmation that he paid the cash to the customer (ideas on how to do this?). A security deposit is another idea - a sum that will be stored by the network and used "just in case". We might even impose a limit on the amount of operations that a node can do in the first few months, based on the security deposit. And of course, there will be a need for signed contracts and real IDs.

The most important business/process problem will probably be making sure that a node has enough cash or Bitcoins so it can correctly process payments. Let's say that if a node doesn't have enough Bitcoins it can refuse to take cash from customers, but if a node doesn't have enough fiat cash and a customer wants to cash in a redeem code, that would be pretty bad. I don't have any fail-proof idea for this yet, except impose limits and pre-shedule payments.

A note on anonimity: I said that nodes will not be anonymous - this is to guarantee that they operate a legit business and don't easily run away with customer money. I also said that the network should be operated semi-anonymously, to protect if from take downs.

There is, however, no reason not to make sure the customers are anonymous (or as anonymous as legally possible). If I don't need to show my ID when I'm buying a cofee, I see no reason to ask for personal data when someone buys a redeem code from BitTransfer.

I am certain that in most jurisdictions individual nodes can figure out a way to sell and buy the redeem codes in such a way that they operate legally while protecting customers' identities.

Next, the business part. I mentioned in my long story 3 comissions: the two nodes and the network. Local fees will also be substrated, if necessary (for example, a customer who wants to cash in a redeem code via local bank transfer will receive a little less, as the node needs to pay the bank for that).

The network's fee should be fixed independent of the amount transferred. For the end nodes, that's probably not a good idea - a node will preffer not to "block" his money with a large transfer - for the same amount of money he could make more if he gets more smaller transfers. So a percentage based on the sum seems like the correct solution for that.

I didn't do any real simulations on these, but 0.4 BTC network fee and 0.3 BTC + 0.25% of the sum for each end node seems fine for me. That makes a total of 1 BTC + 0.5% from sender to recipient. If Bitcoin exchange rate goes up, the fees should go down as well, of course.

For 100 USD (@3.2 BTC/USD), that would be 3.7 USD fee, recipient gets 96.3 USD. For 500 EUR (@2.5 BTC/EUR), that would be 5 EUR fee, recipient gets 495 EUR. Compare it to this: http://www.westernunion.ro/WUCOMWEB/staticMid.do?method=load&pagename=mtOBFees

***

Did anyone actually make it here? Did you read everything or just scrolled down? I'd love to know what you think. As you can see, this project is too big for a single company, we need to be at least a few tens local agents to make it succeed. This is why I wrote such a lengthy post - I can't do it alone, I need your help.

If you believe this can work, join me and let's make it happen!

[1714800912]

1714800912

[MaxSan]

Ok this is a great idea but your making things VERY difficult for yourself..

Why not use a ready established network and just charge lower margins than _every other money transfer company_

By using a system like PayPoint or Payzone to get instant coverage and pre set out business.

What you think of that?

[Doing it this way you really could do it by youself with a little bit of capital and time. If you decide to go ahead I do want a donation if your successful as its a cracker of an idea and relatively simple to do. ]

[ovidiusoft]

The main reason is that I don't want to create yet another payment system, but a Bitcoin transfer system. I want Bitcoin written all over the place .

The other smaller but important reasons are that: I don't believe we could get that lower margins with any existing system and I don't want to have a single point of failure. Worst that we should allow to happen would be that some money doesn't reach the destination and gets returned to the sender (the scenario where a node simply disappears).

Also, I want to be simple to add new nodes to the network - someone should simply provide proof that he has the money to open a node, register to the network and start servicing people. Opening a new Paypoint/Payzone and friends POP is difficult (and might not be possible in a random country/region).

[jago25_98]

Payzone etc is great for deposits but how to do withdrawals that are truly local?

[MaxSan]

give them back the ticket and give them cash? we just have a token system in place to buy / sell coins on behalf of... kinda like how ukhash works but you can replace with real cash rather than there shite.

[conspirosphere.tk]

I would like a totally anarchist system with no agencies (and regulations and taxes), but just agents/mules that you can find at any time with a system like google latitude. They would take most of the cut and be available to meet clients in their area.
Many immigrant communities in my country use informal systems of this sort to send money back to their countries cheaply.

[ovidiusoft]

give them back the ticket and give them cash? we just have a token system in place to buy / sell coins on behalf of... kinda like how ukhash works but you can replace with real cash rather than there shite.

I didn't understand what you're saying. Sorry, english is not my native language, so if you could rephrase that...

[ovidiusoft]

I would like a totally anarchist system with no agencies (and regulations and taxes), but just agents/mules that you can find at any time with a system like google latitude.

These already exist, there's no need for me to re-invent the wheel. These are also in a gray legal area or illegal, and can't be trusted by the large public. I'm trying to create a valid business, a legal alternative to WU and the likes, while promoting Bitcoin at the same time.

[nelisky]

So I'd be an agent, someone would give me €100 to transfer to the US. I would log into the 'exchange network' where every peer is known and trusted and would find an agent that was close to the transfer destination. I would already have both bitcoins and cash balance on that exchange somehow (like a closed mtgox) and would ask to sell €100 worth of bitcoins to that agent.

The other agent would receive €100 worth of bitcoins and would then proceed to deliver the €100 he already has to the recipient.

Each agent would have to have some cash and some bitcoins to start with, register in the 'exchange network' and agree to buy and sell coins at whatever exchange rate is set there. This exchange rate could very well be 0.0001 or 1000.0, so as long as everyone agrees to use it, but obviously to prevent greed taking over people it should closely follow the external exchange rates.

Now, what's in for the client? No nonsense transfers, very low fees, quick as can be.
And for the agent, there should be a simple fee structure, this is not something I can just make up without giving a little thought, and might be a deal breaker if a structure that is both cheap for the client and interesting for the agent can't be found.

The exchange is the "central" point of this whole endeavor, and we might actually be better off with something more distributed, but I can't see how, bar trusting everyone, we can do without some central handling of the fiat part.

And keeping it legal or not is, at best, a matter of opinion. If you mean 'US' legal or 'EUR' legal, that might be possible. Both legal at the same time, slightly more complicated. Worldwide legal? No way that is even remotely possible!

[ovidiusoft]

Each agent would have to have some cash and some bitcoins to start with, register in the 'exchange network' and agree to buy and sell coins at whatever exchange rate is set there. This exchange rate could very well be 0.0001 or 1000.0, so as long as everyone agrees to use it, but obviously to prevent greed taking over people it should closely follow the external exchange rates.

Not all nodes will need both BTC and fiat cash, it's expected that some nodes will be mostly used for sending or (most likely) receiving. A node in a rural region will mostly pay out (because their relatives send them money - see scenario 3). This node cand start with 0 BTC and (a lot of) fiat cash.

BTC value should follow closely real exchange rates, because each node will have to manage their own balances by selling or buying BTC. The node in the example above will have to sell the coins to get fiat cash or he will stop being able to pay soon.

The exchange is the "central" point of this whole endeavor, and we might actually be better off with something more distributed, but I can't see how, bar trusting everyone, we can do without some central handling of the fiat part.

I thought about it but I don't have any idea other than the consensus of all the nodes. The security deposit should help a little, but in the end it will be about trust and following the rules.

And keeping it legal or not is, at best, a matter of opinion. If you mean 'US' legal or 'EUR' legal, that might be possible. Both legal at the same time, slightly more complicated. Worldwide legal? No way that is even remotely possible!

McDonalds operates legally in every country. If they can do it, I am sure we can too. Anyway, this is every node's responsibility and we can't really enforce it. As long as it doesn't affect the network as a whole, every node should do as they see fit (what and how to invoice, deal with VAT if they have such a tax, and so on).

[nelisky]

McDonalds operates legally in every country. If they can do it, I am sure we can too. Anyway, this is every node's responsibility and we can't really enforce it. As long as it doesn't affect the network as a whole, every node should do as they see fit (what and how to invoice, deal with VAT if they have such a tax, and so on).

Ok, you really think that sending money from the US to Iran is the same as mcd selling burgers in both US and Iran? Well, I wish you the best of luck with that

Seriously, though, you can operate legally on *each* country, I'm sure. If all you do are internal transfers you are home free, bar whatever prohibitive taxes and regulations your country might have, but sending money abroad is not the same thing at all, I'm sure you'll agree.

[ovidiusoft]

Seriously, though, you can operate legally on *each* country, I'm sure. If all you do are internal transfers you are home free, bar whatever prohibitive taxes and regulations your country might have, but sending money abroad is not the same thing at all, I'm sure you'll agree.

Of course I do. But the network or the nodes are not sending money. The network is sending/receiving Bitcoins - that's certainly not money. The nodes are buying and selling codes written on a piece of paper, to and from local customers. If those customers send their codes to another country, that's their choice (and their legal exposure).

I'd say the system I described works more or less like gift cards systems from retailers like Amazon, except we also offer buy back.

IANAL, but I think we can find a way to work legally. Or we should at least try.

[nelisky]

Of course I do. But the network or the nodes are not sending money. The network is sending/receiving Bitcoins - that's certainly not money. The nodes are buying and selling codes written on a piece of paper, to and from local customers. If those customers send their codes to another country, that's their choice (and their legal exposure).

If you think about it from a business standpoint, at least based on how it goes around my geographic area, you'll have to charge VAT to your clients because you are selling them "goods" (code in piece of paper). And you pay taxes over the profit you make, so in order to "keep it real" you have to get invoices from those that sell you the codes, and these will be in whatever currency the deal is completed in (BTC isn't officially exchanged, so are we talking barter?). It's easy to see how this can become over-complicated if your business is not to be known as transferring the value, be it in fiat or codes. If you are reselling you have to buy them, and all needs to have proper paperwork.

But forgetting about the legalities of this, and believe me that while I'm playing devil's advocate I am *really* interested in this, here's something that could help in balancing the books across agents; future options. I have a client that wants to send €100 to the US, I ask you how many coins that'll be and  you say 100.0. While this price may or may not be realistic, I send you the coins knowing that:
1) you will send the €100 to the recipient
2) you agree to buy me the same amount at the same rate, so I can ask someone on your physical surroundings to just send the €100 back to me if all you do is get bitcoins at very low prices from me

[ovidiusoft]

If you think about it from a business standpoint, at least based on how it goes around my geographic area, you'll have to charge VAT to your clients because you are selling them "goods" (code in piece of paper). And you pay taxes over the profit you make, so in order to "keep it real" you have to get invoices from those that sell you the codes, and these will be in whatever currency the deal is completed in (BTC isn't officially exchanged, so are we talking barter?). It's easy to see how this can become over-complicated if your business is not to be known as transferring the value, be it in fiat or codes. If you are reselling you have to buy them, and all needs to have proper paperwork.

I'm in a VAT zone too. I don't know about other countries, but I can create a new company that doesn't pay VAT - there is a limit of 35k EUR/year, after that you get switched to VAT. It's a start, though, and I can figure out other solutions later. When I'll have 35k volume through my node I'll afford a real accounting expert

here's something that could help in balancing the books across agents; future options. I have a client that wants to send €100 to the US, I ask you how many coins that'll be and  you say 100.0. While this price may or may not be realistic, I send you the coins knowing that:
1) you will send the €100 to the recipient
2) you agree to buy me the same amount at the same rate, so I can ask someone on your physical surroundings to just send the €100 back to me if all you do is get bitcoins at very low prices from me

I thought about something like this, but I discarded the idea at that time because I see no way of forcing a node to sell or buy BTC at a fixed rate. Also, what would happen if a node just decides to leave the network? I intentionally left the balances' management to the nodes themselves. They can trade locally, speculate on Gox or TH, or they can do future options with other nodes, if they wish. I might be wrong, but I think that would work for well-balanced nodes only? A node that mainly receives cash would have to buy BTC at "real" exchange rates or risk being blocked until someone decides to redeem a code.

[nelisky]

I'm in a VAT zone too. I don't know about other countries, but I can create a new company that doesn't pay VAT - there is a limit of 35k EUR/year, after that you get switched to VAT. It's a start, though, and I can figure out other solutions later. When I'll have 35k volume through my node I'll afford a real accounting expert

Well, I could do the VAT exempt thing too, but unfortunately you can't run a company without a real accounting expert around here, and that costs money Still, I'm sure there are many options, you are right.

I thought about something like this, but I discarded the idea at that time because I see no way of forcing a node to sell or buy BTC at a fixed rate. Also, what would happen if a node just decides to leave the network? I intentionally left the balances' management to the nodes themselves. They can trade locally, speculate on Gox or TH, or they can do future options with other nodes, if they wish. I might be wrong, but I think that would work for well-balanced nodes only? A node that mainly receives cash would have to buy BTC at "real" exchange rates or risk being blocked until someone decides to redeem a code.

No reason for it to only work with well balanced nodes, as you can always buy through the existing methods (transfer, WU, PP, etc) if you need to move cash into coins. There would be very little risk, assuming the nodes trust each other.

Speculating with the coins used on the transfer is a great recipe for disaster imho. Not all of us are good traders, most of us are simple emotional persons which, without proper training and a definitive plan will only feed the sharks, as I'm sure many noticed recently :p

Anyway, how would you and I go about starting this? We'd just agree to buy and sell coins from each other with the promise to delivering the the proceeds of the selling to some person, physically? I'm game for a little experiment, but I'd like to have the actual network shielded from the forum. Basically a network of peers is needed, and we should keep these only known amongst themselves, then when someone needs to send cash they'd post/email/pm one of us (and I mean you ) who'd forward to the closest person geographically?

I would love to see the old and trusted members of this forum to step forward to build the agent network! Again, I'm game.

[ovidiusoft]

I have set up a wiki where we can register our location and methods of receiving/sending money. We can also brainstorm about processes there. PM me to get an account and the link.

[nelisky]

Maybe S3052 could help manage the initial deposit fund and even guide the agents on to the most profitable route to handle the coins received... I'm sure we could get to some kind of arrangement.

[BitterTea]

Every now and then I sit down and try figure out a scheme by which bitcoins can easily be purchased (on a large scale) quickly, safely, and easily with digital fiat currencies.

Every time I've done this, I inevitably come to the conclusion that if it were quick, safe, and easy to do, bitcoin probably wouldn't exist.

Best of luck to you if you can figure out how to solve these problems.

[nelisky]

Every now and then I sit down and try figure out a scheme by which bitcoins can easily be purchased (on a large scale) quickly, safely, and easily with digital fiat currencies.

Every time I've done this, I inevitably come to the conclusion that if it were quick, safe, and easy to do, bitcoin probably wouldn't exist.

Best of luck to you if you can figure out how to solve these problems.

I go through pretty much the same thought process recurrently, but I don't think that's the itch we are trying to scratch here. You mention buying bitcoins with cash, whereas in this system proposal bitcoins are an inner and undisclosed part of the system, at least to the client / user. This is a means of using bitcoins as a transport, not as a product.

Though a well trusted network would go a long way if also accepting to sell coins for cash... just sayin

[ovidiusoft]

Every now and then I sit down and try figure out a scheme by which bitcoins can easily be purchased (on a large scale) quickly, safely, and easily with digital fiat currencies.

In person, cash-BTC exchanges seem safe and fast enough for me. For amounts less that 100 coins I wouldn't even wait for more than 1 confirmation. The costs of doing a double spend attack to gain 3000 USD (while also meeting in person), are simply ridiculous. I'd wait 6 confirmation for 50.000 coins

But as @nelisky said, that's not the problem we're trying to solve here. On the other hand, nodes have the means to do direct exchanges and I believe they will (see scenarios 1 and 2 from the initial post, they can easily be simplified to "one guy walks to a BitTransfer office and buys/sells some coins").

[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?

[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?

[ovidiusoft]

I'm not very familiar with pawn shops either, but in here it's a borrow contract with a physical warranty. The pawn shops are "non-banking financial institutions" (exact translation) and they have rules and regulations. Anyway, using fiat cash as a warranty seems even less legit than all the other approaches we thought about ) )

[Inedible]

Looks interesting but I'm curious, how does this not come under money laundering laws in many countries?

Say I want to transfer $100,000 to Russia - wouldn't this go against both countries laws?

Legally, I can't see it being different to taking a bundle of fiat notes and flying over to Russia with them.

[nelisky]

Looks interesting but I'm curious, how does this not come under money laundering laws in many countries?

Say I want to transfer $100,000 to Russia - wouldn't this go against both countries laws?

Legally, I can't see it being different to taking a bundle of fiat notes and flying over to Russia with them.

So, you are American, right? I say this because you mention "I send from here to Russia" but never say where "here" is, which is very... american

Don't take it personally, I make this joke every chance I get, and I get a lot of chances around here. But jokes aside, you are correct that it can be tagged as money laundering, because that's the 'catch all' that governments use to justify the control measures in place. Imagine that you live in the States and have a 2nd degree cousin in Russia, with which you have a very close relationship. Now, you have a friend in Russia, completely unrelated to your cousin who is having some issues paying for something or another. You mention this to your cousin, ask him to give the guy some cash and promisse to pay him a fancy dinner next time you're together.

Money laundering? No money moved across borders, and for all we know, this is the exact same thing that happens with our service, unless fiat money is in fact moved across borders. Now the real catch is bitcoins and the fact we get fiat money for them. If we where able to operate properly balanced agent nodes, where only bitcoins where ever moved and never converted to cash then it would be no different from the case presented, but even then governments could call it money laundering and shut it down. Only if we can make this legal and taxable will the governments leave it be, because it is in their interest and, to be legal, we would need to get rid of the pseudo anonymous nature of bitcoins and collect all the same data about clients that WU and the like do... not my perfect scenario.

But I digress, I just wanted to make the joke!

[Inedible]

Money laundering? No money moved across borders, and for all we know, this is the exact same thing that happens with our service, unless fiat money is in fact moved across borders. Now the real catch is bitcoins and the fact we get fiat money for them. If we where able to operate properly balanced agent nodes, where only bitcoins where ever moved and never converted to cash then it would be no different from the case presented...

I'm not sure that's true. Bitcoin would be the currency and that has moved.

[TiagoTiago]

... 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.

...

What about public key cryptography?

[TiagoTiago]

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?

They don't buy Linden Dollars from anyone, they only sell it; when people sell their L$ they are selling it to other people, not back to Linden Lab (notice the use of singular, it's only one lab).

[matonis]

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.

Yes, very similar to hawala, although hawala probably serves the function better currently because of the pre-established trust. Existing without paper and/or transaction records for nearly 2000 years, hawala is nearly impossible to prove. Bitcoin solves the clearing function of hawala but not the settlement-into-local-currencies function. Therefore, any bitcoin exchanger/point-of-transfer in a country that is not on the FATF/OECD blacklist will have to comply with AML and KYC guidleines.

[chickenado]

Ok, you really think that sending money from the US to Iran is the same as mcd selling burgers in both US and Iran? Well, I wish you the best of luck with that

But you are not sending money from US to Iran.

You are sending money from US to US, from Iran to Iran, and from btc address to btc address (A btc address has no geographical location of course).

Note that no fiat currency ever needs to leave either the US or Iran for this to work.

[matonis]

Ok, you really think that sending money from the US to Iran is the same as mcd selling burgers in both US and Iran? Well, I wish you the best of luck with that

But you are not sending money from US to Iran.

You are sending money from US to US, from Iran to Iran, and from btc address to btc address (A btc address has no geographical location of course).

Note that no fiat currency ever needs to leave either the US or Iran for this to work.

Important thread. This is how correspondent banking works, with the money center bank in the middle with offsetting correspondents in local jurisdictions. Knowing all the local bitcoin exchanges would allow anyone (almost anywhere) to receive and then sell bitcoin; however, the majority of exchangers are now registering and becoming AML compliant in their countries of origin, which entails identity verification of exchange clientele. This is still an evolving legal area and certain jurisdictions are evolving faster than others. In fact, some bitcoin exchangers are actively promoting regulation, thereby seeking to legitimize themselves (i.e., Intersango). I cover this in my post http://themonetaryfuture.blogspot.com/2011/11/air-guitars-and-bitcoin-regulation.html

Also, see this Reuters article, Bitcoin exchanges offer anti- money-laundering aid http://www.reuters.com/article/2011/06/15/financial-bitcoin-idUSN1510930920110615