Is "Reclaiming Disk Space" already implemented? How effective will it be? Some people are concerned about the scalability of Bitcoin. The blockchain already has reached nearly 1 GB to download and store, which is not exactly in the spirit of a modern thin client, especially in regards to mobile devices.

Now when consulting the Satoshi Paper, it seems they already came up with a solution:


  7. Reclaiming Disk Space
  
  Once the latest transaction in a coin is buried under enough blocks,
  the spent transactions before it can be discarded to save disk space.
  To facilitate this without breaking the block's hash, transactions are
  hashed in a Merkle Tree [...], with only the root included in the
  block's hash. Old blocks can then be compacted by stubbing off
  branches of the tree. The interior hashes do not need to be stored.
  
  A block header with no transactions would be about 80 bytes. If we
  suppose blocks are generated every 10 minutes, 80 bytes * 6 * 24 * 365
  = 4.2MB per year. With computer systems typically selling with 2GB of RAM as of 2008, and Moore's Law predicting current growth of
  1.2GB per year, storage should not be a problem even if the block headers must be kept in memory.


Is this already implemented for the current version? "4.2 MB per year" suggests that no. Is it already on the roadmap? Have the developers met any unforeseen obstacles? Will the solution be as effective as promised?
The blockchain already has reached nearly 1 GB to download and store,

The proposal in Satoshi's paper does not reduce the download requirements, only the storage requirements (see this post to the bitcoin-dev mailing list).  Unless you are able to rely on some trusted third party, you still need to download at least all of the block headers.

If you download only the headers and not the full blocks and treat "buried X blocks deep" as proof that a transaction is valid you are open to a new class of attacks that would not affect a normal full-chain client.  The normal client treats "buried X blocks deep" as proof that a transaction will not be reversed later on -- the check to ensure that the transaction's inputs are unspent is completely separate from this.  A thin client cannot check that a transaction's inputs are unspent because it has only the block headers -- it does not have a copy of the transactions themselves.

The most worrisome of these new attacks have to come from your ISP, but in this day of wi-fi cafes that isn't such a far-fetched scenario.  So, use at your own risk.

I've been picking away at a wiki page dealing with all these issues.