Oh God, not this post again.  Can you people please try to understand that saying something doesn't make it true?

Just integrate Bitcoins (the solution to everything).  Topics older than 30 days become locked.  A bot puts a final locking post on the thread w/ a revive Bitcoin address.  The cost to revive is (days since lost post - 30)^2  / 100 BTC. 

+1  very much what i was going to say. this is epic for BTC!

the point is it will allow for the decentralization of exchanging BTC to dollars or dollars to BTC

Bandwagon. Arrgggh!

:+1 !!!!!

The loyalty in this thread concerns me.

In essence, I'm scared of one person having influence over Bitcoin's protocol. I trust nobody and neither should you. Bitcoin is a powerful technology and if anything will kill it, corruption will.

If you've got a great business model and funding for a much better bitcoin client, more power to you!

If you're planning on defacing one of the web servers that I haven't been keeping up-to-date (because I'm busy doing Bitcoin-related things) or hacking my gmail account to prove that I'm not The World's Best Security Expert... then I'll save you the trouble:

I am not the World's Best Security Expert.
I am not the World's Best Programmer.
I am not a cryptographer.
I am not an expert on finance or banking or monetary systems.
I am not an expert on leading open source projects.

And I hope someday I get replaced as the technical lead for this project. I'm sure there are lots of people better qualified than me, I'm just doing the best I can to try to help make Bitcoin a success.

As a significant shareholder, I disagree. If Bitcoin was a company and had a board, I would of asked for Gavin's resignation long ago.

Gavin gives me the impression of a tinkerer, an experimenter, a hobbyist. When it comes to Bitcoin being made as a product for human beings, I find him completely lacking. He's not a business person and he admits that shamelessly. What Bitcoin needs more than ever is the human element.

I am confident people will inevitably agree and act upon this -- far beyond simple clients.

I think that's a problem that would fix itself if clients had this feature and people started using it.  If you're a miner and are actively seeking fee bearing transactions, you really shouldn't be rejecting fee-less transactions if they are inputs to fee bearing transactions that meet your fee requirements.  This situation can occur today, though it's probably quite rare given the behavior of the main client.

Regarding my suggestion of a fee that has a high likelihood of making it into the next block, I was thinking of some sort of statistical analysis that could determine a fee that is in the Nth percentile with respect to the time between the transaction appearing on the network and it being included in a block.  You could configure the percentile that you wanted your client to suggest (with perhaps the 95th percentile being the default or so).  This means that if you applied the suggested fee, you would have a transaction that should be in the 95th percentile of all transactions in terms of the time it takes for that transaction to get included in a block.

In most cases, you either want the transaction to get into a block as fast as possible or you don't care at all how long it takes.  So choosing between a 95th percentile fee or no fee at all is likely the only choice most people need.

I'm not aware of any version that didn't force fees...

What I would like to see is not only the ability to create transactions without a fee, but also the following:

a) the client to offer a suggestion of a fee that would have a high probability of getting into the next block or two based on some kind of analysis of recent blocks

b) the ability to add a transaction fee to a transaction that you've received and that hasn't yet made it into a block…the client would do this by creating a new transaction with that transaction as an input and sending coins back to yourself (less the desired tx fee)…the client would immediately broadcast this new transaction

There has always been this nagging discomfort with me with regards to P2SH...  and now I finally know what it is...  Backups.  I have put a lot of work into deterministic wallets and paper backups in Armory,  to try to solve one of the most frustrating modes of failure: HDD failure or overwrite combined with either no backup or a stale backup.  

The issue that I am finding with P2SH (which would happen with any similar multi signature scheme that hide addresses),  is that the user is back to requiring a persistent backup solution, because he cannot even identify, much less spend his multi-sig-encumbered coins if he doesn't have the P2SH script.

On the upside,  the P2SH scripts are not nearly as sensitive as private keys.   But they are just as important! If you lose them,  you (probably)  lose the money behind it...

This presents a serious implementation issue:  how do I modify Armory to accommodate backing up the scripts.   I had originally made space for them in the wallet file but now I am realizing that will not enable easy backups (not everyone wants to backup their wallets remotely,  encrypted or not).  So I'm thinking that I should instead create a separate P2SH scripts file,  separate from the wallet,  allowing the user to place it in,  say,  the Dropbox folder.   If the user doesn't want the data stored unencrypted (for privacy reasons),  asymmetric encryption can be used to encrypt each script before appending it to the file.   It would seem that there is no grace time for backups like the Satoshi wallet has (generating 100 address pool)   because you don't know what scripts you're going to receive until you actually get/create them.   They need to be backed up immediately.  

On the other hand,  if these multi-sig scripts require multiple parties,  they are like to have the scripts too,  and you might be able to request them. But this could be a royal pain in the ass if you do business with a lot of different people...

Any recommendations are welcome.  Obviously,  tying the user to dropbox is sub-optimal, but I'm not seeing any other solution that a regular user could put up with that would provide the appropriate level of backups.   Using standard OP_CHECKMULTISIG would solve this,  but there are other reasons it is not being adopted (though I always believed it should be an option even if it isn't the recommended,  but this is a different discussion...)