Android Bitcoin Client Bounty (1740 BTC pledged)

[kiba]

Right, but nothing will happens if there is no hacker willing to take on the project.

[matsh]

I'm interested, but careful, since I don't yet know how much work it is. Right now I'm cleaning up the Java Client API, looking at the system from the outside. When that is done, within a day or so, I will have a close look at the current Bitcoin code, trying to understand what it does.

My initial ideas is:

* The Android app will not crunch blocks trying to earn Bitcoins. The processor is too slow, and the battery would drain in no time.
* The app will NOT just be a thin API to a "real" Bitcoin client somewhere else, on a machine under the control of its user (such as the existing Android Bitcoin app). It will be its own wallet, so if the phone is lost, then its money is gone too,
* Unless, of course, there's a good and safe way to backup the wallet. I have no idea how stuff like that can be done, yet.
* There should be a way of copying a Bitcoin address from say your mail app to the Bitcoin app, and then send money to that address.
* There should be a way of transferring an address from one Bitcoin app to another close-by Bitcoin app, possibly over Bluetooth, so that a transfer of Bitcoins can be done.

The donations don't make much of a difference, really, at least for me. So, I would not get out of my way pleasing everyone willing to donate a buck or two, since that would be madness. When the app gets to be useful, if ever, people who find it useful can donate to its creators.

Anyone out there willing to help out?

[kiba]

Go ahead.

As long it is easy to do transaction locally and is open source, I'll donate some bitcoins to you.

After all, this is not a donation, but a bounty, albeit public spirited.

[sandos]

How big is the wallet file?

I think a very useful feature would be to somehow back it up to some google cloud service. I know docs now allows generic file uploads and 1GB is included from the start. I know not everyone _needs_ to even have a google account when you are using an android phone, but its likely 99.9% does.

[chrisdbc]

Is it possible to modify the original client to have a "lightweight" mobile-friendly mode and support for offline transactions? Something to ponder before digging into a new bitcoin implementation.

[theymos]

Is it possible to modify the original client to have a "lightweight" mobile-friendly mode and support for offline transactions? Something to ponder before digging into a new bitcoin implementation.

A lightweight mode is already partially implemented. In this mode, you only need to download a few megabytes instead of the entire block chain.

Offline transactions would make double-spending attacks easy.

[MoonShadow]

Offline transactions would make double-spending attacks easy.

Easy?  Really?

Offline transactions would make double-spending attacks possible, it would not, taken alone, make them "easy".  I think that the lightweight client should warn the user not to accept transactions offline except from those whom he already trusts, but it should be possible.

[MoonShadow]

How big is the wallet file?

Small.  Mine is under 100Kb.  But they grow a little with every transaction that you make.

[theymos]

Easy?  Really?

Yes. If you don't have an Internet connection and the person you're receiving BTC from does, they can double-spend without even modifying the Bitcoin code (by switching out wallets and carefully controlling their Internet connection).

[Cdecker]

I'm currently working on a Java implementation of the Protocol, which in the end should end up in an Android client. I'm however not planning on releasing the Android app as open-source since I quite like the Ad supported software, but I'd be willing to open source the Protocol implementation with all it's hooks to add it to an application. Benefits would be a clear interface on which other people could build their clients, a peer reviewed Protocol core, for better quality.

I guess with that I'm not eligible to claim the Bounty?  

[MoonShadow]

Easy?  Really?

Yes. If you don't have an Internet connection and the person you're receiving BTC from does, they can double-spend without even modifying the Bitcoin code (by switching out wallets and carefully controlling their Internet connection).

You don't think that would be unlikely to occur, considering anyone receiving a transaction offline should be aware of this, and only accept transactions from those whom they know or otherwise trust?  It requires advance planning at a minimum, and a mark.  Either way, the point of an offline transaction is so that a person with a lightweight client can spend their coins without a constant connection; or sell things if the risk is managable outside of the Bitcoin system itself.

[Cdecker]

I guess that the whole discussion is going a bit awry, I'd hope that stores would put up a small access point for people to connect to when checking out. And actually there could be a lightweight setup keeping transfers low (do not request blocks you don't know yet) and just contact a single node which gets the transaction from you. That would allow people to quickly send transactions. As for the receiving side there is actually no way to tell it went through without listening for transactions and blocks.

With this setup spenders just need to transfer something in the order of 1-2KB, using 3G or even GPRS, while the receivers need an internet connection.

[MoonShadow]

I guess that the whole discussion is going a bit awry, I'd hope that stores would put up a small access point for people to connect to when checking out.

That's why I wanted the client to be NFC/Dash7 aware eventually, because I think that either/both of these technologies will play a big role in the IRL use and trade of digital currencies.  Dash7 is particularly well suited towards spreading Bitcoin transactions and blocks, but even a wifi hotspot that blocked all ports except Bitcoin's would work fine for this purpose.

[Cdecker]

Working on the Java implementation of the protocol: this protocol really has everything a Java Programmer doesn't like, lots of unsigned numbers (unsigned long requires to be mapped to BigInteger...) and little endian, which makes it particularly awful to read stuff from the wire. Anyhow today I read my first single message from the wire dump ^^
I hope in the lecture break I'll find some more time to spend on this one :-)

[kiba]

I hope in the lecture break I'll find some more time to spend on this one :-)

Will you be taking on this project? Where the source code repository for the android client?

[obinine]

It would be great to add support for transfers via the new Near Field Communications standard rather than through a centralized service like bu.mp.

[Cdecker]

I hope in the lecture break I'll find some more time to spend on this one :-)

Will you be taking on this project? Where the source code repository for the android client?

I'm pretty sure that I'll open source the protocol and wallet implementation, to improve reliability by peer review and augment trust in my code. What I'm still playing with is the thought of creating an Ad supported Android client, which would not be opensourced right away, since I know pretty good how that would turn out (people would just strip my ads and take the code and republish it without them). Since there is some serious time involved in creating the infrastructure needed to run an Android client (and the Java Protocol implementation for that matter) I think it would be nice to get something off it

[brocktice]

cdecker: I hate ads in Android apps, how about a paid client?

[FatherMcGruder]

cdecker: I hate ads in Android apps, how about a paid client?

I see some interesting possibilities here. What if the app would transfer a small fraction of a bitcoin to Cdecker, once for every day in which the user made a transfer? Or perhaps, users could send, with the app, a certain amount to Cdecker and in doing so disable the ads?

[kiba]

1740 BTC is not enough for you?