Oh, I see it in the topic now, Tmobile. I guess the $400 price tag threw me off, as I can get it factory unlocked for ~€280, which is roughly $400. Come to think of it, your price is not as good as I thought initially, especially as shipping will add a premium to it.

Sorry for the time wasting...

It's not bound to any network, is it? Would you ship it to Europe?

Are your prices for real? I mean http://www.amazon.co.uk/Nico-BLIND-MELON/dp/B000002U4E/ref=sr_1_1?ie=UTF8&qid=1319667889&sr=8-1 c'mon...

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!

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?

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?

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.

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.


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

I'm not sure I get it... you mean the shelf would be connected to the POS and have a scanner there so you would flash your QR codes, grab the goods and flee? This is the middle man being the teller...

It is actually a great idea, but one more closely related to the bitcoin vending machine thread (that I'm too lazy to search and link), whereas this is about using bitcoin as 'just another payment system' on existing stores. I'm not sure we would be making many friends if we told people "And your employer can now sack you, because they have bitcoins!".

That is not necessarily true. Right now bitcoin is a marginal thing, but were it mainstream the blockchain would have the payment recorded and you would be holding the priv key to the address, so you could prove you paid 'someone'. If the recipient could be linked to the store on which you are buying (I know a script kiddie would just change the receiving address on the teller at mcdonalds, given the chance, but that's why merchants may need a blackbox approach to POS) and it would be left to the store to prove they sent the change.

Remember we are talking (or at least I am) normal stores, receipt at the end of purchase (maybe even stating the address they sent to so they are protected against people complaining they stole the coins) and good reasons to keep the customer satisfied (i.e., not go out of business). I'm not trying to push this as the ultimate solution for merchants, but rather one we can work on right now and is very much no-nonsense.

I assume this is not bound to any particular network?

Oh, and just to stress this point a bit more, the reason you can (could, to be honest, most places don't do it anymore) do offline transactions with credit cards is because the credit card company holds both sides of the deal in a tight grip; if the client didn't have enough credit, they'll not only allow the charge but also add fees and taxes to the client for going over the limit, and if the merchant did something bad, they keep the transactions hostage for a couple of weeks anyway, so they'll collect to repay the client without any extra cost to them.

That and they charge huge fees to both sides too, so they have plenty of leverage.

I think my original idea is much simpler than what is being depicted. You know how mtgox allows you to enter a privkey and they import that key and transfer whatever bitcoins are there into your account? Same thing, except mtgox becomes starbucks.

Yes, the merchant will need internet and bitcoin, but it can be as blackboxed or open as required, that's not the point. The real point is me, the client, don't need to have internet or a bitcoin client on my phone to make payments in bitcoin, and I also don't need to use or trust 3rd parties to hold my wallet, and frankly no change to the protocol and almost no change to the bitcoin client is needed.

This is very 'low tech', we're not sharing transactions, just bitcoin keys, and in a controlled way, so if I'm paying 17.85 and I share the priv keys to 18 btc with the merchant, that's the extent of what they can steal, even if I have 1000 btc in priv keys on my phone. The time to market on such a solution is very small and although it is not by any means perfect, still leaving the door open for a number of attacks, it is something anyone with a smartphone and a computer can use without any technical knowledge of what's going on behind the scenes. Hell, my father would be able to use this, if he had a smartphone that is

As for the merchant side, if you can convince one major merchant to use bitcoins and they understand what these are, 80% of the hard work is already done. I could easily tweak the standard bitcoin client to operate on both the client and the merchant side as described. Why didn't I do it? Sheer lack of time, but if enough people agree with the idea and noone else takes the lead I'll be glad to take a stab at it, just find me a physical brick and mortar store willing to try it out

Or I may be full of hot air, it is Friday...

I'm well aware of that, and that is not the case I'm trying to address at all. Ignore the educational videos, think about starbucks, a restaurant or a bookstore. Or any big chain that you already "trust".

Well, this kind of defeats the purpose of the thin phone app, which is to have very little logic and no connectivity requirements at the store. The use case I have is pretty simple, I travel a lot and don't have wifi / 3G available everywhere. On the other hand merchants are mostly static and have connectivity, so...


Yep, the merchant certainly has the tools to be able to have a good level of confidence on the collected funds. And if you take out the outrageous fees credit card companies charge them, as well as all the chargebacks, I'm sure merchants would be happy to suck up the fees to have faster block inclusions. This could very well be the leverage needed to increase the fee per block to a place where it becomes interesting for miners.


Yep, that is a great idea, I'd say that is pretty much mandatory.


With the backup and encryption, we could go as far as having the phone part be completely dumb. The thick client generates 10k addresses, encrypts the priv keys and provides encryptedpriv+addr+balance to the phone. The phone limits its action to managing the payments. No network on the go needed, ever, to handle these wallets. The only caveat, which already existed with my original approach, is that is I double spend (human error, software bug, malice, whatever) the merchant will collect 18 priv keys and realize one is empty, thus requests another one from me. At this point I refuse to pay (or I don't have any more btc available) and go home... both myself and the merchant hold the priv keys, and this opens a trust problem.

Proving the address had balance and it was in fact the merchant that stole is pretty easy, just look at the blockchain timestamps, but with no central authority I screwed nonetheless. Though I'm sure the merchant would not get any more business from me or any of my peers, which might be enough security right there.

I was walking around a Mall and thought this up, probably based on ideas stolen here and there on these fora.

An android (or whatever you smartphone flavor is) app that is capable of generating bitcoin keys, and knows a little bit about encryption. The idea depends on thick clients both at home and in store, but the 'wallet' becomes much simpler to handle:

I have 100 btc on my osx bitcoin client, and I'm going out on a shopping spree. I'm not taking everything with me, I guess 20 btc is enough for what I'm doing anyway, so I pair my phone and my computer and press 'load 20 btc into phone wallet'. There is a static 'change' address associated with the phone wallet.

Getting to the store, I buy some porn^H^H^H^H educational dvds and head to the teller, where they say my total is 17.85 BTC. I punch that value into my wallet app, enter my pin and a QR code appear. The store scans it and I get my receipt.

At home I see I have .15 in my change address, and linking the phone to the computer I click 'empty wallet' (that name is really scary) and 2 BTC are moved to the computer wallet.

---

So what happened behind the scene?
- Loading BTC into the phone wallet: The phone generated 20 addresses, stored the priv keys pin encrypted and gave the adresses to the thick client, which transfered 1 BTC to each of these, thus putting a total of 20 BTC in. The 'change' address is set if not already so.
- Paying on the store: When we punch in 17.85, and having 1 BTC on each address, the app provides 18 priv keys in the QR code (or codes, probably need more than one) along with the change address. The store scans, imports addresses and transfers to their own key. Maybe wait a few confirms, maybe not, depending on the value of the tx? Because they received 18 BTC they then send the change to the set address.
- At home, the list of pub keys is sent to the thick client, it checks the balance on each address and cross references with what the phone app says happened. It identifies the two addresses that still have a balance and requests the priv keys for these, transfering to the change address.

So the addresses generated by the phone are really 'use and throw away', and all the phone needs to do is manage what addresses have balance available. Not good for full offline use, but you don't need to have a bitcoin client on the phone, and frankly you don't even need the phone, but it does provide some security as the priv keys are always kept encrypted and you can even use multiple amounts per address, just like paper bills, and have a different pin for each value (say 50x1BTC + 3x10BTC + 1x20BTC, that would be 3 pins).

Just an idea, didn't quite think this through, but this could easily be implemented that much I'm sure of.

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

so... no way to buy these using BTC?

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.

Heh, Cali as in California, US, I assume. It is very common for US citizens to assume everyone else is located in the US, but you may also mean Cali in Columbia, so just making sure.

I'm in Europe and I'll bid 200 BTC for both 5870s plus the HP tablet, including shipping.