Of course! I've absolutely no wish to claim anything that would be difficult for you to pay. If .33 BTC works for you that's great, if not then please don't worry about it. If I were doing this for the money then I would have picked another project to work on Whatever works for you is fine.

Hey crazy_rabbit,

If you're prepared to honour the bounty then I'd like to claim it. I've written an Android client for Bitmessage called 'Bitseal' (it's the same project referenced earlier in the thread). The app is open source + freely licensed, and comes with a large body of automated tests:

https://github.com/JonathanCoe/bitseal
https://github.com/JonathanCoe/bitseal-tests
https://github.com/JonathanCoe/bitseal-server

The latest release (0.5) includes local encryption of the app's databsase, using SQLCipher. This means that if someone seizes your device while the app is locked, they will not be able to access any of your sensitive data without the password.

The app can be downloaded either directly as an APK file (see https://bitmessage.org/forum/index.php?topic=4155.msg9750#msg9750) or through the beta testing facility of the Google Play Store. There's a group for people testing it here: https://plus.google.com/communities/115838283581504499326.

Let me know what you think!

Cheers,

Jonathan

Bitseal 0.5 (Bitmessage Android Client) is available for testing:

https://bitmessage.org/forum/index.php?topic=4155.msg9750#msg9750

Many thanks to everyone for their support so far! Your feedback is very welcome.

Atheros, the lead developer of Bitmessage, has made a request for feedback from the crypto community on possible new feature first suggested by Greg Maxwell: https://bitmessage.org/forum/index.php?topic=4170.0

The feature in question is adding support for Bitmessage addresses which, rather than containing the hash of two EC public keys as is the case now, contain a single compressed EC public key. This would allow for greater resilience against traffic analysis, because it would remove the need to request the full public keys of an address before sending a message to it and the need for the receiving node to respond to such requests.

Greg Maxwell's proposal was originally discussed in these posts:

https://www.reddit.com/r/bitmessage/comments/1ay3kh/why_not_use_the_public_key_directly/

https://www.reddit.com/r/bitmessage/comments/1kc03b/please_support_nonhashed_addresses/

The main point that Atheros is asking for feedback on is whether there is any downside to using the same EC key for both ECDSA and ECIES (signing and encryption).

Any input from the Bitcoin community would be very much appreciated!

PyBitmessage 0.4.4 has been released! Downloads for Linux, Mac, and Windows are available at https://bitmessage.org/wiki/Main_Page

This update upgrades PyBitmessage to version 3 of the Bitmessage protocol: https://bitmessage.org/wiki/Protocol_specification_v3

Anyone interested can find the discussion thread about Protocol Version 3 here: https://bitmessage.org/forum/index.php?topic=4067.0

It's a really large update, with several important improvements to Bitmessage. Many thanks to Atheros and Thomas for all the work they've put into this.

I commissioned Gregor to make a logo for my Bitmessage Android app, "Bitseal". He communicated very well and responded quickly to feedback. I'm very happy with the final result, and would definitely recommend him for other projects

Jonathan

Thanks! To answer your questions:

Currently the app uses its own address book. You're right that it might be useful to integrate Bitmessage addresses with the standard contacts list - I'll look into it. Thanks for the suggestion.

I haven't tried using Bitseal as a background service with an API yet, but I think it should certainly be possible. One good point about Bitseal's code is that there's a fairly clean separation between the UI and the background processes, so it ought to be easy to either adapt Bitseal itself or just pull out the background code and make it into a standalone app.

The only major change I made to PyBitmessage was a new set of API commands for the functions required by the Android app. Other than that there were some very small tweaks, of which only one was relevant to normal PyBitmessage. I've submitted that as a pull request: https://github.com/Bitmessage/PyBitmessage/pull/709

I'm pleased to announce that the beta code of Bitseal, an Android client for Bitmessage, is now available.

   

Github:      
https://github.com/JonathanCoe/bitseal
https://github.com/JonathanCoe/bitseal-tests
https://github.com/JonathanCoe/bitseal-server

Screenshots:   
https://imgur.com/a/utC00

Working features:
   - Sending messages
   - Receiving messages
   - QR codes for addresses
   - Address Book
   - Import addresses
   - Export addresses
   - Choose which servers to use (including your own)


Roadmap for development (subject to change):
   - Update for Bitmessage Protocol Version 3
   - Lite client message retrieval using prefix filters (credit to Peter Todd for suggesting this)
   - Local encryption of the database, using SQLCipher
   - SSL for connections between clients and servers
   - POW implemented in C or C++ via the Android NDK
   - Support for broadcasts
   - Refresh the UI


Notes:

- Bitseal is not ready for widespread use yet. A full release is planned once lite client message retrieval is implemented. The app will be available on the Google Play store once this is done.

- Bitseal is free, open source software, released under the Gnu General Public License Version 3.

- Some parts of Bitseal include, are based on, or are reliant upon software written by others, including Jonathan Warren, Sebastian Schmidt, Tim Roes, Roberto Tyley, the bitcoinj developers, and the Bouncy Castle developers. This is noted in the source code where applicable.

- I have set up a few default servers which can be used for testing purposes. Anyone is free to set up and use their own. The server application is simply a slightly modified copy of PyBitmessage.

- The development of Bitseal has been a large project, taking many months of work. I'm doing it on a purely non-profit basis. Bitcoin donations are very gratefully received: 1ALTrxJ3Yn3Rc85Uf467u3ZcpHCzx4jDAT

As JustusRanvier alluded to, Bitmessage doesn't have a blockchain, as there's no need for a distributed consensus. Instead Bitmessage has a set of shared network objects (messages and public keys), with nodes in the network retaining the last 2.5 days worth of that data.

You're quite right that phones are not suitable for processing all the data that a full node deals with, which means that we have to come up with a way to make a 'lite' client for Bitmessage. Thankfully I think that we now have a good solution for this, namely prefix filtering of the kind used in Bitcoin stealth addresses (see http://sourceforge.net/p/bitcoin/mailman/message/31813471). I met Peter Todd a few days ago and he suggested this, so all credit to him.

So, we now have a decent method of creating lite clients for Bitmessage - it will just take some time to get it implemented. It's also worth nothing that lite clients could help us to mitigate the damage of flooding attacks (such as the one going on now) by shifting most of the burden of network processing away from end-users, in favour of volunteers and other groups that can run high-capacity full nodes. That's my hope anyway.

The Bitmessage network is undergoing a flooding attack, with someone sending lots of spam broadcast messages. We're working on a way to fix or mitigate the problem, with lots of discussion in the thread you linked to.


I'm working on it  There should be a significant update in coming weeks.

Ente is right - it's basically a handshake. When you want to send someone a message, your Bitmessage client requests their public keys from the network and then verifies that they are correct using the hash encoded in their Bitmessage address. The usual reason for getting the "waiting for encryption key" message is that the owner of the destination address is offline and their public keys are not available elsewhere on the network.

You can see a full description of the process on page 7 of the Bitmessage technical document, here:

https://bitmessage.org/Bitmessage%20Technical%20Paper.pdf

In the long term I'd like to see Bitmessage support non-hashed addresses (the address IS the public key), as was suggested by Greg Maxwell some time ago (see below). That would resolve this problem, although obviously the recipient of the message will still have to come online at some point to receive it.

http://www.reddit.com/r/bitmessage/comments/1kc03b/please_support_nonhashed_addresses
http://www.reddit.com/r/bitmessage/comments/1ay3kh/why_not_use_the_public_key_directly