Bitcoin Forum

I am pledging 20 BTC for the development of a viable bitcoin client for android for the purpose of facilitating local transactions.

Added condition: I want it to be open source. GPL or BSD like licenses.

Pledges:

Kiba: 20 BTC.
brocktrice: 800 BTC.
creighto: 50 BTC.
brucewagner: 800 BTC.
slush: 50 BTC.
Vandroiy: 20 BTC

Pledges outside the forum:

akivasilver@d00m.com - 20 BTC

Total: 1760 BTC so far.

I'll pledge 400 make that 800, and would even pay if it's just a nice Android/iPhone web app BUT it must be runnable on one's own server, not linked to its own service.

I.e. I run bitcoin + this service on my own server, it runs a secure web app that lets me view my balance, get new addresses, and send to addresses, per Kiba's local transaction specifications. Bonus of another 200 if it'll show/scan QR codes for exchanging addresses.

Added.

By local transactions, I assume a minimum capability of a local wallet.dat, the ability to use bu.mp (or similar) to transfer addresses, and the ability to create transactions in the absence of working Internet access.

I pledge 50 under these conditions.

Added.

Brocktice upped the ante to 800 BTC, plus a 200 btc potential bonus.

I was thinking on working on an Android client (not just an interface to the desktop client, but a standalone client), so I'm intrigued by the Bounty.

Sadly I'll only have time after christmas, so I'll contribute if someone's faster than me.

One more thing: conditions have to be a bit better specified. I'd go for standalone app (no desktop client needed), manages it's own wallet, barcode scanner that recognizes the URI format (http://bitcointalk.org/index.php?topic=55.msg21964#msg21964), anything else?

I am very tempted. I am a very experienced Java developer (12 years) and have been doing professional programming for 22+ years (C, C++, Java). Unfortunately no Android experience, and my hash/crypto/p2p knowledge is limited.

My current assignment probably ends by Christmas, and after that I could possibly do this for two months straight. It would, of course, be open source, and I always do TDD programming (high-quality code), and I might have colleagues willing to pitch-in, but they may be squeamish about a project like this. Haven't asked yet.

I will think about this for a few days and get back with my decision.

Near-Field and/or bu.mp intergration.  Option to limit client to one (trusted) connection, in order to limit bandwidth consumption over cell account, or ability to limit client to only download blocks with wifi.  Ability to use Dash7 for transactions, so that transactions can be distrubuted to nearby Dash7 capable devices without the need for a continuous Internet connection would be a plus, but not critical.

I recommend, instead of the GPL licence, maybe consider using the Apache License, Version 2.0.

I'll pledge 800 BTC too.

( I think we need to advertise this bounty in some Android app development forums.....   Who wants to post news of our bounty in a bunch of Android app development forums, with a link back to this thread....? )

I would totally have a go at this if I wasn't currently in a coding frenzy with other stuff, partly android-related, and I know that if I stop now my interest in this will dwindle away :)

Done.

Any chance of pooling resources in a joint effort? 1 really good app >> 5 average apps :-)

and fwiw, i recommend gplv3 :)

Posted the link in a swedish android-forum with a very short (and incomplete) swedish explanation.

Offer 50BTC for standalone client (no central service) with opensource code.

Done.

If you want people to develop something, come up with detailed specifications. I read the thread, but I cannot write a program deciding whether or not a given candidate program fullfills the specifications currently.

Write down things like how the UI should look like, exactly in which ways you want to interact with the device, etc. If you don't care about a specific UI, it means that an addressbook with contacts with bitcoin addresses is not included for example and that it could look butt ugly. We generally want happy clients, but we also cannot guess exactly what you are willing to pay for (which is often different from what can be made).

There is a reason people developed UML. It is because one can point at a document saying "this is how we want you to document the requirements". Now, I don't need a full UML spec and I don't expect you to be able to write one, but you should be able to write a coherent story explaining all the features such that for everyone contributing to this thread it is clear what is going to be developed.

I also recommend you to define the abbreviations that you use to make it a self-contained description. I have used bitcoin, but for example I was not aware of bu.mp (it does look fairly interesting, but also a bad idea as there is a central server). The bu.mp requirement and a gplv3 license already seem to be incompatible (read the bu.mp license agreement). I think technically you can distribute something as gplv3 and calling a proprietary API, but it's rather messy, legally speaking.

What does 'creating a transaction mean without internet access'? The way I read it is that you just want to store a transaction like 'MOVIE TICKET - 5BTC - <address of receiver> <source address>', which you can later retrieve again by listing all such transactions. That's the level of detail one needs before one starts development as an example.

That way you can say before a single line of code is written what a sane way is to present the UI for example, whether it is even possible to make it run on a specific version of Android (another thing which was not specified), whether the (unspecified) performance characteristics are even possible on device X (what is the reference device).

In short, as in most software projects, the client is not clear about what he wants and in this case there are multiple stakeholders, which requires you to get to a consensus of what you want. First figure out what you want, then ask again.

The first thing we need is a working interface with Mybitcoin.com that can use as many of it's functions as possible, such as it's addressbook.  It would be nice if the interface can play nice with bu.mp in order to use it to trade addresses with the rest of your contact info.  The standalone client is after that.

What I mean by "in the absence of Internet" is that the client is a true 'lightweight' client, with a pruned blockchain (which requires that merkle tree pruning be implimented in the main client first) so that the user doesn't have to be connected to the Internet at all times in order to send money, as a website interface would.  This allows a client to create a transaction with or without the Internet and send it whenever the Internet becomes available or by another future means such as Dash7 mesh networking if such a thing becomes available. 

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

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?

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.

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.

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.

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.

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

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

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?  ::)

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.

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.

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.

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 :-)

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

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.

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 :)

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?

1740 BTC is not enough for you?

Ad supported software has it's place, but not on my hardware.  Only open source software qualifies for my bounty contribution.

that's about $400... that's a measly amount for work like this that'd take time.

Sure, but people can reasonably add conditions to their bounties that require FOSS attributes.

Read the quote I was quoting. It was the person saying whether $400 isn't enough. Hint: it isn't, unless you want to do it & the $400 is a bonus. This is a perfectly doable task but would take quite a while to do to perfection (which personally if I'm taking people's money then I do want to). ;D

Oh please no!
Automatically stealing a few cents per transaction would start the whole mess about the puddinpop cuda client again, don't worry I'll probably stick to opensourcing the core and make an ad based Frontend and give people the option to disable the ads by sending me a few coins :-)

My js-remote (http://tcatm.github.com/bitcoin-js-remote/index.html) is fully working on Android and supports local transactions by displaying QR codes on the phone and scanning them with the camera. It's also possible to display QR codes on a computer and send Bitcoins to it from a phone.

Does this qualify for the bounty?

I like your solution (but didn't tested it on phone yet). Unfortunately current version is still unusable because nobody will open own bitcoind RPC to internet and send plain username/password over it. I don't know how difficult is to add SSL layer, but once this will be solved somehow, my 50BTC is yours.

SSL works in theory. In practice, there's either a bug in browsers or bitcoind that prevents a reliable connection. I hope to resolve that within the next days.

Great, then I send you the rest of my bounty.

Wait a second, I thought this is about a full implementation of Bitcoin on top of Android and not some remoting. I'm implementing the whole stack in Java for a native Bitcoin app.

Personally I prefer remote solution because I don't want to have my coins on mobile phone for security reasons. So handling wallet + QR codes are enough for me and I want to support this solution. This does not mean I won't pay you for full Android stack, too.

Good point, I'm using the Android BackupManager to save and restore the wallet once it's implemented, so keeping things on a phone wont be too risky, just restore and transfer to another account :-)

You can run bitcoind on the phone. This even makes your wallet compatible with the desktop version.

What about talking with the developer for this project to see about adding Bitcoin functionality to what he's got going on?

http://timothyjc.blogspot.com/2010/12/wallet-for-android.html

Feel free, but I doubt that they are comparable tech.

The most important thing to come out of this won't be an android bitcoin client but a (hopefully less opaque) reference implementation of the bitcoin protocol, from which a bunch of different clients could potentially be built.

I'm also working on a java bitcoin stack. Let a thousand flowers bloom.

Added SSL support to js-remote (http://tcatm.github.com/bitcoin-js-remote/index.html) using a little server script.

You can just transfer a few bitcoins (as you see fit) to your phone wallet.
If your phone is stolen with saved credentials (which probably many will use) you're screwed even more

Interested in comparing notes,  I would love to see your approach to it :-)

tcatm's bitcoin-js-remote met all of my bounty conditions. I just paid him the full 800 BTC + 200 bonus for using QR codes.

I would rather have a wallet. That remote is not very user-friendly. (Think your mom).

I would rather think *your* mom!

But seriously, I understand the desire for something more like having a wallet on my phone, and I think that would be good. However, his implementation meets my needs, and it most certainly meets the requirements I posted for paying out my share of the bounty. I think the UI could be made a little more intuitive, but AFAIAC that is rearranging deck chairs on the Titanic.

Please don't anyone think of a "bounty" in terms of it being "a fair market price" for services.... as if someone was being "hired" to develop software.

It's NOT a payment for services.   It is a token "thank you" for your contribution to the larger community by providing excellent FOSS software for us all.

It is simply an AWARD, going to the best submission, and that award comes with a PRIZE attached.

If you think of it as a prize ---- not a fee --- then no one can (should) complain about the amount being too small.

Market prices are never fair, are they? :) They're just... optimized.

Anyway, is anyone continuing work on this even without the huge bounty?

I'm working on it in my spare time, and also a few others have started.
I'm not sure when I'll be able to release anything, but I got a pretty solid protocol layer worked out, just has to be tested against the Devices capabilities. The Crypto APIs are a bit harder because Android has a crippled version of the Bouncycastle, that don't provide RIPEMD-160 and ECDSA secp256k1, but I think I got that figured that out as well. I'm kinda slow with the crypto stuff, but I should get it running sometimes after my exams ^^

Edit: nearly forgot the important stuff: the network and wallet code will be released under the Apache License 2.0, the Android client itself will not, but everyone will be able to write their own :-) Also I'm interested in sharing the open source code as soon as possible, but releasing it now would just end up in thousands of forks that do not contribute to each other, so if there are developers interested in joining the java library effort please tell me, and you can start judging the ugliness of my code, or start contributing. The goal is to have a solid base implementation on which to implement additional services and interfaces.

I whish I knew more GUI programming, because to me everything could be easily done with a bit of shell scripting.   openssl would do all encryption/digest/signing you might need, just as in my bitcoin-bash-tools (https://github.com/grondilu/bitcoin-bash-tools).  There is also a qrencode program for encoding a QR code, and zbar-tools for scanning.  Obexftp would handle bluetooth communications.  Everything else could be done withh the bitcoind command line client itself.  So all we need is a GUI scripting language that could organize all this.  So : is there a port of zenity on Androïd ??

Android is not a GNU platform, even if it runs Linux. You'd have to port a lot of the tools you're using in your shell scripts. I'm not even sure bash is readily available. Zenity isn't, and would require a lot of work to port. However, there is a simple XML description language for building Android GUI's; scripting that could be easier.

Well, I guess you're right.  Thanks for reminding me why I dislike Androïd.

What about adding Busybox?  Or even all of the GNU tools neccessary to make Android a full GNU/Linux compatible?  Considering that most people who are using an android smartphone are almost always connected to the Internet, it's not unreasonable to have symlinks to an entire set of libraries on the cloud.  For that matter, how big would a staticly linked bitcoind binary be?  HAs anyone tried it to find out?

Statically linked bitcoind for android is about 4 MB.

What about just getting rid of Android and join the MeeGo project ?

MeeGo is dead meat.

Excellent.  That's nothing.

Noble effort. But it's like trying to propel linux to the desktop in a world of window.

Hasn't this been done?

As far as I know, desktop Linux barely have any marketshare.

http://en.wikipedia.org/wiki/Linux_adoption

There's no good way to measure the market share of Linux, but it certainly more than barely there. We're getting off topic though.

I'll take a look at it. Let me know.

Any favorite communication/sharing channels?

I'm personally trying to get to grips with gerrit, which might be a good way to ensure code quality by code review, also it allows automatic builds and checks via hudson  8)

How about #bitcoin-dev on freenode?

Well I can share single classes there but as I said I don't want to make it world accessible yet.

What I want is a community working on improving a single network/protocol core implementation in Java, and having 10 independent forks just reduces the collaboration. I want to create a functional core before releasing mainly to group interested people around it to help improve and maintain it, and then we can make it completely public.

Just to let the subscribers of this thread know:

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 (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/ (http://code.google.com/p/bitcoin-wallet/)

Any news on this? The thread must be revived!

I also pledge minimum 20 BTC for a functional lightweight android client, but I might donate more if I like it and it turns out being actually used by other people, so I can exchange money with them wherever I am without juggling change. :)

Please continue this, I think it's quite important for BitCoin to have a portable version that's easy to use -- otherwise it's not much of a wallet.

And so the prize tag of the bounty had increased.

Andreas is making steady progress. I think the next release is blocked on a working BoundedMemoryStore, which I'm planning on tackling after a few other things.

Hello Everyone,

i just created my first Android App. It's a RPC client for bitcoind.
Right now it can show you some stats
http://lwinet-server.dyndns.org/external/bitcoiner/Screenshot_main.png http://lwinet-server.dyndns.org/external/bitcoiner/Screenshot_sendform.png
(tap on the hashrate to start/stop mining)

and can send bitcoins to an address.

Feel free to try it out
http://lwinet-server.dyndns.org/external/bitcoiner/net.lwi.BitCoiner.apk (http://lwinet-server.dyndns.org/external/bitcoiner/net.lwi.BitCoiner.apk)

Plans for the future (if and when i got time):
-QR-code integration for sending and receiving coins
-Show correct account balance (currently the bitcoind api only counts the received coins, not the sent ones)
-Maybe instant currency conversion
-Localization
-Release source code when its not that embarrassing any more :-)

Any thoughts?


Belkaar

P.S. I don't want to qualify for the bounty but donations are welcome :-)
1As5wGKDLovNPWQ3Me7z4abhhH3HgWBshd

I look forward to trying it when the source code is available. :)

Didn't a remote client for Android already exist?  I thought someone had that one licked back in July.

[/quote]
Didn't a remote client for Android already exist?  I thought someone had that one licked back in July.
[/quote]

If so please point me to it. No point in doing the stuff twice.

Here it is then :-). But you've been warned, it ain't pretty.

http://lwinet-server.dyndns.org/external/bitcoiner/BitCoiner_source.zip (http://lwinet-server.dyndns.org/external/bitcoiner/BitCoiner_source.zip)

Belkaar

How do I install this on my Android device?  Fyi I have a rooted Motorola Attic 4G running Android 2.6.1. and have terminal access.

Actually i just now found it in the bitcoin market.  Installs fine and runs, but I need to setup a server with a static ip I guess.

But what I would really like is to run bitcoin daemon locally on my Android...

That's what the bounty is about ^^

It works just fine with a home server and dynamic dns (i.e. dyndns.org). Thats what i wrote it for.

Having a wallet on my phone is way to dangerous for me since i'm wiping my phone whenever a new rom pop up :-). One of the times I'd surely miss backing it up.

As I said. I'm not after the bounty. Just thought it was the right place to post it.

Installed fine, and fired up at first, but after inputting the neccessary data, I now get...

"Sorry!
The application BitCoiner (process net.lwl.bitcoiner) has stopped unexpectedly.  Please try again.

(Force Close)"

It doesn't seem to matter how many times I try.

Is BitCoiner available via the Market ?
(btw: I guess there are already two other implementations of that: "BitcoinDroid" and "Miner Status")

I just got this new Android, and I might try porting the JAVA Bitcoin client to Android.  What would be the minimum requirements to claim this bounty?  If I can get a simple text or menu interface that is able to download the hash chain, mine coins, send coins, and do everything else that the regular client can do, does that mean I qualify for this bounty?  What is the approval process to obtain t he bounty involve?

I don't think you'll ever want to mine bitcoins on a phone, so that's not required. The bounty is not controlled by a single person so the requirements might differ. Most pledgers will probably agree that:

• It needs to participate as a node in the network (e.g. no remoting of a Bitcoin client running on another machine)
• Be able to receive and send bitcoins
• Be open source (GPL, Apache, BSD, you name it, but the source must be distributed and we must be allowed to reuse it in other places)
• Backup and restore would be nice

And as for the "Java Bitcoin client" there is none yet. There are only two implementations of the networking protocol: [mike]'s great work with bitcoinj (quite complete, and already at the base of a test client on android) and my BitDroid-Network implementation (which is quite unfinished because I wanted to put the blockchain and crypto operations into another module but never got to it, but I still maintain that for many connections mine performs better ^^).
I hope to see some of your code someday :D

No. Since its not finished Im to cheap for the 25$ Android market fee ( which i find ridicolous considering google also collects a sales percentage :-)

Wait, do free apps have to pay this fee also?

Wasn`t aware of the market fee. Shame on you Open Handset Alliance !

The fee is there to ensure all Market participants have been through the Google credit card anti-fraud system (which is pretty good). The point is to try and raise the bar for people uploading malicious or illegal apps.

It's not there to make a profit for Google, which is in no need of the poxy amounts of cash generated by it.

The fee is a single, one-time $25 per person/organization. (Contrast this with Apple's $99 per YEAR.) The fee is charged whether you intend publish free or paid apps. Personally I paid it long ago and haven't published a thing yet, though I will be soon.

what's up with this?

does the bounty still hold?

1740 quite some money nowadays, noone up to this task? Andreas Schildbach's Wallet (for testnet) was almost there, wasn't it? (crashes my phone, but used to work just fine couple weeks ago)

It does for me, and my previously stated conditions, to my stated bitcoin amount.  When I pledged it, 50 bitcoins was a tip.  Now it's a day's wages.

I completely forgot about this for a while. Given the expected short-to-medium term value of Bitcoin, I think I'm going to revisit it. Though the OP should perhaps be updated to show that part of the bounty has already been paid out.

I had the impression someone was working on the client, albeit slowly. The problem seems to be the blockchain and RAM usage.

I'm not sure a full-fledged node is even the goal here, is it?


"runnable on one's own server" sounds to me like it's simply a rpc client, no?

Can the pledgers please clear this up?

Different pledges have different requirements.  An android remote control client has been developed, and I believe has been paid out.  Mine has not.

I've been inquired about this by my employer if this is viable, and I am pondering going for it making it open-source.

I've hacked together a semi-working prototype based on bitcoinj, however ran into obvious technical difficulties - bitcoinj is too fat and inefficient to the point i couldnt make a transaction.
After compiling bitcoind, the client was not able to verify (rescan) whole chain tx by tx in reasonable time, not to mention necessary use of sdcard.
The state in which code is now, no android device is up to the task except very hiend ones.

Following changes are needed to be made:
Trusting the blockchain to be correct from some point of time and start from specific merkle root is a neccessity, this should not be a problem as more than week-spanning tree forks are unlikely.
From there on, incoming txes are processed, stored locally only as blockheaders with possible forks in a backlog which gets consumed into the merkle root.

This is as lite it gets, is reasonably secure, easy on bandwith, and seems it will work on all ranges of androids way down to the severely lacking HTC Dream.

However blockheaders (https://github.com/bitcoin/bitcoin/tree/blockheaders) and complete tx/wallet rewrite are necessary to cater for performance.

Starting from where it is now this is work at least for 2 months. Should i take the bounty, at the current rate I wouldn't go below 2500BTC.

Recommendation to the pledgers: split the tasks to smaller bounties (worth ~1500-2000BTC IMO):
1) separate protocol code from bitcoin client into a library, include "lite" operation as an option, to avoid hacks pegged on the back of bitcoin client (umaintainable mess)
2) make it efficient to run on underpowered devices
3) write an easy JNI binding bitcoinj style

The android frontend is a matter of 500BTC, no more. Same goes for iPhone.

therapist

As has been noted several times, BitCoinJ is not ready for use on Android yet. We know how to make it efficient enough for use on phones and the code to do that is coming.

No bounties needed. Just patience. By the way there are at least two other people working on Android GUIs for the library.

Glad to hear it! Will keep an eye on it, though I'm not entirely convinced of from-the-scratch implementations (thus the call for JNI).

The official client won't work on Android either. It loads the block chain at startup in the same way BitCoinJ currently does.

Can the 800 BTC pledgers please clear up which have been paid out? And how much there is to gain right now?

As to everyone else, please add to the bounty. I think this android client is really important. The open source mentality is nice and all, but we shouldn't rely on people working for free too much, especially now that time is of the essence. We're missing out on all those android fans who read about Bitcoin now, many would surely join if they had a full client.

Agreed. It appears that half the bounty was already paid, which really dampened my enthusiasm for working on this.

Mine has not been paid out...

"By local transactions, I assume a minimum capability of a local wallet.dat, the ability to use bu.mp (or similar) to transfer addresses, and the ability to create transactions in the absence of working Internet access.

I pledge 50 under these conditions"

I'm going to add a new condition, the system needs to be working on my Samsung Intercept by July, or I'm cutting my pledge in half.  This pledge has turned into a large chunk of what I have left.

Just throwing it in there that if I ever get some time I'd love to take this on. I been wanting to dip my feet in the Android waters and I'm starting to get into this idea of Bitcoins.

Free software is for creating community. It does not mean zero pay.

Open source is for bug fixing.

Making it GPL / BSD will not hurt funding, and increased competition will reduce fears of big players in the end everybody makes more even if it isn't the whole pie.

Getting closer: http://code.google.com/p/bitcoinj/source/detail?r=89

:)

This is awesome, bitcoinj appears to be on a good way to finish the job!

This might become the main Bitcoin client. Java is much more suited for this kind of thing anyways. (I'd prefer C# even more, but for some reason all the people prefer Oracle and its patent shit to Mono.)

Anyways, I have a problem now. So many people are working on this now, I don't know whom we should pay the bounty to when they finish!

Edit: I hope the 800-pledges don't chicken out now, just because it's about 8000 USD? I want to see those brave souls granting us android support credit! I can't wait to start paying random android users in BTC! ;D

I believe some of this ransom was already payed?

One of the two 800BTC bounties was paid months ago. I have no idea of the status of the other, which is why I haven't moved forward on this.

What is the status now?

Has anyone thought of embedding bitcoinj ( http://code.google.com/p/bitcoinj/ ) in a full Android Bitcoin client?

Of course generation does not seem to make much sense on devices with limited computing power.

The problem is that the standard way the Bitcoin does things overwhelms Android.   Not enough memory or data storage, too much storage access.

oh i wish i had seen this pledge earlier :)

is there any site that collects bounties with an escrow service? On the one hand I see how generous many BTC people are but on the other hand with a 2 or 3 man month effort one would like to be sure to get payed in case one provides the best solution.
Also I see BTC is just perfect for such a bounty service. I saw pledge site for open source development (http://cofundos.org/) fail but I'm sure if the pledges were charged for real, things might have gone differently.

Any news on how this has been going?

Is there a spec list to work against? Or just has to work on Android solely, ie no cloud/remote?

Now we have two:

Bitcoin-android (based on BitcoinJ)
  - https://github.com/barmstrong/bitcoin-android

BitPay (based on InstaWallet)
  - https://github.com/warpi/BitPay
  - http://forum.bitcoin.org/index.php?topic=24452.0

BitPay involves trusting InstaWallet.
You missed to mention RPC-clients like http://sourceforge.net/projects/bitcoin/

Is the above mentioned Bitcoin-android already stable? http://code.google.com/p/bitcoin-wallet/ workds on BitcoinJ, too.

Looks like it has some good feedback on HN: http://news.ycombinator.com/item?id=2732708

Bitcoin Android Released!

http://forum.bitcoin.org/index.php?topic=26684.msg334880#msg334880

Actually bitcoinandroid is not the first standalone wallet.

For example, just the day after BitcoinJ was released, I released the first version of Bitcoin Wallet

https://market.android.com/details?id=de.schildbach.wallet

Never got any piece of the bounty, though... )-:

bitcoin wallet keeps eating wallet files and is not a functional wallet yet. unfortunately that is true for the other app as far as i read here on the forum. some guy got the same issue with persistent crashes at startup that i know too well from bitcoin wallet.

i hope that bitcoin wallet stays as honest as it was and sticks with testnet for the time being as i so far lost all my test coins i used to show it to my friends. if the trouble is due to bitcoinJ@android then bitcoin wallet was the first to receive a reward in my eyes but bitcoinJ deserves its share as well once the issues are solved.

I installed this app today and I'm quite convinced it deserves at least a major piece of the bounty promised. Whatever y'all imagined when you promised to pay some BTC: This is it!

To be honest, my 20 BTC bounty hasn't been paid yet. Couldn't get around testing those apps yet, and I often see reviews with coins disappearing.

If this works out, I guess I should pay half of it to the main BitcoinJ developer, he really made this possible.

Then... mh, I'll try the Bitcoin Wallet app. The other one practically admitted sending my wallet to Google unencrypted -- I don't know whether to call it theft or a bad joke. :P


Any experiences with the Wallet app? Has anyone lost coins using it, or faced any other problems? I'll fool around with it a bit as soon as I find some time for it.

I don't want to pay bounty to a program that just leaks or steals the coins in the end, so I'm taking my time watching first.

The Bitcoin Client (http://forum.bitcoin.org/index.php?topic=29109.0) I'm developing is aimed to be cross-platform with Android being one of the supported platforms from the get-go.

I'm not sure if it's up to your standards or needs, but if you think that it's something you'd like see developed seriously please consider donating/investing in the project.

More details: http://forum.bitcoin.org/index.php?topic=29109.0

-Eli

If you don't trust Bitcoin Wallet, you can try the Testnet version first. Or try with only small values.

And yes, there are known problems. It will take some time to get them ironed out.

If you should have troubles with "stuck" coins, I can help you out.

Cheers,

Andreas

I like this bounties escrow service idea.
Is anyone working on it?

Have a look at
https://en.bitcoin.it/wiki/Contracts

Very interesting outlook for the future, regarding your question especially Example 3 (assurance contracts).

The bitcoin wallet from Andreas Schildbach has been around for months now. We use it at POS in our business every day. Andreas gives immediate support and keeps on developing updates and putting in more functionality over time. No coin got ever lost and every payment made has always arrived.

If anyone deserves to get the bounty this thread is all about, it's him. I have personally donated btc to him for creating this sftware and releasing it open source.

What's the story with all you guys offering btc here for that app, was that all hot air and you are now sitting back home smiling because you got the app for free?

No offense to yourself, nor to Andreas; but his app never met my own bounty requirements.  I've conversed with him about this in the past via email, and have received some interest in finishing those requirements; but apparently mine are too few to be of significant interest.

Could you be more precise about your requirements??
The last post surprised me a bit as my shildbach-transactions always had problems. Once I sent 1BTC and it only got sent after sending another 0.005BTC. Now I have 1BTC stuck since weeks and sending another 0.005BTC went through without breaking the other BTC loose like last time. A permanent grayed out transaction.
Therefore my requirements would be some way to backup my wallet but if all txns get through, I'm happy with it.

This is often caused by the inconsistent nodes the android client connects to, it was limited to 6 nodes for concurrent connection issues that android had (I might be wrong though, correct me Goonie :/)

I've too have been testing/forking the codebase and been using it September, it has little issues. I highly recommend you connect to a dedicated back-up node or your bitcoind on a vps or something ( this is my setup ).

But if I need a connection to my bitcoinD, what's the point in having Schildbach's app? I can already remote control bitcoinD with other apps that are far less code.

Why? I think the answer is obvious but single point of failure is a good one. by connecting to other known well connected nodes such as your own, or https://en.bitcoin.it/wiki/Fallback_Nodes you eliminate this risk, not to mention it's a full feature client and makes you part of the network.

*due to the limited number of connections (6) you might not able to get the "freshest" data on the network thus you have spotting tx confirmations and etc.
the satoshi and any bitcoin client can suffer from the same problem from this low connectivity.

ok, fine, but with a sample of 6 peers, the Schildbach-Client could also just drop those with the stalest data and connect to fresher ones, couldn't it? How come there are so many stale clients that 6 peers are not enough to get the head of the block chain??

I have been in the past on this very topic thread, but much deeper.  Basicly everything has been implimented except for off network transactions, and direct (ad hoc wifi) or semi-direct (two android phones using an open wifi access point as a bridge) client connections to both trade transaction data and blocks.  The later could be accomplished by utilizing broadcast/multicast features of wifi & a "piratebox" as the bridge (http://wiki.daviddarts.com/PirateBox) and Andreas has created another program for networking android devices into a complex screen that uses multicast to coordinate, so I know it's within his abilities to do so.  I just think that he doesn't consider off-network ad-hoc transactions to be a worthwhile goal.  I wan't to be able to use my phone wallet, for in person transactions, even during a power/network outage. (or beyond wireless service range, camping perhaps?)  Otherwise a remote control app for my home bitcoind is just as powerful.  If I can't use it to buy half-priced milk at the corner store because the store owner doesn't have power to run his refrigeration units (or his register to process credit card transactions) than it's not "cashlike".

1740 BTCs ?  Wow

Good luck preventing him from double spending. If all shops accept offline transactions, he walks from door to door spending the same coins over and over again restoring his backup in between. I doubt BTC will be any useful offline.

The risk of a double spend isn't always of greatest concern.  It would still be quite technically difficult to double spend even in this situation, kinda stupid to risk it for half priced milk.

Some of those bounties have mutually exclusive goals, so they cannot all be claimed for the same client.

Sorry in advance for the necropost. It took ages until this got settled.

My little 20 BTC bounty is being paid now, I sent 15 to BCCAPI and will send at least the remaining 5 to BitcoinSpinner when I find a donation address.


The bounty was obviously not intended for "lol I meet the nonexistent specification when there is good weather" crapware. I need software that I can actually use to introduce people to Bitcoin. The kinds of errors, crashes and broken designs (Backup?!) the first Android clients produced were unacceptable. The Schildbach wallet has failed me on many occasions, and did destroy money on a newcomer's phone. I needed Nandroid backups to get coins back multiple times, those with locked-down phones were not so lucky.

BitcoinSpinner using BCCAPI was the first project that delivered and worked reliably enough to be used, so I can announce it as my personal winner. Strange as it is in terms of block chain management, it does what is asked of it.

That said, I encourage everyone to join in and support whichever client they prefer. A few BTC does not seem much, but if a lot of people donate, it adds up and supports good software and thus Bitcoin.

What is the status of this project? Was it ever completed? Anyone have the git?

These days the Schildbach wallet works pretty well, but I don't think the full bounty was ever claimed. This thread is a great example of why bounties are a bad idea, actually. I usually tell people not to post bounties when I see them these days and so far nobody has ever disagreed with me.