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.
Topic: Bitcoin Wallet for Android - page 28. (Read 121407 times)
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.
That's probably because modern OS's can be trusted to handle any ram overusage by some form of virtual memory paging, but Android doesn't do this. So some form of substitute needs to be created. Perhaps bitcoinj can be modified to treat the blockchain as a series of records, of say 500 blocks apiece, and only keep the latest one in ram; and the rest as flat files on storage. Odds are high that it would be rare that bitcoinj would have to check back farther than a couple months for anything, so beyond 20 such files, the client could then hash the entire blockgroupfile so that it could recheck it if it needed to redownload it from a support server. Such a server could support thousands of such client, as downloads would be uncommon.
In fact, this might be a good feature for the main client. No need for a regular client to prune at all, and even keeping the headers would become optional if it had the small database of archived blockchain hashes.
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.
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.
Yes the blockchain handling in BitCoinJ needs a lot of work. It's not just storage. It's handling of chain splits (reorgs). I'm working on reorgs first before storage because the chance of encountering a reorg gets much higher when you're keeping a permanent record of the chain.
I'm surprised an Android client came out so fast, but it's great to see anyway, even if it's still early days. If people could work together on it that'd be even better.
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...I'm surprised an Android client came out so fast, but it's great to see anyway, even if it's still early days. If people could work together on it that'd be even better.
That has been called 'pruning' by others. It was intended by design for a future 'lightweight' client that could still stand alone, without the need to trust a remote server.
Yes the blockchain handling in BitCoinJ needs a lot of work. It's not just storage. It's handling of chain splits (reorgs). I'm working on reorgs first before storage because the chance of encountering a reorg gets much higher when you're keeping a permanent record of the chain.
I'm surprised an Android client came out so fast, but it's great to see anyway, even if it's still early days. If people could work together on it that'd be even better.
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... I'm surprised an Android client came out so fast, but it's great to see anyway, even if it's still early days. If people could work together on it that'd be even better.
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.
We will be releasing an android client soon, coupled with a server that does exactly this.
If the user is just spending, does he need the blockchain?
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.
Yes the blockchain handling in BitCoinJ needs a lot of work. It's not just storage. It's handling of chain splits (reorgs). I'm working on reorgs first before storage because the chance of encountering a reorg gets much higher when you're keeping a permanent record of the chain.
I'm surprised an Android client came out so fast, but it's great to see anyway, even if it's still early days. If people could work together on it that'd be even better.
I'm surprised an Android client came out so fast, but it's great to see anyway, even if it's still early days. If people could work together on it that'd be even better.
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.
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.
There was quite a bounty for this at one time
https://bitcointalksearch.org/topic/android-bitcoin-client-bounty-1740-btc-pledged-1812
Can't you store the block chain somewhere else?
https://bitcointalksearch.org/topic/android-bitcoin-client-bounty-1740-btc-pledged-1812
Can't you store the block chain somewhere else?
If the user is just spending, does he need the blockchain?
Based on bitcoinj, I've created and uploaded a first, experimental Bitcoin wallet implementation for Android:
http://market.android.com/details?id=de.schildbach.wallet
You can send money just by scanning a QR code the app displays. You need to install one of the QR code scanning apps for this to work (e.g. "Goggle").
The app currently only works for testnet. Because testnet is very slow in transaction processing, it currently takes ages to update the wallet. Unfortunately, I can't switch to prodnet, because Android apps only got 4 MB of heap memory and that's not enough for the blockchain. You can use the emulator and assign a max heap size of 32 MB though.
GPLv3'ed source available here: http://code.google.com/p/bitcoin-wallet/
Comments anyone?
Regards,
Andreas
http://market.android.com/details?id=de.schildbach.wallet
You can send money just by scanning a QR code the app displays. You need to install one of the QR code scanning apps for this to work (e.g. "Goggle").
The app currently only works for testnet. Because testnet is very slow in transaction processing, it currently takes ages to update the wallet. Unfortunately, I can't switch to prodnet, because Android apps only got 4 MB of heap memory and that's not enough for the blockchain. You can use the emulator and assign a max heap size of 32 MB though.
GPLv3'ed source available here: http://code.google.com/p/bitcoin-wallet/
Comments anyone?
Regards,
Andreas
Jump to: