Topic: [BIZ] [IDEA] [RFC] International cash transfer via a Bitcoin-based network - page 2. (Read 6677 times)

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

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.

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.

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.

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

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.

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.

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

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?

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

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

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.

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.

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.

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.


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.

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


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.

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

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.

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.

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.


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.


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