It's better to until the proposal to reduce bitcoind initial download size mentioned by Gavin recently has been implemented. Otherwise, downloading more than 20G bytes itself is formidable already.
If you're talking about the invertible bloom filter stuff, that's not about reducing the size of the block chain but is about reducing the amount of data that needs to propagate when a new block is found. Bloom filters are as far as I know part of the push for an SPV client. This stuff is better discussed outside of this thread though as it is not specific to Counterparty.From Gavin's blog:
Quote
After that, initial block chain download can be further optimized to ask peers directly for the UTXO set instead of reconstructing it by asking them for the entire history of the blockchain. The risk would be that they lie about what is spent and unspent, to try to get you to accept invalid transactions or create invalid blocks if you are mining. The best solution for that problem is to embed a “UTXO commitment” (a hash of all of the data in the UTXO set) into blocks, and adding a new consensus rule that any such commitment must be valid for the block to be valid.
Quote
The Future Looks Bright
So some future Bitcoin enthusiast or professional sysadmin would download and run software that did the following to get up and running quickly:
Connect to peers, just as is done today.
Download headers for the best chain from its peers (tens of megabytes; will take at most a few minutes)
Download enough full blocks to handle and reasonable blockchain re-organization (a few hundred should be plenty, which will take perhaps an hour).
Ask a peer for the UTXO set, and check it against the commitment made in the blockchain.
From this point on, it is a fully-validating node. If disk space is scarce, it can delete old blocks from disk.
So some future Bitcoin enthusiast or professional sysadmin would download and run software that did the following to get up and running quickly:
Connect to peers, just as is done today.
Download headers for the best chain from its peers (tens of megabytes; will take at most a few minutes)
Download enough full blocks to handle and reasonable blockchain re-organization (a few hundred should be plenty, which will take perhaps an hour).
Ask a peer for the UTXO set, and check it against the commitment made in the blockchain.
From this point on, it is a fully-validating node. If disk space is scarce, it can delete old blocks from disk.
Anyway, let's hope the 0.9.x be applied widely as soon as possible, so that OP_RETURN can be used to reduce UTXO set.
BTW, I've heard there's a way to spend those multi-sig transactions used in encoding XCP transactions. Is that true or not?
Yep: http://redeem.bitwatch.co/
