He's going to speculate on a very volatile market. There is no guarantee, and the risks are high. Only buy with your cigarette money

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.

Ok, so from what I can understand, you want to create options and the means to easily (automatically) transfer the contracts. I will not comment on the sustainability of such a system, which I doubt for the moment, but I think it can be made to work.

My question is this: why would anyone want to transfer the put contract, too? Why would someone voluntarily give up his protection? Because, in the end, that's what an option is...

I see this scenario to be common: user Joe exchanges 300 USD for 100 BTC+ the put contract for 100 USD @ 3 USD. He buys stuff, maybe he also gets some coins by selling. He will keep the contract until he will want to exchange his coins to USD. If the exchange rate is higher than the contract, he will sell at spot price and be happy. If the exchange is lower than the contract, he will exchange 100 BTC at 3 and the rest at spot. If he doesn't have 100 BTC, he will buy at spot and use his option for some quick profit.

True for margin trades, not entirely correct for options. A risk-adverse businessmen will find options useful. One can buy options for the amounts needed to pay expenses and do a clean exit if the exchange rate plummets and the business is no longer profitable.

There's already a discussion about money transfer over Bitcoin here: https://bitcointalk.org/index.php?topic=48704.0 . I would love to hear your ideas.

Where I live, notarized contracts require the presence of both parties and cost more than 30 EUR...

@nelisky suggested that I should spam this thread with this link: https://bitcointalk.org/index.php?topic=48704.0

We need your input on the system proposed and, if you'll like it, the support of the legendary "Escrow League"

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

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

No. If you have fiat currency, you're already outside the Bitcoin network and into IRS' playground, where you need to follow their rules. If your bank account gets frozen, the rest of the Bitcoin network will not care.

As for the source of money, it's simple: you sold Bitcoins, which you either bought, or mined, or received in exchange of products or services. Why would you be afraid of IRS if you were doing legit trades? (You *are* doing legal trades, right?)

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.

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.

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

+1.

No need. Lovely Rita can have some 5 cents stickers to replace the demaged QR codes. She needs to be around to check that the spots are all paid for anyway. The more complicated part is how do the drivers make sure that Ugly Tina didn't put another QR code there to steal the money?

I love the idea!

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.

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

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