Note that this is not an official Google project, but was done by a Google employee in his "20%" time. I would be wary of interpreting this as Google endorsing Bitcoin, or as implying that Google would defend Bitcoin if it were subjected to legal scrutiny.
Right, that has a lot to do with why I mentioned its unofficial status in the first clause. The point is that they could have left this unaffiliated with Google altogether, but at least chose some level of association, which helps to get Bitcoin good press.
Google Code is a public open-source project hosting service. Anyone can use it, and if a Google employee is going to release code and has no particular preference, surely they would use Google's own hosting.
Oops, didn't know that. Still, Google had to decide to let it be known that this was one of their employees being paid to do it, when they could have chosen not to be associated in this way.
A company's employees publishing open-source projects is, in general, good publicity. Choosing to be not associated would consist of them telling said employee not to use their @google.com account for publishing this project (unless there's some other active publication of 'this is by a Google employee' that I don't know about), and why would they bother doing that unless they thought this particular project would be bad publicity?
(Disclosure: I have been (and will be) a Google intern, which probably affects my priors here, but I do not believe this argument is dependent on non-public information.)
It's not that Google allowed someone to potentially see the connection to Google, but that Google ensured that they (Google) would be associated with the project by informing the media. The story doesn't say "omg through investigative reporting we found that Google paid for the creation of a bitcoin client" (remember, the 20% time is not "whatever you want", but projects approved by management).
Ah, after chasing down the original announcement, I see that it does contain the phrase “Google is pleased to announce the release of BitCoinJ, ...”. Still, that is a message from the original author of the software; it is neither a press release nor written by a different party at Google, which I would expect to see if Google was actually promoting or considering using Bitcoin or BitCoinJ.
Does anyone know if similar scheme's can be set up with more time-flexibility in the quantity of currency in circulation (meaning more currency available when it's popular and less when it's not, so it has better monetary properties)?
heh, well I know you know my reason, but for others, I will link to my attempted basic explanation. Heuristically, it would be sort of odd if this particular rather arbitrary method of generating new currency (which is irreversible) provided the optimal quantity of currency. This is especially true in the limit, when the the quantity is essentially fixed.
Actually, now I think I'm going to have to change my mind: I just destroyed ~2 bitcoins by not backing up my wallet when I reinstalled Linux (for the ~10th time) to add a 4th GPU to my rig. Inflate those bitcoins back!!!
More seriously, though, if the actual number/value of bitcoins in circulation becomes a problem for being too low, someone can start another currency with the same protocol. So long as they can achieve the same network affects, the coins will have comparable value and increase the effective "crypto-money supply".
That's true. I haven't thought extensively about the economics of competing currencies, so I'm not sure what effects this would have.
Sure you have -- just think of barter as a species of competing currency. Then, put things on a continuum: from less to more money-like:
direct barter --- highly liquid goods --- limited-use alternative currencies --- mainstream money
Oh, also, drethelin needs the lecture, or least a link to the lecture, on why being deflationary will kill a currency.
That's like saying the Fed wouldn't see a need to print more US dollars if we could have half-pennies, millionths of pennies, etc.
No, for several reasons. First, part of the premise of bitcoins is to have a known rate of inflation that is eventually limited, whereas the Fed has no systemic rules against inflation in general.
Second, bitcoins are entirely digital. The ease of a transaction for 5 bitcoins is almost identical to that for .00351 bitcoins. Making fractional coins on the other hand would make the system extremely more complicated to use.
You don't NEED to make more bitcoins because as their scarcity relative to how many people want them goes up, you can simply and EASILY trade in fractional bitcoins to make up for it, which you can't do if the dollar supply was limited.
1) Bitcoins do not have a known rate of inflation. The demand to hold units of a currency and the quantity of that currency determine its value together. In the limit, where the quantity of bitcoins in circulation is near the limit, so producing more is very expensive, the demand to hold bitcoins is the primary thing influencing the value of bitcoins.
2) The reason mainstream economists think that the quantity of dollars is important is for business cycle reasons, rather than the divisibility of money. Roughly: prices are sticky, so changes in the demand for money relative to the quantity of money have real effects. more.
Oh, I don't disagree with any of that -- but if you hold jsalvatier's view (and mainstream monetary economists do), you believe it's necessary for a currency to get, not just more divisions of the money stock, but new "coins" entirely -- and therefore don't like the fact that the currency can't be inflated. From that perspective, the high divisibility of bitcoins is no reassurance.
stickiness is the only issue, and since bitcoins don't have built in expectations this isn't a problem yet. otherwise floating WRT other currencies/commodities is fine.
So I downloaded Bitcoin onto my Ubuntu box, ran the daemon, set generate to "true", and set up portforwarding on my router and verified that the connection count was greater than 0. Am I done (at least until I want to spend the fracking things)?
I used the calculator you linked with the results of "bitcoin getdifficulty" and "bitcoin gethashespersec" and it reported a 95% probability of getting a block in 16 days and 4 hours. WTF? Even before you told me your estimate of "on the order of years", I read online that it's expected to take a few months.
What's a typical number for "bitcoin gethashespersec"? Am I pouring electricity down the drain right now? I'm turning off Bitcoin generation until I figure out what I'm doing.
ETA: I don't actually know the hardware of my box, as I inherited it from a non-techy person in whose basement it would be gathering dust if I didn't want it. I do know that the box was built several years ago by a hacker-ish individual who dropped quite a bundle on it.
The difficulty factor should be correct and updated as already present on the page; if getdifficulty returns a different value, I do not know why that is. Perhaps you haven't yet downloaded all the blocks (it's a process that takes several hours upon first starting Bitcoin, and until it's completed you cannot generate)?
As for the speed, a midrange AMD GPU will give 150-200khps (meaning two-three weeks per 'win'), while most CPUs will provide at the very best a tenth of that (I have a low-range CPU and it gives ~2.5khps).
The difficulty factor is correct. I've got 700khps; top shows ~200% cpu usage (it's a dual-core machine). Holy gigaherz Batman, I've got a monster in my spare room!
I love the Bitcoin algorithm and implementation. But the total number of bitcoins to be produced - approaching 21 million - is not enough, for two reasons.
Bitcoin won't be useful until at least 100 million people use it. We'd really like 1 billion people to use it. But the maximum number of users possible is 21 million, because only 21 million people can have bitcoins, even if each has only one.
It's very discouraging to start up your bitcoin client every day for weeks, and keep it running all the time, and still have no bitcoins. This will discourage early adapters.
Bitcoin won't be useful until at least 100 million people use it. We'd really like 1 billion people to use it. But the maximum number of users possible is 21 million, because only 21 million people can have bitcoins, even if each has only one.
Bitcoins are divisible to the one hundred millionth place. So the code can support up to 2100 trillion users.
It's very discouraging to start up your bitcoin client every day for weeks, and keep it running all the time, and still have no bitcoins. This will discourage early adapters.
Early adapters are a bit more robust than that, I think. But there's a thread on this topic in the bitcoin forum, so perhaps the button will be removed in future versions. Ewallets like MyBitCoin do not have this problem to begin with, and it appears that the Google version does not have this feature either.
Bitcoins are divisible to the one hundred millionth place.
Actually, it's better than that. The software can be updated in the future to make them more divisible, even just by shifting the decimal places on their internal representations (thus, start using 'bitpennies' or something.)
Though not yet an "official" project, Google has released a Bitcoin client. As you may remember, there were concerns here about what the government/legal reaction to Bitcoin [1] will be, and the significance of certain groups lending their support to it. EFF and SIAI accept Bitcoin donations, which helps, and this action by Google is another big step.
Previous articles: SIAI accepting Bitcoin donations, Discussion on making money with Bitcoin (Clippy warning on the latter)
[1] In short, it's an anonymous P2P crypto-currency with no transaction fees, in which new units are generated by spending computer cycles computing hashes until you find one with specific properties.