Rassah
Legendary
Offline
Activity: 1680
Merit: 1035
|
|
August 22, 2014, 06: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 )
|
|
|
|
Koshi
Newbie
Offline
Activity: 20
Merit: 0
|
|
August 22, 2014, 11: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!
|
|
|
|
danielW
|
|
August 25, 2014, 04:21:00 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.
|
|
|
|
Koshi
Newbie
Offline
Activity: 20
Merit: 0
|
|
August 25, 2014, 12:34:09 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.
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
|
|
August 25, 2014, 05: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.
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
Legendary
Offline
Activity: 2126
Merit: 1001
|
|
August 26, 2014, 07: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.
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
Newbie
Offline
Activity: 20
Merit: 0
|
|
August 26, 2014, 08: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.
|
|
|
|
|
TheFascistMind
Newbie
Offline
Activity: 42
Merit: 0
|
|
September 18, 2014, 12:42:38 PM |
|
|
|
|
|
Rassah
Legendary
Offline
Activity: 1680
Merit: 1035
|
|
September 18, 2014, 03:35:46 PM |
|
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
|
|
September 18, 2014, 10:47:55 PM |
|
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
Legendary
Offline
Activity: 2126
Merit: 1001
|
|
September 19, 2014, 07:46:13 AM |
|
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
Legendary
Offline
Activity: 1237
Merit: 1010
|
|
September 19, 2014, 08:00:12 AM |
|
They are already working on a solution to the problem. If you read the thread carefully its kinda clear.
|
|
|
|
worldcup
Newbie
Offline
Activity: 38
Merit: 0
|
|
September 20, 2014, 07:50:10 AM |
|
is it actually done or still under development?the function is awesome and helpful, i want one on my phone, too.
|
|
|
|
JonathanCoe
Newbie
Offline
Activity: 11
Merit: 0
|
|
September 20, 2014, 01:17:55 PM |
|
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
Legendary
Offline
Activity: 1237
Merit: 1010
|
|
September 21, 2014, 02:09:16 PM |
|
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
Legendary
Offline
Activity: 1400
Merit: 1013
|
|
September 21, 2014, 02:20:18 PM |
|
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
Newbie
Offline
Activity: 11
Merit: 0
|
|
September 21, 2014, 08:06:58 PM |
|
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
Newbie
Offline
Activity: 42
Merit: 0
|
|
September 24, 2014, 01:43:51 PM |
|
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
Legendary
Offline
Activity: 1400
Merit: 1013
|
|
September 24, 2014, 01:52:41 PM |
|
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.
|
|
|
|
|