If the user is just spending, does he need the blockchain?

I am still putzing around with my Android client work....but as for [mike]'s Java code, I'd think storing the block headers in an SQLite database may be the way to go, but you'd need to edit that code to do so as I saw it.

But great job on the first pass. I should clean up and release what I have with respect to using C2DM to notify a bitcoin client that blocks are waiting. Also, now that we have a growing DNS spec...I don't feel bad if I am not part of the network as a whole.

No, not really.  But any independent client will need to have access to a full blockchain at some point in order to even know that it has any bitcoins to spend.

What about a remote blockchain?  A symlink over the Internet, or a blockchain 'server' that can scan the blockchain for these Android clients whenever the Internet is available.

I was looking into the chain storage and as far as I see it you'd just need a few recent blocks to track transactions you're interested in. I'd keep them in a stubbed "quarantine" chain as long as I'm not satisfied that they were confirmed, and then stub them off at ~10 confirmations, and just store the potential inputs for transactions I'm going to send. It's just that right now I'm swamped with 2 theses, and I wont be able to actually implement it for some time...

You need enough headers to be able to efficiently handle block chain splits/re-organizations. I don't think you need to store all headers, as they can be fetched on demand from a full node peer. As blocks get buried the chances of the chain forking from that point get lower and lower.

If you don't mind downloading all the headers again when the chain splits and you end up on the losing side, you only need to store a single header along with a few bits of extra data, like how much cumulative work was underneath that block.

The right tradeoff is somewhere in the middle. You probably want to store a days worth of headers at least. After a day has passed the chances of the chain splitting and undoing a days worth of blocks is very low - only if a serious bug is found like back in September could that really happen.

The problem Goonie has is that both BitCoinJ and the official BitCoin implementation store block headers in RAM. That's ~5mb per year of operation when stored without overheads. But in practice all implementations do have overheads so it's more than that.

BitCoinJ needs to operate in very low RAM environments like phones, so the way it'll handle chain storage has to be different to the official client.

I don't think it needs new protocol extensions.

Even if you store all headers on disk you don't need them all in RAM. You can just mmap a view of those blocks and deserialize the ones you need or hash the raw byte range. You have to be careful to handle forks correctly though.

Android has some unique constraints, like hard limits on memory usage and the fact that IOP latency is highly variable. Same is true for iPhone of course. Some things the official client does would work poorly on a phone.

I think the native heap size is something different. See here:

http://developer.android.com/resources/articles/avoiding-memory-leaks.html

When he wrote that there was no support for persisting the block chain to disk.

There is now. However it is still loaded into RAM at startup. The reason is some BitCoin operations need to map a hash back to a header, along with some state that is not in the header itself (like cumulative work). So for simplicity the current code loads all headers into a map at startup and calculates the non-persisted data as it goes. It solves the startup time problem for people working on desktops.

To solve the problem completely for mobile, a BlockStore implementation that has constant RAM overheads is needed. I have some ideas for how to build such a thing but haven't done so yet.

Is there any way to write and concatenate a file on the SD card that contains the blockchain, then verify this bit by bit, to circumvent the 4MB mapped memory limit?

Hi Goonie,

I'd be interested in contributing to your project. Do you have a backlog of tasks that need doing? What is preventing you from using the app on prodnet? Is it still the block chain memory issue?

Regards

BTC1472