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

[Rassah]

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 )

[1715149749]

1715149749

[1715149749]

1715149749

[Koshi]

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!

[danielW]

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.

[Koshi]

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.

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?

[danielW]

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.

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

[Ente]

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.

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

[Koshi]

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.

[JonathanCoe]

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

[TheFascistMind]

Bitmessage is dead.

[Rassah]

Bitmessage is dead.

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.

[slothbag]

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.

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

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

[jeezy]

Bitmessage is dead.

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

[worldcup]

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

[JonathanCoe]

Bitmessage is dead.

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 want one on my phone, too.

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

[jeezy]

i want one on my phone, too.

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

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.

[justusranvier]

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.

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

[JonathanCoe]

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.

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.

[TheFascistMind]

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.

[justusranvier]

Why isn't that enough to solve this problem?

It is. (once it's actually implemented)

Someone's just FUDing.

If you actually READ (as in RTFM) the thread, such a grouping or streams solution is not simple as you might naively assume. And probably why it is not implemented.



Anyone who is actually a programmer knows the "devil is in the details". So these idiots who make proclamations based on some general rumor or conceptual idea, can't hold a candle to someone who is actually down in the trenches implementing this stuff and thus speaks from a deeper understanding of the issues involved.

For the meantime, Bitmessage is dead. And bringing it back to life isn't going to be trivial.

So who is trolling, as you always do.

Anyone still paying attention to this "Legendary" idiot deserves the misinformation he spews.

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.

Quoted for lolz.