So: the danger isn't revealing private keys (I mis-remembered),  the danger is a naive developer will see the signmessage RPC command, not realize that signing arbitrary data can be dangerous, and put up a web page that lets somebody enter arbitrary data to be signed with one of the developer's public keys.

This might just be a documentation issue, although if signmessage was changed to sign a hash of the passed-in message instead of the message itself then it would be completely safe.

To steal your bitcoins by breaking crypto (as opposed to getting your private key), somebody would have to:

1. Break RIPEMD160.  Because your bitcoin address is a RIPEMD160 hash...  AND
2. Break SHA256.  Because your bitcoin address is a RIPEMD160 hash of the SHA256 hash... AND
3. Break the ECDSA elliptic curve encryption signature algorithm, to figure out the private key that corresponds to the public key that they got from breaking (1) and (2).

That's assuming that you don't re-use bitcoin receiving addresses (your public key is revealed the first time you spend coins that were sent to that address).  If you do re-use the same receiving address, then they just need (3).

I don't spend any time worrying about whether or not the NSA (or anybody else) can break ECDSA.

RE: other weird variable type requirments:
sendmany's second argument is a JSON Object, with string keys and number (float) values.  I think the equivalent in PHP is a PHP Array (indexed by string).

Several routines take boolean arguments.
All the rest are strings or numbers.

I've deployed a -testnet version of ClearCoin, at:
  https://testnet.clearcoin.appspot.com/

It is fully functional, so feel free to creates some escrow transactions and get some testnet bitcoins from the the testnet faucet (which I will eventually move to testnet.freebitcoins.appspost.com).

For anybody else developing on App Engine, here's what I did to make it work:

In my main.py:
CURRENT_VERSION_ID is the version of your app that's running, and is set by App Engine.
set_namespace makes all subsequent datastore and memcache operations read/write from a different database.  So almost all of the code for ClearCoin doesn't care whether it is handling testnet coins, it just works.

The only other change needed was a check for 'test' in os.environ['CURRENT_VERSION_ID'] when deciding which bitcoind server to use.  I run the -testnet bitcoind for ClearCoin on a different machine than the production bitcoind, so experiments on the test net won't affect the production ClearCoin at all.

If you're not running on App Engine, you should think about building in the equivalent of CURRENT_VERSION_ID and 'set_namespace' so deploying test and production versions of your application is easy.

Best thing I've bought:  Boston Red Sox tickets (from a friend who has season tickets).
Second best: my alpaca socks.
And I've bought three or four lunches with bitcoins so far (also from friends-- they pay, then I repay them in BTC).

I really wish I had a use for Golden Mean Calipers, they look nifty.

You are forgetting that there are (at least) three players in the bitcoin economy:  miners, users... and merchants.

If transaction fees are driven to zero so miners start dropping out, then merchants have an incentive to step in and start mining themselves so their transactions get processed in a timely manner.  Otherwise they don't get paid.

The testnet Faucet has 7,000 testnet coins in it, you can get 50 at a time at:
 https://freebitcoins.appspot.com/TEST/

If I were Satoshi...  I would have built a modest amount of inflation in to bitcoin.  "Modest inflation is what most people are comfortable and familiar with," I would have reasoned to myself, "so that's the right thing to do."

However... I'm not so sure that would have worked.  It is very nice to be able to say "bitcoins are valuable because they are rare, and they are rare because they are designed that way-- there will never be more than 21-million of them."  That is easy to understand, and gives bitcoins a clear advantage over existing currencies.

That really aught to be openssl .. && rm -f ...
... or maybe something more complicated to make sure the wallet encryption/writing completed OK before removing the wallet.dat.  Like checking to make sure wallet.dat.aes256's filesize doesn't get smaller through the decrypt...use...re-encrypt cycle.

I dunno, you tell me-- the idea is anybody can use gitian-builder to create trusted releases, right?  Working with BlueMatt to make the nightlies use it seems like the right place to start.

Mucking with the Linux build process isn't high on my own personal TODO list, I have my hands busy wrestling with the Windows build (can gitian build windows mingw bitcoin binaries?) and setup.nsi...

What's the extra CPU cost for recovering the public key?  Current bottleneck for bitcoin transaction processing is the CPU cost of ECDSA signature verification, not disk space or bandwidth, so saving bytes at the expense of more CPU is not the right thing to do.

I thought I'd explain a little more why I think most conservatives might have a negative reaction to bitcoin, why libertarians love it, and why I think liberals might be convinced to love it.

I'm starting from Jonathan Haidt's Moral Foundation Theory, which says that we all have five basic universal moral foundations:

• Harm/care
• Fairness/reciprocity
• Ingroup/loyalty
• Authority/respect
• Purity/sanctity

Different cultures and people of different political or religious viewpoints feel more strongly about some of these than others.  Conservatives score pretty highly on all five; liberals score very high on the first two.  Libertarians... are complicated.  More like conservatives when it comes to money, more like liberals when it comes to social issues.

So: how do I think people will react to bitcoin for each of the five moral foundations?

Harm/care:  if Bitcoin gets a reputation for 'that online currency that the criminals and drug dealers use' then that's bad.

Fairness/reciprocity:  if Bitcoin is seen as 'that online currency that made a bunch of early adopter geeks obscenely wealthy' then that's bad.

Ingroup/loyalty:  I think conservatives might feel like bitcoin is an affront to Their National Currency (whatever currency that happens to be).

Authority/respect:  Conservatives probably won't like a rag-tag band of open source rebels trying to overthrow The Authorities.  I'm not happy about the tone of the recent Forbes article, for example.

Purity/sanctity:  Assuming we can get past the Harm/care problems, I actually think bitcoin could be positioned as the purest form of online money.

Moral Foundations Theory strikes me as probably right (and it's backed by pretty solid research, it is not just philosophical musings).  I've been thinking about how to "frame" bitcoin to appeal to people on a moral/emotional level.  Random thoughts:

Fairness/reciprocity: if you're an early adopter geek, start circulating your coins-- send them to MyBitcoin or MtGox and then back to yourself if you want to keep them, but make it hard to tell if there ARE any early adopter geeks holding lots of coins.  And if you're talking about bitcoin, compare it to the fairness of the current system, where bankers are allowed to create (and profit from) creation of money.

What do y'all think?

Governments can print money, so if they want bitcoins it would be much more efficient for them to just buy them (with newly printed money) than try to mine them.

Going on a bit of a tangent:

Once common criticism of bitcoin is that there is nobody like the Federal Reserve to "smooth out the bumps in the economy by manipulating the money supply."  Set aside for a minute whether or not the Fed actually does a good job of that or whether or not the Fed actually has the ability to do that.

One response is that there is absolutely nothing stopping the Federal Reserve, or anybody else, from stepping in and "smoothing out the bumps in the bitcoin economy."  The Fed could buy bitcoins when it thought the value was too low, and sell them when it thought the value was too high. It'd have to plan ahead and keep a big stock on hand so it had some to sell, of course.

That might lead to a productive discussion on why that would or wouldn't work, and if or how it is different from what the Fed (or the World Bank) does now.

All that Icelandic geothermal power could make them a mining hot spot, too.

I am mostly a pacifist.

My turn to be the newbie:  Is there a high-level discussion of the economics of NameCoin or DNS in general somewhere?  What is the scare resource that needs to have a price attached?

My half-baked thoughts:

Seems like domain names are not the scarce resource; CPU power available to process transactions is the scarce resource.  So it seems to me simply not allowing any free transactions, allowing an arbitrary number of "new domain" and "domain transfer" transactions with arbitrary fees attached, and allowing the mining nodes to decide which transactions to accept into their blocks and which to drop will create the "right" number of domain names at the "right" price.

Any individual, well-known domain name is a scarce resource.  "google.namecoin" is worth more than "xblkje4klj21.namecoin"... but if I want to get the google.namecoin domain name from google (or a domain squatter), and google or the domain squatter is willing to keep paying the (minimal) NameCoin renewal transaction fee, then I can just offer them cash or bitcoins (or NameCoins) to transfer the domain to me.

Today, it costs the entire network something like $0.001 to process each transaction.

The limiting factor is checking to see if the transaction is valid or not (the CPU cost of ECDSA signature verification).  When the transaction volume gets high enough miners will have to start prioritizing which transactions they check, and they will use transaction fees as a quick initial check to see if they should invest CPU cycles to include transactions in a block.  Yes, miners want to include as many transactions with fees as possible in their blocks, but it won't be economical for any miner or mining pool operator to include an infinite number of them.

And speaking of mining pools... they are a lot more efficient than individual miners because they allow transactions to be verified once instead of requiring that all of the miners in the pool do that work.  Very small miners will be driven to join a mining pool, and the big mining pools will be competing to have the lowest fees and highest payouts (and so will be optimizing their ECDSA verification code and will figure out which transactions are profitable and which aren't).

So:  I don't think bitcoin will have very few miners.  I think it will have lots of miners connected to a smaller number of mining pools, and the whole system will optimize itself to be wonderfully efficient.

Very good idea.  Anybody want to implement it?  I've got a Python tool that walks the block chain gathering transaction statistics:
  https://github.com/gavinandresen/bitcointools/blob/master/statistics.py

Teaching it to compute 'bitcoindays destroyed' shouldn't be terribly hard.  I think.

This morning I taught it to add just the smallest or just the largest output in each TxOut and report the range to get an estimate of 'true' transaction value being exchanged without counting change TxOuts or mining pool payouts.

So, to be conservative, assume that the biggest-value TxOut for every transaction is change and the smallest is the actual bitcoins being transferred.  Taking the smallest TxOut of all the transactions last month, an average of about 35,000 BTC were sent per day.

This month the average is about 55,000 BTC per day.   Add in the MtGox trading volume to get a reasonable lower estimate of something like 70-80,000 BTC changing hands every day.

+1

Y'all have heard of the KISS principle, right?

Because there is a real cost to the network for every transaction, and the code hasn't been fully optimized yet.

Allowing users and miners to set fee policy without recompiling will happen, but I think there are higher priority issues to tackle first.