It might come as a shock, but the world is a little larger than USA. For us not fortunate enough to live in USA or in a established SEPA zone (that is, where SEPA transfers don't cost exactly as a wire), credit cards / paypal are the only cheap and fast ways of paying. Even getting LRUSD is a pain.

OP, no matter what you do, don't forget to secure your wallet.dat

I believe we really should. Auditing all the code used is an important step for any serious business. Sure, maybe the investor doesn't have the technical knowledge to do it himself, but I would expect that someone who wants to push 1mil $ in a Bitcoin business will spend a few k to have someone audit the code (note: maybe not this week, but having this kind of investments will happen).

And I'm saying this because I believe it's important to expect audits and I think code should be written and documented with that in mind.

Well, money transfer is a complicated matter, one that is still not completely solved in a reasonable way by current systems. My plan was to create a system transparent to the user, easy to understand (give me your cash, get this code, send it to your friend and he'll exchange it for cash), fast and cheap. I am starting to think that's not possible, though...


This sounds good and the system you describe is simple enough. What I'm not sure about is how easy it would be to buy and sell bonds (or EFTs) in <random location here>. It might simply be way to complicated or expensive, or both.

Anyway, following with interest! If what you suggest is possible, count me in.

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

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

@JackH, you seem to know a lot about the subject, you care to give us a hand? https://bitcointalk.org/index.php?topic=48704.0

They don't, not anymore. They gave up information to USA and sold databases to Germany (and no, please don't tell me that was some rogue employee who stole a CD from the datacenter, I know enough security to realize that it's much more common that Germany put a lot of pressure on the banks and then bribed them).

I wouldn't consider banking as being private anywhere in the world anymore.

Just in theory. In reality, SEPA transfers from Romania (I didn't check TO) cost and take the exact same time as regular international wires. I checked more than 10 major banks until I gave up.

Download them from GitHub[1], there's a SHA1 sum file there you can chech agains. But if you want security, you should really download the source code from GitHub, audit and compile it yourself.

[1] https://github.com/bitcoin/bitcoin/downloads

Hey, this project looks great. I see you already thought about plugins, so I guess every vendor or exchanger can expand it so you can have automagic currency exchange and even in-app buying (for example, I would love an implementation for SpendBitcoins.com).

Did you think also of supporting multiple real and crypto currencies? With the appropriate plugins, one could have available a number of Bitcoins (local stored or in various exchanges and e-wallets), *coins (like Namecoin, which might also come with a plugin that will enable domain administration) and even plugs into other online currencies like LibertyReserve and so on. And exchanges for all that on top.

That would make Safebit (let's not call it Safebit Bitcoin Wallet, but Safebit Digital Waller or just Safebit Wallet) a sigle point of command to all the various digital currencies that one has in different places.

I'm not a developer, but I'm game for testing it on Linux and Android, and also for anything web-based (it would be cool if one could access the wallet from remote).

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

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?

Add this line to /etc/xdg/lxsession/LXDE/autostart:


and create .screenrc in the home directory:


(you can drop the sudo, I don't remember why I put it there, but I must have had a reason ).

It already is. In most countries, there are anti-dumping laws preventing businesses from selling their products below producing/buying costs (with special exceptions like assets liquidation and so on). There are also minimum wages laws, taxes, etc.

If a company were to mine bitcoins, it would have to keep a proper accounting of expenses/wages/incomes and then they would not be able to sell below a specific price (not easily, anyway. They would have to invent some limited promotion, or file for bankrupcy...).

Excuse the truism, but there is no such thing as a free market. Not yet, anyway.

You can also move your business to another, friendlier, legislature. There are countries where you can create anonymous companies, the owner is determined by possession of shares (usually, physical possession of some written paper). You can take these, create a digital representation and notarize a statement like "whoever possesses this digital representation is the owner of this physical share". Digital representation might be a bitcoin wallet private key or a share in GLBSE. Or, for people who want to make sure you keep your word, you can send them the paper by mail.

Easy to understand: http://www.energyquest.ca.gov/how_it_works/air_conditioner.html

I think a escrow service for the BTC and sending the cash with tracking would solve most of the problems. And I also think there must be some trusted people in Quebec who can help establishing Als' identity and/or be used as a local escrow for the cash (you send them the cash, they give it to Als in person).

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


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.

Very nice ideas in this topic! I'd love a thin client on my phone, so I can use it without connectivity... What about this variation on the theme, which has some issues, but also the advantage of being much easier/faster to implement:

* the user has some coins on a Internet accessible system. It could be a web wallet or a self-hosted service. I would prefer to host my own, it doesn't need to be a complicated thing, just a bitcoind with a simple and secure web interface, maybe also free redirector for people behind NAT-s. Let's call this https://paymesomebtc.com/ovidiusoft/

* the user also has the thin client on his smartphone. No keys, no btc stored on it!

* the user has a shared secret with the thick system (a pin, a password...).

I see the payment as going like this:

* user walks to the cashier, scans the store QR code (bitcoin address) with his phone.

* user enters the amount and the shared secret

* phone app generates a QR code which will redirect to https://paymesomebtc.com/ovidiusoft/DATABLOCK.   DATABLOCK contains the receiving address and the amount and will be encrypted with the shared secred.

* cashier scans the code, gets redirected to a very simple page that says: "Press OK to send X amount to address Y" (or "No funds available"). He presses OK, a transaction is made.

The system is not perfect, of course. Some problems:

* system exposed on the Internet == risks of hacking. Probably not a big issue, if you're dealing with small amounts and it's dead-simple to set up even for dumb users. It should probably be able to punch a hole in the firewall, detect attacks and automagically blacklist IPs. Shouldn't require ANY configuration except the shared secret. Maybe it should be integrated in the standard client as an option "Make X amount available for mobile spending" (which will register a URL and start the local web server).

* encryption strength. The algorithm must be symetrical with simple enough keys, so it would be easy to do a plain text attack on in. A random salt will help, also OTP for the shared secret (via SMS) - when a transaction is requested, the thick client sends a sms to the client's phone. He tells the code to the cashier who can then click on the OK button and validate the transaction.

* QR code size. My phone wasn't capable of reading a version 40 code from https://en.wikipedia.org/wiki/QR_Code#Storage , so we might have a problem encoding all that data in the URL.

So, what do you think?