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.

18-21 August works for me.  New York City in August: ah, I can smell it now....

RE: changing the confusing transaction fee message:  good idea, and yes, "we" can.

How about:

This transaction requires a transaction fee of at least 0.0N because of its amount, complexity, or use of recently received funds


I don't want to use the word "recommend", because the GUI doesn't let you try to send them without a fee.

We've already got ParseMoney in util.cpp, this patch adds parseNumber/uriParseAmount.  Having more than one way to convert strings into bitcoin amounts is not a good idea, in my humble opinion.

Also, instead of having a separate executable it would be more 'wxbitcoin-like' to have one executable that acts as either client or server depending on what command-line arguments are given.  The problem with two executables is you'll have clueless users double-clicking on bitcoinuri.exe and then wondering why it doesn't do anything.

I do like the use of boost message queues to communicate.

Actually, Clearcoin only requires 3 confirmations.

And now that I've got some pressing core bitcoin stuff off my plate, I'll get back to working on a -testnet version of Clearcoin, and as soon as that is done I'll be announcing a JSON-RPC API so you can write code that interacts with clearcoin (creating escrows, getting their status, releasing coins if you're properly authorized, etc).

After putting together the 0.3.21 release candidate today, I'm thinking after 0.3.21 is out the door it might be a good time to do a major source tree re-org.   I like the idea of following the GNU directory layout standard, and it would make my job easier if source was in src/, readmes/etc were in doc/, scripts to automate the Windows build were in build/, etc.

PS: jaromil is the second person I've heard who says they'd prefer a development mailing list.  I don't care one way or another, but it would be easy to create one using SourceForge's mailing list feature.  What do others think?