Bitcoin Forum
December 08, 2016, 02:38:03 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 »
  Print  
Author Topic: Bitcoin Wallet for Android  (Read 115024 times)
Andreas Schildbach
Moderator
Hero Member
*
Offline Offline

Activity: 563



View Profile WWW
March 11, 2011, 09:25:51 PM
 #1

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

Bitcoin Wallet for Android: Your own Bitcoins, in your own pocket!
https://play.google.com/store/apps/details?id=de.schildbach.wallet
1481164683
Hero Member
*
Offline Offline

Posts: 1481164683

View Profile Personal Message (Offline)

Ignore
1481164683
Reply with quote  #2

1481164683
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481164683
Hero Member
*
Offline Offline

Posts: 1481164683

View Profile Personal Message (Offline)

Ignore
1481164683
Reply with quote  #2

1481164683
Report to moderator
1481164683
Hero Member
*
Offline Offline

Posts: 1481164683

View Profile Personal Message (Offline)

Ignore
1481164683
Reply with quote  #2

1481164683
Report to moderator
1481164683
Hero Member
*
Offline Offline

Posts: 1481164683

View Profile Personal Message (Offline)

Ignore
1481164683
Reply with quote  #2

1481164683
Report to moderator
FatherMcGruder
Sr. Member
****
Offline Offline

Activity: 322



View Profile WWW
March 11, 2011, 09:31:41 PM
 #2

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
Hal
VIP
Sr. Member
*
Offline Offline

Activity: 314



View Profile
March 11, 2011, 10:56:23 PM
 #3

There was quite a bounty for this at one time

http://bitcointalk.org/index.php?topic=1812.0

Can't you store the block chain somewhere else?

Hal Finney
chromicant
Jr. Member
*
Offline Offline

Activity: 40


View Profile
March 11, 2011, 11:26:49 PM
 #4

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 Offline

Activity: 1526


View Profile
March 12, 2011, 10:13:22 AM
 #5

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 Offline

Activity: 1666



View Profile
March 13, 2011, 05:03:26 AM
 #6

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
Full Member
***
Offline Offline

Activity: 218


View Profile
March 13, 2011, 07:34:26 AM
 #7

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
Hero Member
*****
Offline Offline

Activity: 487



View Profile WWW
March 13, 2011, 11:50:00 AM
 #8

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...

Want to see what developers are chatting about? http://bitcoinstats.com/irc/bitcoin-dev/logs/
Bitcoin-OTC Rating
MoonShadow
Legendary
*
Offline Offline

Activity: 1666



View Profile
March 13, 2011, 01:36:36 PM
 #9

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 Offline

Activity: 1526


View Profile
March 13, 2011, 01:45:35 PM
 #10

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 Offline

Activity: 1666



View Profile
March 13, 2011, 02:03:21 PM
 #11

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 Offline

Activity: 1526


View Profile
March 13, 2011, 03:42:02 PM
 #12

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
Member
**
Offline Offline

Activity: 106


View Profile
March 14, 2011, 08:36:54 AM
 #13

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.
Andreas Schildbach
Moderator
Hero Member
*
Offline Offline

Activity: 563



View Profile WWW
March 14, 2011, 09:55:50 AM
 #14

My Nexus One, running on official Android 2.3.3, has a heap size of 4008 kB. This is determined with Debug.getNativeHeapSize().

Bitcoin Wallet for Android: Your own Bitcoins, in your own pocket!
https://play.google.com/store/apps/details?id=de.schildbach.wallet
Mike Hearn
Legendary
*
Offline Offline

Activity: 1526


View Profile
March 14, 2011, 11:20:34 AM
 #15

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

http://developer.android.com/resources/articles/avoiding-memory-leaks.html
em3rgentOrdr
Sr. Member
****
Offline Offline

Activity: 434


youtube.com/ericfontainejazz now accepts bitcoin


View Profile WWW
April 17, 2011, 07:00:27 AM
 #16

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 Offline

Activity: 1526


View Profile
April 17, 2011, 07:26:36 AM
 #17

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 Offline

Activity: 19



View Profile WWW
April 18, 2011, 04:48:57 AM
 #18

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.

15R7dpxfWuDrQY9CtUzMsg6A7sKMdWbTd3
nhodges
Sr. Member
****
Offline Offline

Activity: 308


View Profile
June 21, 2011, 09:20:39 PM
 #19

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 Offline

Activity: 1526


View Profile
June 23, 2011, 08:03:38 AM
 #20

I already checked in a BoundedOverheadBlockStore which solves the memory problem.

Downloading the chain is still pretty slow though.
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!