|
Andreas Schildbach (OP)
|
 |
March 11, 2011, 09:25:51 PM
Last edit: July 11, 2012, 12:12:00 PM by Goonie |
|
Based on bitcoinj, I've created and uploaded a first, experimental Bitcoin wallet implementation for Android: http://market.android.com/details?id=de.schildbach.walletYou 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 |
|
|
|
|
|
FatherMcGruder
|
|
March 11, 2011, 09:31:41 PM |
|
If the user is just spending, does he need the blockchain?
|
Use my Trade Hill referral code: TH-R11519 Check out bitcoinity.org and Ripple. Shameless display of my bitcoin address: 1Hio4bqPUZnhr2SWi4WgsnVU1ph3EkusvH |
|
|
|
|
chromicant
Newbie
 Offline
Activity: 40
Merit: 0
|
|
March 11, 2011, 11:26:49 PM |
|
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.
|
|
|
|
|
Mike Hearn
Legendary
Offline
Activity: 1526
Merit: 1134
|
|
March 12, 2011, 10:13:22 AM |
|
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.
|
|
|
|
|
MoonShadow
Legendary
Offline
Activity: 1708
Merit: 1010
|
|
March 13, 2011, 05:03:26 AM |
|
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. |
"The powers of financial capitalism had another far-reaching aim, nothing less than to create a world system of financial control in private hands able to dominate the political system of each country and the economy of the world as a whole. This system was to be controlled in a feudalist fashion by the central banks of the world acting in concert, by secret agreements arrived at in frequent meetings and conferences. The apex of the systems was to be the Bank for International Settlements in Basel, Switzerland, a private bank owned and controlled by the world's central banks which were themselves private corporations. Each central bank...sought to dominate its government by its ability to control Treasury loans, to manipulate foreign exchanges, to influence the level of economic activity in the country, and to influence cooperative politicians by subsequent economic rewards in the business world."
- Carroll Quigley, CFR member, mentor to Bill Clinton, from 'Tragedy And Hope'
|
|
|
|
chaord
|
|
March 13, 2011, 07:34:26 AM |
|
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. |
|
|
|
|
|
Cdecker
|
|
March 13, 2011, 11:50:00 AM |
|
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... |
|
|
|
MoonShadow
Legendary
Offline
Activity: 1708
Merit: 1010
|
|
March 13, 2011, 01:36:36 PM |
|
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... 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. |
"The powers of financial capitalism had another far-reaching aim, nothing less than to create a world system of financial control in private hands able to dominate the political system of each country and the economy of the world as a whole. This system was to be controlled in a feudalist fashion by the central banks of the world acting in concert, by secret agreements arrived at in frequent meetings and conferences. The apex of the systems was to be the Bank for International Settlements in Basel, Switzerland, a private bank owned and controlled by the world's central banks which were themselves private corporations. Each central bank...sought to dominate its government by its ability to control Treasury loans, to manipulate foreign exchanges, to influence the level of economic activity in the country, and to influence cooperative politicians by subsequent economic rewards in the business world."
- Carroll Quigley, CFR member, mentor to Bill Clinton, from 'Tragedy And Hope'
|
|
|
Mike Hearn
Legendary
Offline
Activity: 1526
Merit: 1134
|
|
March 13, 2011, 01:45:35 PM |
|
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.
|
|
|
|
|
MoonShadow
Legendary
Offline
Activity: 1708
Merit: 1010
|
|
March 13, 2011, 02:03:21 PM |
|
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. |
"The powers of financial capitalism had another far-reaching aim, nothing less than to create a world system of financial control in private hands able to dominate the political system of each country and the economy of the world as a whole. This system was to be controlled in a feudalist fashion by the central banks of the world acting in concert, by secret agreements arrived at in frequent meetings and conferences. The apex of the systems was to be the Bank for International Settlements in Basel, Switzerland, a private bank owned and controlled by the world's central banks which were themselves private corporations. Each central bank...sought to dominate its government by its ability to control Treasury loans, to manipulate foreign exchanges, to influence the level of economic activity in the country, and to influence cooperative politicians by subsequent economic rewards in the business world."
- Carroll Quigley, CFR member, mentor to Bill Clinton, from 'Tragedy And Hope'
|
|
|
Mike Hearn
Legendary
Offline
Activity: 1526
Merit: 1134
|
|
March 13, 2011, 03:42:02 PM |
|
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.
|
|
|
|
|
sandos
Sr. Member
Offline
Activity: 440
Merit: 250
#SWGT CERTIK Audited
|
|
March 14, 2011, 08:36:54 AM |
|
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. I'm fairly sure 16MB heap has been standard for some time. I think my magic had that, and its an old phone. Also, if youre on cyanogenmod you can change the heapsize. |
|
|
|
Mike Hearn
Legendary
Offline
Activity: 1526
Merit: 1134
|
|
March 14, 2011, 11:20:34 AM |
|
|
|
|
|
|
|
em3rgentOrdr
|
|
April 17, 2011, 07:00:27 AM |
|
Based on bitcoinj, I've created and uploaded a first, experimental Bitcoin wallet implementation for Android:
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.
What's wrong with storing the block chain on the SD card (no need to be SQLite) and just swap in and out chunks to memory when needed? |
"We will not find a solution to political problems in cryptography, but we can win a major battle in the arms race and gain a new territory of freedom for several years.
Governments are good at cutting off the heads of a centrally controlled networks, but pure P2P networks are holding their own."
|
|
|
Mike Hearn
Legendary
Offline
Activity: 1526
Merit: 1134
|
|
April 17, 2011, 07:26:36 AM |
|
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.
|
|
|
|
|
Rena
Newbie
Offline
Activity: 19
Merit: 0
|
|
April 18, 2011, 04:48:57 AM |
|
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. For Linux, it would be enough to have a frontend that just connects to the machine via SSH or similar secure protocol and talks to bitcoind. I assume the Windows client has a similar "headless" interface, and there are SSH ports for Windows as well, though I've never used them so I don't know how easy they are to use. |
|
|
|
|
|
nhodges
|
|
June 21, 2011, 09:20:39 PM |
|
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?
|
|
|
|
Mike Hearn
Legendary
Offline
Activity: 1526
Merit: 1134
|
|
June 23, 2011, 08:03:38 AM |
|
I already checked in a BoundedOverheadBlockStore which solves the memory problem.
Downloading the chain is still pretty slow though.
|
|
|
|
|
BTC1472
Newbie
Offline
Activity: 3
Merit: 0
|
|
June 27, 2011, 01:34:24 PM |
|
Based on bitcoinj, I've created and uploaded a first, experimental Bitcoin wallet implementation for Android: http://market.android.com/details?id=de.schildbach.walletYou 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 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 |
|
|
|
|
|
