Topic: [ANNOUNCE] Bitmessage - P2P Messaging system based partially on Bitcoin - page 3. (Read 89873 times)
September 18, 2014, 07:42:38 AM
August 26, 2014, 03:35:20 AM
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
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
August 26, 2014, 03:22:05 AM
hmm it seems to work when I sent it to you, did you get it?
Yes, I received your message and replied. I'm glad to see that it's working, at least in this case.
August 26, 2014, 02:58:50 AM
all I get is "sending public key request waiting for reply"
I have sent to a few diffrent callback addresses and the light is yellow.
I have sent to a few diffrent callback addresses and the light is yellow.
Perhaps you could try sending me a message? My address is BM-2D96qyC3rF72YaxktSYco3eWdNJPXbuN6U
What does it show on the "Network Status" tab of the Bitmessage client? How many connections and processed messages are there?
hmm it seems to work when I sent it to you, did you get it?
All the other messages say "waiting for encryption key. will request it again soon."
I am pretty sure this simply means the receiver is offline. Your client will resend daily until the receiver confirms it received your message.
In fact it's a handshake, first the public keys need to be exchanged, and then the message itself is sent.
Ente
August 25, 2014, 12:07:41 PM
all I get is "sending public key request waiting for reply"
I have sent to a few diffrent callback addresses and the light is yellow.
I have sent to a few diffrent callback addresses and the light is yellow.
Perhaps you could try sending me a message? My address is BM-2D96qyC3rF72YaxktSYco3eWdNJPXbuN6U
What does it show on the "Network Status" tab of the Bitmessage client? How many connections and processed messages are there?
hmm it seems to work when I sent it to you, did you get it?
All the other messages say "waiting for encryption key. will request it again soon."
August 25, 2014, 07:34:09 AM
all I get is "sending public key request waiting for reply"
I have sent to a few diffrent callback addresses and the light is yellow.
I have sent to a few diffrent callback addresses and the light is yellow.
Perhaps you could try sending me a message? My address is BM-2D96qyC3rF72YaxktSYco3eWdNJPXbuN6U
What does it show on the "Network Status" tab of the Bitmessage client? How many connections and processed messages are there?
August 24, 2014, 11:21:00 PM
all I get is "sending public key request waiting for reply"
I have sent to a few diffrent callback addresses and the light is yellow.
I have sent to a few diffrent callback addresses and the light is yellow.
August 22, 2014, 06:17:17 AM
Maybe not the headers that are used now, but a new header that is encrypted as part of the message? Have each message have a header that is a standard set of characters, like 1234567890, that's encrypted with the recepient's key just like the rest of the message, and have the light client request these encrypted headers one by one, checking which it can decrypt, and once it finds the 1234567890 string, request the rest of the message.
Your idea sounds quite a lot like Bmng-Dev's proposal. Under his proposal all messages would include a new MAC that can be requested along with public key R by a lite client and then used to identify which messages are destined for it. It could then request the full msg payloads from a server, perhaps obscuring its request by also asking for extra msg payloads that it doesn't really need. As both public key R and the mac would be unique for each message, this seems like it would be pretty decent in terms of security.
Having said all that, there may well be flaws in any or all of the 3 proposals we have so far. Hence the request for input from the Bitcoin community.
And yeah, trying to absorb semi-coherent crypto proposals at 3am is always fun
I appreciate you making the effort! 
August 22, 2014, 01:31:38 AM
Why can't light clients just request message headers that all messages will have, and if they don't decrypt using the address, just reject them? Similar to how SPV clients just request block headers, and discard blocks or addresses not relevant to them.
While I may be missing something, I don't think this would work. In Bitmessage, the message headers are unencrypted and do not contain any identifying information about the destination of the message (see https://bitmessage.org/wiki/Protocol_specification#Message_structure). The only part of a person-to-person message ("msg") that is encrypted is the full msg payload itself (see https://bitmessage.org/wiki/Protocol_specification#msg). Therefore I can't see how a lite client could identify the messages sent to them using only the message headers.
Maybe not the headers that are used now, but a new header that is encrypted as part of the message? Have each message have a header that is a standard set of characters, like 1234567890, that's encrypted with the recepient's key just like the rest of the message, and have the light client request these encrypted headers one by one, checking which it can decrypt, and once it finds the 1234567890 string, request the rest of the message. May need to add some extra variables to the header string to make decryption harder, and use bloom filters to obfuscate which messages are really meant for it. At least that's how I imagined it. I'm sure there's something unworkable with this idea, though
(and all that techy crypto stuff in the 3 proposals document is going over my head, especially at 3 in the morning 
) August 21, 2014, 03:41:12 AM
Why can't light clients just request message headers that all messages will have, and if they don't decrypt using the address, just reject them? Similar to how SPV clients just request block headers, and discard blocks or addresses not relevant to them.
While I may be missing something, I don't think this would work. In Bitmessage, the message headers are unencrypted and do not contain any identifying information about the destination of the message (see https://bitmessage.org/wiki/Protocol_specification#Message_structure). The only part of a person-to-person message ("msg") that is encrypted is the full msg payload itself (see https://bitmessage.org/wiki/Protocol_specification#msg). Therefore I can't see how a lite client could identify the messages sent to them using only the message headers.
For reference to anyone reading this, the discussion thread about how to do lite client message retrieval is here: https://bitmessage.org/forum/index.php?topic=4075.30
We currently have 3 proposals for how to do it, summarized in this document:
https://docs.google.com/document/d/1b5q1SmZZQ_d-8I3kaBj3Kc2vWSNnPXVOqKgbduEqyTQ/edit?usp=sharing
Any input from the Bitcoin community would be really appreciated!
August 20, 2014, 11:35:40 PM
Why can't light clients just request message headers that all messages will have, and if they don't decrypt using the address, just reject them? Similar to how SPV clients just request block headers, and discard blocks or addresses not relevant to them.
August 06, 2014, 05:00:56 PM
Nuova versione di Bitmessage!
Quote
0.4.3
Support pyelliptic's updated HMAC algorithm. We'll remove support for the old method after an upgrade period.
Improved version check
Refactored decodeBase58 function
Ignore duplicate messages
Added bytes received/sent counts and rate on the network information tab
Fix unicode handling in 'View HTML code as formatted text'
Refactor handling of packet headers
Use pointMult function instead of arithmetic.privtopub since it is faster
Fixed issue where client wasn't waiting for a verack before continuing on with the conversation
Fixed CPU hogging by implementing tab-based refresh improvements
Added curses interface
Added support for IPv6
Added a 'trustedpeer' option to keys.dat
Limit maximum object size to 20 MB
Support email-like > quote characters and reply-below-quote
Added Japanese and Dutch language files; updated Norwegian and Russian languages files
Support pyelliptic's updated HMAC algorithm. We'll remove support for the old method after an upgrade period.
Improved version check
Refactored decodeBase58 function
Ignore duplicate messages
Added bytes received/sent counts and rate on the network information tab
Fix unicode handling in 'View HTML code as formatted text'
Refactor handling of packet headers
Use pointMult function instead of arithmetic.privtopub since it is faster
Fixed issue where client wasn't waiting for a verack before continuing on with the conversation
Fixed CPU hogging by implementing tab-based refresh improvements
Added curses interface
Added support for IPv6
Added a 'trustedpeer' option to keys.dat
Limit maximum object size to 20 MB
Support email-like > quote characters and reply-below-quote
Added Japanese and Dutch language files; updated Norwegian and Russian languages files
July 14, 2014, 06:37:02 AM
Awesome!
I felt the next step for Bitmessage would be a broader userbase, via "popular chat client addon". I didn't think much about mobile integration, as it seemed too impossible to me.
Two thoughts on this:
- did you check out bitcoinj? That's what "Bitcoin Wallet" on Android is using, and it has an efficient "lite" modus.
- whatever the way to go, I would really prefer that all BM messages are all the same. As soon as some of them have a tag and some not, plausible deniability is gone, more information is added via that distinction, people need a different backchannel to say "hey, please tag messages sent to me", which again leaks info, and finally there will be many people not receiving messages because of this and dropping it all together in frustration.
Sorry for that long sentence.
Please make all BM messages the same :-)
You are doing wonderful work, this will be a big step forward!
Ente
I felt the next step for Bitmessage would be a broader userbase, via "popular chat client addon". I didn't think much about mobile integration, as it seemed too impossible to me.
Two thoughts on this:
- did you check out bitcoinj? That's what "Bitcoin Wallet" on Android is using, and it has an efficient "lite" modus.
- whatever the way to go, I would really prefer that all BM messages are all the same. As soon as some of them have a tag and some not, plausible deniability is gone, more information is added via that distinction, people need a different backchannel to say "hey, please tag messages sent to me", which again leaks info, and finally there will be many people not receiving messages because of this and dropping it all together in frustration.
Sorry for that long sentence.
Please make all BM messages the same :-)
You are doing wonderful work, this will be a big step forward!
Ente
Thanks! We're very excited to be bringing Bitmessage to Android. To answer your questions:
1) There's a small amount of code from BitcoinJ in the Android client, so yes that's been helpful for us. All credit to Mike Hearn and the others for producing it.
2) I agree that having all Bitmessage messages be structurally identical is definitely desirable. If we can preserve that while still finding a way for lite clients to identify messages addressed to them, that would be brilliant. If you follow the Bitmessage forum thread there is a suggestion from Thomas that may allow us to do that, so hopefully it will be possible.
The current message tagging proposal specifies that all messages will have a tag, but if the destination address is not a lite client then it is just 32 bytes of random data, so we're trying to keep as close as possible to messages being unidentifiable. Suggestions and ideas are very welcome.
Agreed. This sounds like some awesome changes for Bitmessage. Looking forward to the new features and using it on my mobile!
Cheers
If people are prepared to get involved and contribute to Bitmessage then I think we can make some really good progress in the near future. 
July 13, 2014, 02:57:04 PM
Agreed. This sounds like some awesome changes for Bitmessage. Looking forward to the new features and using it on my mobile!
July 13, 2014, 02:34:31 PM
Awesome!
I felt the next step for Bitmessage would be a broader userbase, via "popular chat client addon". I didn't think much about mobile integration, as it seemed too impossible to me.
Two thoughts on this:
- did you check out bitcoinj? That's what "Bitcoin Wallet" on Android is using, and it has an efficient "lite" modus.
- whatever the way to go, I would really prefer that all BM messages are all the same. As soon as some of them have a tag and some not, plausible deniability is gone, more information is added via that distinction, people need a different backchannel to say "hey, please tag messages sent to me", which again leaks info, and finally there will be many people not receiving messages because of this and dropping it all together in frustration.
Sorry for that long sentence.
Please make all BM messages the same :-)
You are doing wonderful work, this will be a big step forward!
Ente
I felt the next step for Bitmessage would be a broader userbase, via "popular chat client addon". I didn't think much about mobile integration, as it seemed too impossible to me.
Two thoughts on this:
- did you check out bitcoinj? That's what "Bitcoin Wallet" on Android is using, and it has an efficient "lite" modus.
- whatever the way to go, I would really prefer that all BM messages are all the same. As soon as some of them have a tag and some not, plausible deniability is gone, more information is added via that distinction, people need a different backchannel to say "hey, please tag messages sent to me", which again leaks info, and finally there will be many people not receiving messages because of this and dropping it all together in frustration.
Sorry for that long sentence.
Please make all BM messages the same :-)
You are doing wonderful work, this will be a big step forward!
Ente
July 13, 2014, 12:52:41 PM
ANNOUNCE: Bitmessage Android Client and Message Tagging Proposal
Discussion here: https://bitmessage.org/forum/index.php?topic=4075.0
Proposal wiki page here: https://bitmessage.org/wiki/Message_Tagging_Proposal
Android client screenshots here: https://imgur.com/a/xRGOq#0
All comments and feedback are very welcome.
Discussion here: https://bitmessage.org/forum/index.php?topic=4075.0
Proposal wiki page here: https://bitmessage.org/wiki/Message_Tagging_Proposal
Android client screenshots here: https://imgur.com/a/xRGOq#0
All comments and feedback are very welcome.
July 10, 2014, 06:17:32 AM
Hi, I create decentralized marketplace with bitmessage and bitcoin. And it can be used like exchange, more about BitXBay here.
July 09, 2014, 05:27:40 AM
what Bitmessage ?? Desentralize Chat
Good Invention will Thumb up for this project
Good Invention will Thumb up for this project
July 09, 2014, 12:42:26 AM
ANNOUNCE: Proposal for Bitmessage Protocol Version 3
Discussion here: https://bitmessage.org/forum/index.php?topic=4067.0
Proposal wiki page here: https://bitmessage.org/wiki/Protocol_specification_v3
All comments and feedback are very welcome.
Discussion here: https://bitmessage.org/forum/index.php?topic=4067.0
Proposal wiki page here: https://bitmessage.org/wiki/Protocol_specification_v3
All comments and feedback are very welcome.
June 23, 2014, 11:59:54 PM
is it the same as "troll box" or "chat box" 
maybe the difference is in the encryption?
wont it delay the message?
maybe the difference is in the encryption?
wont it delay the message?
Bitmessage is more of an email replacement than an IM one.
Jump to: