Topic: Android Bitcoin Client Bounty (1740 BTC pledged) - page 7. (Read 44734 times)

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.

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.

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'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?  

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

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

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.

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.

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.

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.

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.

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?

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

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. 

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 -

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

Done.

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

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

and fwiw, i recommend gplv3

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