Bitcoin Wallet for Android

[cjp]

Hi,

I've downloaded the source of this app and I'm going to try it out in detail soon.

I just wanted to let you know that I have a Google Nexus S, and I'd like to help adding NFC capabilities to this Bitcoin client.

Is there something like a list of current features, and a roadmap for future features for this software? And maybe some software design diagrams for the current version and some future version?

Is there consensus on how to make transactions fast (say, less than 3 seconds), and how to reduce the memory footprint? Is it a good idea to have a full-featured client on your telephone, or is it possible to move part of the work to an (untrusted) 'cloud' service? In the second case, the app on the phone just needs to be able to check the work of the cloud service, and preferably somehow keep the private keys stored locally.

[1713856180]

1713856180

[1713856180]

1713856180

[1713856180]

1713856180

[1713856180]

1713856180

[1713856180]

1713856180

[TierNolan]

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.

What you could do is just set one of the blocks in the chain as a new "genesis" block and just store that hash for that block, its index and the headers from that block to the head of the chain.

If the genesis block header is more than 2000 blocks from the end of the chain, you could move the fake-genesis block forward until it is 1500 blocks from the head.

It is unlikely that there would ever be a fork point that is more than 1500 blocks long.

[Mike Hearn]

Actually I implemented re-orgs and a fix for the memory problem some time ago.

The next thing we need to fix for an independent Android client is initialization time for the first launch, when you have a fresh wallet. Right now you still have to download and (lightly) verify the entire chain, even though it's guaranteed that for a new user there won't be any transactions of interest there. It can be speeded up significantly by only fetching the headers for that section of chain.

Before I can implement that, we need unit tests for the Peer class though. It's under-tested right now.

[netrin]

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.

I'm all for a light weight block chain, but really, do we want our mobile devices negotiating the block chain at all? I'd be willing to pay .1 a year to subscribe (or 0.001 per inquiry) to a secured 'server', not as a bank, just as a block chain repository that I may query (and inject transactional sends). Perhaps I'd subscribe to multiple.

All I would want my mobile device doing is requesting the status/confirmations/balance of a small set of addresses (only when I open my applet, make a transaction, or explicitly ask for any new receives) and let me send. Nothing more.

[Mike Hearn]

Yes, if you're OK with relying on a third party server you might prefer the WebCoin approach.

Managing the block chain on a phone isn't such a big deal, really. Once all the relevant optimizations are done it can be quite efficient. It has the advantage that you can choose your level of privacy and independence, but the disadvantage of being more complex and heavier. With the server approach that organization always knows your balance and which transactions are yours.

[netrin]

With the server approach that organization always knows your balance and which transactions are yours.

No, I want my private keys. Sure, one of the servers could know my "sends" but not necessarily my "receives" and I could use multiple servers. And I would like to see onion wrapping like TOR or nym/cipherpunk remailing.

[MoonShadow]

With the server approach that organization always knows your balance and which transactions are yours.

No, I want my private keys. Sure, one of the servers could know my "sends" but not necessarily my "receives" and I could use multiple servers. And I would like to see onion wrapping like TOR or nym/cipherpunk remailing.

I'm pretty sure that there is an effort to develop a two part wallet for this kind of scenario, wherein the marginally trusted server has a copy of your public keys, but not your private keys, and produces the entire transaction before sending it to your device to be signed and sent back.  This could be onion wrapped by setting up the server as a hidden service, and using orbot on android to handle the proxy connection.

[netrin]

I'm pretty sure that there is an effort to develop a two part wallet for this kind of scenario, wherein the marginally trusted server has a copy of your public keys, but not your private keys, and produces the entire transaction before sending it to your device to be signed and sent back.  This could be onion wrapped by setting up the server as a hidden service, and using orbot on android to handle the proxy connection.

I don't believe it has to be so complicated and certainly not stateful. I only need a server (or a decoupling locally) to actively keep the up to date with respect to the block chain, should i wish not to store the block chain locally.

I know my addresses. If I want to know my balance I can query the server for the balance of each address (I can do this today with blockexplorer.com without it knowing anything about me). If I want to send, I just sign the transaction locally and send it to the network (either to my server or to other nodes).

I must trust the server not to lie to me about the block chain. We already trust dozens of bitcoin services and their 'notion' of the longest block chain.

Incidentally, exact what I'm talking about has already been proposed to decouple the backend from the UI. I just want to move the backend to a remote location.

[MoonShadow]

Incidentally, exact what I'm talking about has already been proposed to decouple the backend from the UI. I just want to move the backend to a remote location.

Yes, I was describing an alternative solution.  A full client could still run on android, if the blockchain was kept on a fault tolerant network shared drive of some sort, and only a local copy of the locally important blocks were held on disk.

[netrin]

Incidentally, exact what I'm talking about has already been proposed to decouple the backend from the UI. I just want to move the backend to a remote location.

Yes, I was describing an alternative solution.  A full client could still run on android, if the blockchain was kept on a fault tolerant network shared drive of some sort, and only a local copy of the locally important blocks were held on disk.

As Mike Hearn mentioned earlier, Webcoin does share the db/client decoupling goals. So, I look forward to hearing more as you tackle the merkel tree pruning challenge that Satoshi wrote about (pg4). What kind of bandwidth does basic p2p network/node negotiation require? I have the impression (from my own passive monitoring) that it's not trivial.

[willphase]

Yes, I was describing an alternative solution.  A full client could still run on android, if the blockchain was kept on a fault tolerant network shared drive of some sort, and only a local copy of the locally important blocks were held on disk.

I decided to take the approach of just storing the public address hashes, and using blockexplorer as the central repository of transactions - it's not a full wallet implementation, but my android application allows you to use your public addresses to view the balance/transactions in your wallet from your android phone.

Link to the thread here. (shameless plug)

Since it doesn't need the block chain, and instead uses blockexplorer, it can update a full wallet balance in very few HTTP requests (depending on the number of keys/transactions), using far less bandwidth/time than a full block chain download, and only needing to store public key hashes on the device.

Will

[zellfaze]

Not to be too entirely off topic...

But I just finished downloading and testing this app with a few testnet coins.  Really wonderful interface.  I'm sure the details of the implementation have some work that needs done (at least that is the impression I get here), but as far as interfaces go, I think this app does a wonderful job of making Bitcoin easy to use on the Android.

[Distribution]

I installed this on my LG Optimus, but it seems like downloading the blockchain is taking forever. Currently, it looks like it has about 16mb of it. I noticed some people were going in a short time, but mine has been downloading for the past day or two.

EDIT: I've sent .02 BTC to the address it gives me with no success. I sent .01 from my Bitcoin client and .01 from the Mt. Gox Live Trader. Neither one has shown up on my phone. The blockchain file is at 16.44 mb right now, is it supposed to be bigger?

[pdki]

Looks good! Does it store the blockchain in internal memory? Is it possible to push it to the sdcard for memory constrained devices?

[error]

Looks good! Does it store the blockchain in internal memory? Is it possible to push it to the sdcard for memory constrained devices?

The block chain should already be on the SD card.

[pdki]

It always shows downloading block chain: 0% Do you know what might be wrong?

[pdki]

The blockchain download problem is now gone after a reinstall. I was able to receive 0.001BTC. I sent 0.001BTC back to my PC wallet 16h ago (1NCTneo6yy8b1bok7F2U7RP4VgciHY2sik) but the transaction does not show up, not even unconfirmed, both client have been runnning constantly. Did anybody manage to sent money from the Android client? What is the clients policy for resending unconfirmed transactions?

[kwukduck]

Looking really good. Althoug i'm not too happy with the bottom warning "You *will* lose your bitcoins associated with this wallet".
That makes it pretty useless imho...
Why would anyone use a wallet when i know it's gonna be lost soon...?

I think it's one of the first things you should consider when developing this, make sure the basics work and are safe.

[kwukduck]

Well, that didn't take too long...
After sending a few btc the application crashed, when i start it now i get a white screen for a few seconds, then black, then the force close message.
I tried rebooting and cleaning cache, nothing helped.
Strange thing is, i have the same issue with bitcoin-android after i sent some coins. At first i thought it was caused by my barcode scanner, but i replaced it without result.

Here is the bug-report info:

https://i.imgur.com/VHc1G.jpg
https://i.imgur.com/vA7lc.jpg

[FatherMcGruder]

Besides getting stuck on the block chain sync when I first ran it, Bitcoin Wallet works well for me. I sent a bitcoin from my PC to my HTC Incredible 2 and back. It has a neat-o cash register sound that plays when you receive a payment. I didn't sit and watch, but the next morning, the two transactions had 60 and 62 confirmations. The app also has good integration with other apps, like Google Goggles for QR code stuff. Unfortunately, due to a limitation in BitcoinJ, you only get one public key to work with. Hopefully that will change soon. In the meantime, Bitcoin Wallet looks very promising and I find it very suitable for playing around with. Hopefully I'll get a chance to use it to buy lunch at that place in NYC.