I wasn't able to find the link posted by CasualSam.  Could you repost the link please?

Could you unlock my account 'jeremysalwen'

many doge thanks.

Hey Bitfreak,

I very much like your mini-blockchain idea.  I'd like to implement it, but as it stands, I feel like it would benefit from further specification before I start writing the code.  If you could give me an account on the wiki so I could start outlining the data structures, protocols, and algorithms my implementation will use, that would be great.  I was planning on implementing the idea before I found out about the prize, but I'm really happy to have someone to bounce ideas off of.

Here's what I've fleshed out so far:

Account DB structure:  Merkle tree
While the "XOR of all accounts" structure is nice from the perspective of a thin client, as you pointed out, it makes things rather difficult to bootstrap, and corrupt or malicious information sent from your peers hard to detect (how do you know which block is bad?).

Merkle trees solve this distribution problem, and you can run a thin client almost as efficiently.  If you only want to track a single account, you only have to fetch a single "path" down the merkle tree.  If you're running a full client, the XOR system isn't better either, because if you want to actually verify that the transactions match up to the account balances,  you need to store all the account balances anyway, and need to have a fast way of indexing the accounts.  This is going to have basically the same overhead as a Merkle tree.  Rather than trying to retrofit the XOR system with additional data structures, we can just use the merkle tree which serves as a p2p distribution/thin client support/fast read-write data structure all in one. 

Mini-blockchain Security:

I was thinking about the issue of an attacker rewriting the entire chain once the mini-blockchain is forgotten might be remedied by attaching signatures to all the accounts, or some other scheme, but after I thought about it a bit, it's essentially a problem in communication complexity which is provably impossible.  /Someone/ needs to keep track of the old blocks in order for chain-rewriting to be detected.  But it's only necessary for a single person to have a copy of the old blocks to prove that a chain rewrite is invalid.  The way I think about it, the actual length of the mini-blockchain that is stored can vary as much as the user wants between clients, and a few clients can store the whole blockchain.  Of course, the issue of who is guarding against mini-blockchain rewrites, how that information is communicated and accepted by the network, and how to make sure there are incentives to catch this sort of attack still needs to be figured out (an idea which just occurred to me is that catching a block rewrite could be worth some percentage of the fake chain's proof of work, but we need to be careful that it can't be gamed in either direction.).

Compressing the mini-blockchain:

Assuming that you have validated your transaction history and account trees, you don't actually need to store the entire mini-blockchain on disk, just the initial account tree, the current tree, and then the transactions, which can be used to recreate any intermediate tree.

-Jeremy

Hello all,

I'm a developer who registered primarily to post about this thread: index.php?topic=371601.0 although I'll likely stick around to comment on other threads.  I like the idea of a finite blockchain, and I think it would help lower barriers to adoption.  I also am interested in CPU-efficient hash functions.  If we could create hash functions for which off-the-shelf CPUs are the most cost effective miners, then I think the hash chain would be more secure.

Both of these goals aren't achieved by current altcoins (scrypt doesn't really do its intended job), but hopefully will be soon.