It was the bitcoin-wallet app I was using. I checked the blockchain.info website to trace the transactions the app took. I've got no idea if the blockchain android app does the same thing as bitcoin-wallet.

A quick question. Is there any way of getting to the rotated keys of the Bitcoin Android app from a backup of the old keys? Or is there any auto-backup facility for the application? Or an auto-backup after the key rotation?

From a look on blockchain.info, it looks like the Android bitcoin wallet generated a new key and transferred all of my existing bitcoins across to the new address without any user intervention. However, the application cache for the bitcoin app has been cleared, so it doesn't appear to have the private key to the new address.

Please tell me that the update didn't automatically transfer all the bitcoins over to a new address without making some form of backup first? It definitely looks like that's the case, but it's such an obviously terrible idea that I have difficulty believing anyone could have actually done it without some form of safeguard.

This sounds a lot like threshold cryptography combined with distributed key generation.

There have been a few papers written on using RSA to achieve the same result, but I'm unaware of this being done with elliptic curves. However, I'm not a cryptographer.

As a sidenote, splitting a private key in this fashion could be used to construct a simple contract without needing a trusted third party. Two individuals could generate a split private key, and then sign a pure function that would perform some prearranged task; by signing the function, it would be tied to a bitcoin account and essentially act as a fund manager. Bitcoin miners could then run this pure function (passing into it the current block data as an argument) as part of the block chain verification process.

For those writing alternative GUI wrappers that target the bitcoin daemon, has anyone had much success in figuring out when the daemon has received new transactions?

So far my solution has been to aggressively poll the daemon. There is a pull request for "push" RPC calls that would notify a HTTP server when a new transaction is received, but this has yet to be merged, and isn't really in a workable state currently.

Does anyone have any other solutions? This seems like the biggest blocker to developing a good alternative GUI (or web service, for that matter).

I'm still getting some problems getting this pull request to compile against master, even after applying the diff. Could you possibly publish your git branch?

Not even the most optimistic bitcoin enthusiasts are predicting that bitcoin will replace all world currencies!


No, you're talking about changing the whole monetary system. Everyone else considers bitcoin to be a fun experiment and currently a risky investment.

If bitcoin succeeds, it will be as an alternative payment method. You'll still be able to pay things in dollars/euros/pounds/yen/whatever, especially since governments usually expect to pay your taxes in the local currency.


That's probably a good indication it will succeed


Adopting bitcoin doesn't mean you'll be magically free of taxes.


You could just peg the value of whatever you're selling to a dollar value until the price stabilizes. You'd still pay in bitcoins, but the price would be determined by the exchange rate.

Yes... so what? If I invested $1500 in Google stock in 1999, I'd have over $1 million by 2004. How is bitcoin any different?

I don't think you quite appreciate the fact that, at the moment, investing in bitcoins is a risk. There's no guarantee that the price of bitcoins will continue to rise, just as there was no guarantee that Google would become as successful as it is today.

Early adopters get large returns because they shoulder large risks. Anyone investing in Bitcoin should be fully prepared to lose whatever money they put in.

You don't appear to know what a Ponzi scheme is, and you don't seem to have a good understanding of how Bitcoin works.

A Ponzi scheme involves lying about how much capital there is. You might invest $1 million, and then I might lie and tell you that I've managed to double your investment, when in reality I've done nothing. It's the act of deliberately misrepresenting the amount of capital available that makes it fraud.

Bitcoins cannot be a Ponzi scheme in themselves, because there's no one person who decides their worth. Bitcoins are, at worst, merely a risky investment.

Secondly, you seem to assume that everyone will buy up bitcoins and hoard them, but the value of bitcoins derives from their ability to transfer wealth without the need for an intermediate financial institution. If no-one's using bitcoins, then they have no worth beyond speculation, and you can't grow an economy from scratch to $10 billion on speculation alone.

If bitcoins ever get to $10,000 / 1 BTC, then it will be because people are regularly using them to transfer money. It's the infrastructure and social following that would give bitcoins their value; we won't ever get into a situation where billions of dollars are invested in a currency no-one uses.

Finally, you seem to be upset that early adopters stand to gain large amounts of money "for nothing" if bitcoin succeeds. You don't seem to appreciate that anyone investing in bitcoins at this point is taking a risk. If you invest $1000 in bitcoins, then there's a strong possibility you'll lose your investment if the currency fails. The principle of high-risk/high-reward is nothing unusual.

This would be incredibly useful for me, and would make a lot of work I was planning on doing around polling unnecessary.

I've been working on something like this, but it probably won't be ready for a few weeks.

With the recent closing down of Coinpal, I've been looking into the terms and conditions of alternative payment processing sites, to see whether they would allow buying bitcoins. Some other people are probably doing the same thing, so this thread is an attempt to collect everyone's investigations into one place (or at least a place to report my own investigations).

The sites I've looked at so far:

Google Checkout

Forbids "Financial products, services and stored value" and "Discounted currencies or currency exchanges"  (reference).

Amazon Payments

Forbids "Cash or cash equivalent instruments - including but not limited to money orders, travelers' checks, and generally accepted stored value products." (reference).

AlertPay

Forbids "Using or selling any form of e-cash, web cash or other matter, tangible or not, that is redeemable by a Buyer for a product or service from a third party." (reference).

NoChex

Forbids "Currency, bullion or prepaid debit/credit cards" (reference).

Moneybookers

Requires approval for "money exchange or remittance businesses, including but not limited to bureaux de change, currency exchanges and purchase of travel money" (reference). I enquired about approval for bitcoin, but they told me it would not be allowed. (And even closed down the account I used to make the request!)


So as yet I've not found a payment processing site that seems like it would allow bitcoins. I'll continue to look around, and update this thread as I do.

Hmm. You have a point...

Perhaps I should just shut up until I'm sure which side of the fence I'm on. I have a feeling I'm falling for Parkinson's Law of Triviality; I should care this much about URI syntax.

Perhaps I'm overreacting

But... Paypal's API doesn't allow for irreversible transactions, and isn't as easy to implement as just sticking a URL on a page.

Still, I guess the "Send Coins" dialog would offer confirmation in the user's native number format. Perhaps that's enough?

But at least it's misleading in the right direction. If someone makes a mistake and writes:

bitcoin:address?amount=10

Then they'll send 10 nBTC, far less than they originally thought. This is annoying, but no additional money has been lost.

But if we use the "human-readable" format, we'll run into problems with people who use a comma to indicate a decimal place. For instance, someone might write:

bitcoin:address?amount=10,00

They'd think they were giving 10, but in fact they're giving someone 1000 BTC instead.

Now we could ensure that commas are not allowed in the amount, but even if the specification explicitly forbids it, we may find that a lazy programmer just uses a standard "parseInt" format and forgets to force the locale to US.

The "human readable" syntax also has the problem of only being human readable for people who use the English number format, which in my view lessens its advantage.

And finally there's the problem of future proofing. If Bitcoins become popular, then everyone will be writing "amount=0.00123", which is no more readable than "amount=1.23e5".

After some thought, I'm going for low-level, because I don't think "high-level" is possible without the potential for major user mistakes.

The problem with a "high-level" human readable is that you'd either have to localize it (e.g. 10,00 vs 10.00), or agree on a single format.

If you're going to localize it, you need to embed the user's locale in the URI scheme, otherwise "10.000" could either mean "10" or "10000". Adding a locale in seems over complex and prone to mistakes. And it's ugly.

If we decide to agree on a single format, such as using a period to denote the decimal place, then it ceases to become "human readable", and instead becomes "readable for people who live in these countries". This is also bad, because it means that anyone from countries with a different number system might send the wrong amount by mistake.

So in my view you cannot have a human-readable "high-level" syntax, because different countries have different ideas of what that means. One of the options of this poll simply isn't possible to have unless we want people to accidentally send 10,000 bitcoins to a person who only wanted 10.000.

Therefore the only option is to use the "low-level" approach of using nano-bitcoins.

Maybe it's just me, but I didn't understand that 5X8 meant 500,000,000 until I read the specification in more detail. On the other hand, I would have instantly understood 5e8, because it's a standard convention. So at least in my case, there is a disadvantage to using this syntax, as it's less discoverable. I'd also point out that the difference in character height makes it easier to distinguish the exponent and multiplier in 5e8, whereas 5X8 is a little harder to read.

Perhaps I'm incorrect, but my guess is that the number of people who are familiar with the 5e8 convention is considerably greater than the amount of people who prefer using hexadecimal notation for monetary values. It's my opinion that using a syntax that disadvantages the majority, even if only slightly, is not worth the cost if only a very few people benefit.

If we really must have hexadecimal notation, can't we use a different exponent marker for hexadecimal values? e.g. 500e8 for decimals, and 0xf00x8 for hexadecimal.

Looks like I was beaten to the punch

This issue is of some interest to me, so I'll try putting together a branch with a minimal implementation of URI handling. I'll initially support the "bitcoin:<address>" syntax, but without the additional parameters, which can be added later. URI handling will require RPC turned on, and I'm not going to attempt OS protocol registration for now.

Out of interest, what does it mean when it says that a Bitcoin withdrawal is "verifying"? What's there to verify?

I'm pretty sure the same-origin policy applies to localhost URLs as well.

However... if you're not interested in the response, you can get a browser to perform a POST request across domains via a form. I suspect this means we'd still need a password, even for "non-sensitive" commands, otherwise a rogue site could flood your client with (for instance) a thousand new address requestions.

So back to the auto-generated password again, but this time with limited server commands by default...


That's true, and that was my main reason for proposing this. We probably should get that functionality working with an explicit RPC password first.