... only if the investments are in things that don't make us more productive.

There are really three categories, in order of desirability:

1 Investment in productive activities
2 Savings
3 Investment in non-productive activities

The broken window fallacy is confusing categories 1 and 3.

I'll be in Paris with my family next month, and would like to arrange a meeting or two with other bitcoin-people.  Who is in/near Paris, and what would be a good time/place to meet?

PS: sorry for not writing in French, it has been a very LONG time since high-school French class...

Hundreds of google accounts AND hundreds of IP addresses (the Faucet does still check IP address).  And the patience to solve hundreds of CAPTCHAs...

I'm pretty sure almost all of the bitcoins going out of the Faucet are new people trying out Bitcoin.  We're getting between 500 and 1,000 downloads of bitcoin binaries from the SourceForge site per day (stats here).

PS: Thanks again to everybody who donates to keep the Faucet running!

Limit-per-ip-range is an interesting idea.

I'd like to give the current not-yet-released solution a month or two to work before trying something else.  I see two possible directions:

+ Limit-per-{connection,ip-range}.  Trouble with this is an attacker who has multiple IPs (think botnet operator) can mount a distributed flood attack.

or/and

+ Take transaction priority into account when deciding what to drop.

I'd really like to talk to a p2p network researcher; it seems to me it might be possible to keep some statistics on what "typical" bitcoin network traffic looks like; perhaps nodes could drop neighbors if they notice network traffic from them looks way out of whack (e.g. sending a much-larger-than-typical number of addr messages or free transactions or...).

Huh.  One-to-three day transfer times doesn't seem to have hurt the dollar much: http://www.depositaccounts.com/blog/inside-look-at-ach-transfer-speeds-at.html

"Instant" payments with world currencies is an illusion created by your bank of financial institution based on how much they trust the person or institution sending the money.  There is nothing stopping bitcoin financial institutions from using the same trick, and I think as the bitcoin economy grows and companies start to trust each other instant transfer times will happen.

Stuff is valuable because it is either useful (like hammers) or we think it is pretty (like Picasso paintings); the more rare, useful, and/or desirable something is, the more valuable it tends to be.

We know how rare bitcoins are.  It remains to be seen how useful they are.  I think they're pretty useful as both a convenient way of paying for things and as a long-term store of value, but it will take time to convince most people that they're useful for those things.

https://github.com/bitcoin/bitcoin/pull/138

I think this is ready:
I found one edge case during testing, and after discussion on #bitcoin-dev changed the information reported.  The edge case was reporting the coinbase transactions from orphaned blocks.  Here's the scenario:

+ As soon as you generate a block, the coinbase transaction goes into your wallet as a 1-confirmation transaction.  Before this patch, that transaction was not listed in the listtransactions output.  With this patch, it is (as "category" : "immature", "confirmations" : 1).

+ If that block is orphaned, the coinbase transaction is no longer valid.  With this patch, it will be reported at "category" : "orphan", "confirmations" : 0

+ When a coinbase transaction has 120 confirmations, it will be reported as "category" : "generate" (as before).

I added a comment to the PULL request-- I ran into an issue when sanity testing this (a testnet wallet that reports an impossibly high balance after conversion).

Yes, and right now it will sit in your wallet at 0 confirmations and get rebroadcast once in a blue moon (ok, not that long, but I'm too lazy right now to dig out the rules for when transactions are rebroadcast) until it DOES make it into a block.

And you'll have to hack your copy of bitcoin to be able to send a less-than-.01 transaction without a fee; the RPC send* methods automatically add the fee, and the GUI will tell you a fee is necessary (and won't let you send unless you agree to it).

Be nice, y'all.  Todd emailed me directly and I steered him here because I don't have time to talk about economic theory with everybody who emails me these days.

Todd:  if you were designing a new currency, what would it look like?  Are you imagining a LETS-like system of credit?

Bitcoin is designed to be like a scarce natural resource, which is pretty conservative, really-- scarce natural resources have a long history of being used as currency.  I don't know enough about the alternatives to know whether or not they could work as an Internet currency-- the LETS systems I've heard about all rely on local interactions and trust to keep people from cheating.

PS: I'm going to move this thread to the Economics forum.

Better would be a new feature that tells the mining bitcoin "please credit generated bitcoins to THIS address (instead of a new one)."

If you are just mining, you don't need the private key at all, the bitcoin address (or public key) is enough to create the coin generation transaction.

Do these types of 'make money without doing anything productive' schemes bother anybody else, or am I just a financial prude who doesn't recognize harmless fun when I see it?

I feel like we might soon need a Frequently Seen Schemes to go along with our FAQ, just to let people know that using a different currency doesn't suspend the laws of economics.

That's not the ONLY question.  A question I've been thinking a lot about is what are an employer's potential liabilities if they are caught paying employees in bitcoins "under the table."

I honestly don't know the answer if the employer is in Finland and the employee is in Ecuador, and suspect the answer might depend on whether or not the person doing the work is considered an independent contractor or an employee.

I just bought two Boston Red Sox tickets from my friend Baer using bitcoins.  They really do work nicely for grassroots, person-to-person transactions, and the beautiful thing is you don't need a lot of people accepting them in one place to get started.

Cloning your wallet to do anything besides backing it up is a bad idea.

It might work perfectly for a while... but you are very likely to get weird behavior from bitcoin sooner or later, because doing that is not tested or supported.

Where 'weird behavior' is one clone of the wallet shows one balance, the other clone shows another, and you might end up with bitcoins that you can spend from one wallet but not the other (or, worst case, end up with bitcoins that neither wallet is able to spend).

If you REALLY REALLY REALLY want to do this... then get the latest code from git, pull sipa's 'Spent per txout' patch, and then spend a bunch of time testing to find out what happens when your cloned wallets eventually start using different keys from the keypool.

From wikipedia:

So, who are the merchants in the bitcoin rush?

Adds support for the Tonal numbering system to bitcoin.  Branch is at  https://github.com/gavinandresen/bitcoin-git/tree/tonal

Pull request is:
  https://github.com/bitcoin/bitcoin/pull/8

(Note: you will need Tonal Git and a Tonal-capable browser to follow that link).

Am I the only person here who looks at our documentation for how to use bitcoin from PHP and thinks "people are going to run away screaming" ?  See:  https://en.bitcoin.it/wiki/API_reference_(JSON-RPC)

I strongly believe you are making the common cases (simple shopping carts or "hold a bitcoin balance for a customer and let them spend it") much, much more complicated than necessary.

What do other people think?  I'd especially like to hear from people who have prior experience using PHP to implement shopping carts and other simple applications that deal with money.  Did you use BCMATH/GMP?

HOW MANY TIMES DO I HAVE TO YELL THIS???

Of COURSE you shouldn't use floats internally (unless you are doing something trivial like adding up items in a shopping cart).

We are talking about the JSON-RPC api.  Which is an api for communicating between bitcoin and other applications, in which all values are turned into strings.

So:  what are the best practices in the banking world for representing monetary values in strings?  As far as I can tell, the answer is "write them out as decimal values and convert them to Decimal() or integer as you read in or write out."

Which is exactly what Bitcoin does, and which is what I think we should recommend to people.

An IEEE double-precision floating point number has 53 bits of precision, which IS sufficiently accurate to store a bitcoin balance.

Every single possible bitcoin value can be converted to and from an IEEE 64-bit float with no loss of precision.

I agree that if you're going to be performing lots of calculations on bitcoin values you need a Decimal type (and ClearCoin stores and uses python's decimal.Decimal(precision=8) for all bitcoin values)-- if you don't, floating point errors can accumulate and eventually cause you to gain or lose .00000001 of a coin.

But really the main problem with storing monetary values as any floating point type is you're likely to be embarrassed by mistakes like error's cash register receipt if you truncate values instead of rounding before printing.