Topic: [ANNOUNCE] Bitmessage - P2P Messaging system based partially on Bitcoin - page 2. (Read 89814 times)

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.

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

Great project. I have a few questions:

Does this app use its own address book, or does it integrate with the existing address book? Google contacts allow arbitrary fields to be attached to records. It should be possible to add Bitmessage addresses to existing contact this way.

Will Bitseal be able to run as a background service that other Android applications could call via an API?

Will the changes you made to PyBitmessage get merged upstream?

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

https://i.imgur.com/GnCeFtt.png   https://i.imgur.com/eYb4e3w.png   https://i.imgur.com/wcSPaIv.png

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

Ok i have fix it but in a strange way. First i open bitmask and then the bitmessage begin to see the nodes but was always in yellow status. After that i close bitmask and bitmessage and when i open again bitmessage it was working and now is always in green status

Redownload or try other system/computer. Something looks very wrong with your setup.
Normaly should connect (even) without port-forwarding.

Any idea why i cant connect to internet with bitmessage? I always have the "could not connect to Peer" and i have setup my router to port forward 8444 and i try to delete and the .dat files but with no luck. My net connection is still in red.

Quoted for lolz.

Official version of Bitmessage is functioning for me again, even though the broadcast spam is still high.

Apparently many users moved to the new experimental version.

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.

Bitmessage doesn't work like that. It only stores a few days of history.

Great! But would this mean to have the whole blockchain on your phone? Which is a nogo clearly. I know a lightweight solution like Electrum ist not as secure as a full node but there's really no other way for mobile devices I guess.

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.

is it actually done or still under development?the function is awesome and helpful, i want one on my phone, too.

They are already working on a solution to the problem. If you read the thread carefully its kinda clear.

I don't follow you.. You say POW doesn't work, but suggest a(nother) coin, which itself would use POW?
I prefer it this way, keeping it simple for the user. Sending messages take a little time, but they don't have the hassle with some coin stuff. This is a messenger tool, after all!

Also, why should POW not work? Sending a message is somewhat expensive, costs, say, 30sec CPU time. For a user as mail-replacement this is ok. Spammers need expensive equipment to set up a big spamming operation. And even then, with 30sec CPU, this translates into 0.2 cents electricity costs. A single spam message probably won't yield more than that, in average.
And finally, if ever there is a spam problem, it is easy to adjust the POW costs.

Ente

In my opinion POW cannot be used for spam prevention.. wrong doers will always out power regular users hashpower.

So that leaves only 2 solutions..

1. Whitelist, explicit trust.. this kinda ruins Bitmessage main feature anonymity
2. Charge valuable tokens per message.. Bitcoin? Nxt already has anonymous encrypted messages costing a tx fee?? or maybe its own coin.

Unfortunately the masses want free messages, I think a fee per message would not be a big success.

Still works for me... Based on the discussion it sounds as dead as Bitcoin was dead when transaction malleability, or any other bug, was found.