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.
Topic: Bitcoin Wallet for Android - page 27. (Read 121407 times)
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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
I already checked in a BoundedOverheadBlockStore which solves the memory problem.
Downloading the chain is still pretty slow though.
Downloading the chain is still pretty slow though.
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?
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.
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.
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.
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.
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?
I think the native heap size is something different. See here:
http://developer.android.com/resources/articles/avoiding-memory-leaks.html
http://developer.android.com/resources/articles/avoiding-memory-leaks.html
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.
Jump to: