jav

It does use Mt.Gox in the background for the actual exchange process. There is not enough volume (yet) to make an internal exchange practical, there would be too much risk at the moment, at least for my taste.

When I started on this project, Mt.Gox was pretty much the only choice, because of the large market share (> 80% at the time) and the necessary volume and small enough market spread. Their withdrawal delays are annoying, that's true. It does not affect me directly, since it's only Bitcoin in and Bitcoin out for me, where so far Mt.Gox had pretty much never delays. But it does distort the market price, which means you get a great rate when you fund your Bridgewalker account (because BTC is overvalued on Mt.Gox) and get a bad rate when you spend it (again, because BTC is overvalued on Mt.Gox) - so in the end it kind of zeroes out for you as a user, but it's still confusing for the user, why you have this offset.

There aren't many alternatives though. Bitstamp could be one, but I'm worried that they still might run into regulatory issues down the line. Also none of the other exchanges offer real-time streaming updates about changes to the order book, like Mt.Gox does, which is very useful to keep track of the market. Kraken could be an interesting alternative to Mt.Gox, since they seem to run a solid operation. If they add such a streaming API with real-time updates about the order book and maybe get some more volume, then I would consider switching the backend over.

Or someone else does it first - it's open source now, after all! ;-)

Or maybe you could hedge the whole thing just with some financial swap construction, but I haven't looked into that too much and it's not my area of expertise. I would be interested to find out how much something like that would cost in terms of overhead/fees and who would be a partner to provide such financial services for Bitcoin. If you have some input regarding this, feel free to contact me - my email address is on the Bridgewalker website.

No, you cannot use this app to buy bitcoins. So I'm afraid it does not solve one of the hardest challenges Bitcoin still faces, which is how to get any. You'll have to figure out the best/cheapest way depending on where you are.

If you happen, for example, to stand in front of a Bitcoin ATM, you can use that to turn fiat that you have in the form of cash into fiat that you have in your Bridgewalker account (by buying Bitcoin from the ATM and sending it to your Bridgewalker address), which you can then later spend wherever it says "Bitcoin accepted here".

A lot of exchanging back and forth for sure, but basically the idea of "Bitcoin only as tranfer mechanism" applied at every step. It's also just a technical prototype. In practice it might make sense to cut some of those exchange fees by having a more direct way to fund your account, at the cost of only being available in certain markets/countries. For this prototype I went with the easiest solution: only Bitcoin in, and Bitcoin out.

Some background: It's an Android wallet, where you maintain a euro balance (held by Bridgewalker for you). Using those funds, bitcoins will be bought at current market price whenever you want to send any. This allows you to use Bitcoin only as a payment mechanism, without being affected by the exchange rate volatility. You fund your account via Bitcoin as well, which will be exchanged for euros at current market price and credited to your account.

So: Bitcoin as transaction mechanism, Euro as store of value.

That's exactly how I operate Bridgewalker (I'm the founder). Everything is fully hedged, I'm not taking a gamble on the exchange rate.

The OP's example is diffing listings of the two directories whereas your command is asking diff to directly work on the directories themselves.

Thx! The client is BitPay ( https://github.com/warpi/BitPay ). But if you want to use the green address feature for secure instantaneous transfers, you will need a more recent version than is currently available in the Android market. This one includes support for it: https://github.com/javgh/greenaddress-pos-tools/BitPay.apk/q... .

You might be interested in this option then: BTCDeals.com is reselling the bundle for Bitcoins: https://www.btcdeals.com/humble-indie-bundle-3/ . (Although I assume they will use CC themselves to buy the bundle, so that might still be a show-stopper for you.)

This comes from this forum post: http://forum.bitcoin.org/index.php?topic=782.0

The problem was, that transactions can have "change". So by sending 1 BTC, the client did in fact send 1 BTC to one address and the remaining 8999 BTC to a a newly generated address which is automatically added to the wallet. Since the backup was before this transaction, the backup didn't include the private key to the change address and 8999 BTC were lost.

A really unfortunate incident, as the person simply didn't know this technical detail. It prompted some upgrades to the client, which now generates addresses in advance and stores them in the wallet. When new addresses are needed, the ones from this pool are used first. With a recent client this accident would not have happened. It's still important to know though, that after _sending_ Bitcoins, a wallet might potentially include new private keys that are not in an old backup (if the pool has been completely used up since the last backup).

By the way: All this happened in August 2010, so this wasn't $81,000 at the time.

My guess would be that these are payouts from a mining pool. People pool their hashing capacity to collectively find a new block worth 50 BTC and the pool then splits the reward between the participants. Some pools probably do this payout step on a fixed schedule.

On the other hand, most pools have moved to include several recipients into a single transaction, so if it is a pool, it's somewhat "outdated".