[ANNOUNCE] Bitmessage - P2P Messaging system based partially on Bitcoin

[HostFat]

Yes.
Is it impossible?
If NOT, will it possible in the near feature?
If NOT again, so you should show an error message explaining exactly that it isn't possible (something that stop the user to try it again), because I was going to use it to make many different tests.

[Atheros]

Yes.
Is it impossible?
If NOT, will it possible in the near feature?
If NOT again, so you should show an error message explaining exactly that it isn't possible (something that stop the user to try it again), because I was going to use it to make many different tests.

It is currently impossible but it can probably be made possible. Bitmessage currently does not process its own messages and public key requests- it only broadcasts them to other nodes. But evidently it needs to process them so that tests like yours will succeed. I will have it fixed shortly or at least will prevent the UI from going forward with the send.

[HostFat]

Thank you

[Atheros]

Of course!

I have patched the UI to disallow the send and inform the user of the problem. The code is in the master branch on Github and the version number is the same as before.

[HostFat]

I tried other tests with a friends, and I got this status message: "Public key was requested earlier. Receiver must be offline. Will retry."
So the receiver must be online to receive the messages? I thought that it was working as Bitcoin, so both clients can connect whenever they wont and they will get the message from other nodes.
Am I wrong? Do both clients must be online to receive messages?

[Atheros]

I tried other tests with a friends, and I got this status message: "Public key was requested earlier. Receiver must be offline. Will retry."
So the receiver must be online to receive the messages? I thought that it was working as Bitcoin, so both clients can connect whenever they wont and they will get the message from other nodes.
Am I wrong? Do both clients must be online to receive messages?

You need their public key from them before you can send a message. After you send or receive one message to or from them then you will always have their public key.

Alice -----pubkey request----->
         <-----------pub key--------- Bob            (after seeing the pubkey request)
Alice --------message-------->                         (after receiving the pubkey)
         <-------acknowledgement----Bob            (after receiving the message)

At this point Alice and Bob have eachother's pubkeys, AND the public as a whole has Bob's pubkey. If anyone sends a message to Bob then they won't have to do the first two steps. Their software will simply mark Bob's pubkey as "used personally" so that it never deletes it.

The two clients never need to be online at the same time but the person to whom you sent the message must go online long enough to do the POW for the pubkey message and send it out (a couple minutes).  Currently if you restart Bitmessage while this particular POW is being completed, it doesn't continue the POW gracefully. For msg and broadcast messages on the other hand, the POW task automatically continues if the user restarts Bitmessage while it is being completed.

[marcus_of_augustus]

Just tried the latest version and seems to work ok ... well done Atheros, this looks like a really promising piece of work.

Any idea when security audit might get done?

[Atheros]

Just tried the latest version and seems to work ok ... well done Atheros, this looks like a really promising piece of work.

Any idea when security audit might get done?

Thank you; that's very nice of you to say.

It really depends on who can audit it. I'll be spamming a cryptography mailing list tomorrow.

[HostFat]

@Atheros
ok, but can you explain why I can send Bitcoin to other users even if the client doesn't know my public key?
I'm not so expert about the deep works of Bitcoin ...

[Xenland]

@Atheros
ok, but can you explain why I can send Bitcoin to other users even if the client doesn't know my public key?
I'm not so expert about the deep works of Bitcoin ...

From what I can tell about bitmessage it looks like since it uses elliptical curve which is what Bitcoin addresses are derived from at a particular layer, I believe if you were to take public key of the elliptical curve and sha256 it and base58 (its been awhile that’s probably not exactly right) you got your self a bitcoin address.

[HostFat]

You need their public key from them before you can send a message.

What I'm asking is this: will Bitmessage be able (on next versions) to achieve the status where two users are able to send each other messages without being online contemporary?
I mean "never".

[Atheros]

@Atheros
ok, but can you explain why I can send Bitcoin to other users even if the client doesn't know my public key?
I'm not so expert about the deep works of Bitcoin ...

In the very early days of Bitcoin you did have to have the other party's public key and all transactions were of this format. Within a couple weeks, Satoshi started using transactions that spent to a hash of a public key- the hash encoded in a Bitcoin address. A modern typical Bitcoin transaction script basically says "Whoever has a public key that hashes to match this hash may spend this bitcoin to someone else."  Then the receiver of the bitcoin who spends it later must at that time supply both the public key and the signature for this latest transaction. You'll notice that nothing is encrypted in Bitcoin; only signatures are used. In Bitmessage, person-to-person messages are signed and then encrypted. Broadcast messages are only signed, therefore, just like with Bitcoin, you don't need anyone else's public key ahead of time to send a broadcast message and they don't need yours to subscribe. But because it is not possible to do encryption without a public key, the public key must be acquired before a person-to-person message can be sent.

From what I can tell about bitmessage it looks like since it uses elliptical curve which is what Bitcoin addresses are derived from at a particular layer, I believe if you were to take public key of the elliptical curve and sha256 it and base58 (its been awhile that’s probably not exactly right) you got your self a bitcoin address.

That's that right idea.
Public keys   ----->   SHA512  ---->   RIPEMD160  ---->  Attach the address version number, stream number, and checksum ---->  base58

You need their public key from them before you can send a message.

What I'm asking is this: will Bitmessage be able (on next versions) to achieve the status where two users are able to send each other messages without being online contemporary?
I mean "never".

You can currently. But the first time they use their addresses with each other, Alice will have to press the send button and then may go offline, then Bob will have to go online at some point (to reply with his public key) and may go offline, then Alice will have to go online at some point (to send the message). I know it sounds like a lot of back and fourth but after it is done once then sending a message is a one-step-process. Also if Charlie comes along and wants to send Bob a message within the next 4 weeks, the above process is skipped because everyone already has Bob's pubkey.

[HostFat]

But because it is not possible to do encryption without a public key, the public key must be acquired before a person-to-person message can be sent.

Can you add a function to broadcast/share a database of all public keys created of the last X days on the Bitmessage's network? (between clients)
You can add a limit on Bitmessage settings on how many public keys (or how many X "days" ) it will be shared with other clients.

[Atheros]

But because it is not possible to do encryption without a public key, the public key must be acquired before a person-to-person message can be sent.

Can you add a function to broadcast/share a database of all public keys created of the last X days on the Bitmessage's network? (between clients)
You can add a limit on Bitmessage settings on how many public keys (or how many X "days" ) it will be shared with other clients.

I could have Bitmessage broadcast out a public key after generating it, yes. As I cannot think of any real downsides it seems like it would be a good idea. I will implement it. The X days variable already exists; it is set at 4 weeks. I would only do this for randomly generated addresses though as users will usually generate deterministic addresses in large batches and only use them as needed.

EDIT: Implemented. Active in version v0.2.4 and beyond.

[HostFat]

Wohoo!
This should fix the problem (for me) that I explained previously.

[HostFat]

Ok, I tested the last version (v0.2.4) and it finally works perfecly!
It's a good alternative to the email, and it's completely decentralized!
We just need more nodes

[lenny_]

Is Bitmessage working on Linux? I tried it on Debian Testing:

Code:

$ python --version
Python 2.7.3
$ python bitmessagemain.py 
PyBitmessage requires PyQt. You can download it from http://www.riverbankcomputing.com/software/pyqt/download   or by searching Google for 'PyQt Download' (without quotes).
Error message: No module named PyQt4.QtCore

PyQt on Debian exist only in version designed for Python3. So I installed it - python 3.2 and PyQt 4.9.3-4:

Code:

$ python3 --version
Python 3.2.3
 python3 bitmessagemain.py 
  File "bitmessagemain.py", line 22
    except Exception, err:
                    ^
SyntaxError: invalid syntax

Any suggestions? I am using latest version from git.

[Atheros]

PyBitmessage is written for Python 2.7, not Python 3 and that is the source of the problem. I currently don't know how easy it would be to get running on both and if it would be too much work to support both in the future.

[HostFat]

Can you make it portable?

[Atheros]

Can you make it portable?

By portable do you mean, for example, able to run it on a USB flash drive and take the keys and messages with you? This would be quite easy actually.