I have found several issues with current implementation. Address spoofing and Inventory injection attacks, crashing listener thread with stateless connection flood etc. There are several ways to seriously disturb functionality of this network. When I have time, I'm going to look for ultimate attack, which would be network propagated persistent attack. It would crash all clients after injecting just a single message to any node of the network. Message would also be persisted in datastore so it would recrash the client on restart. Requiring manual fix or software update to get past this issue. By design system doesn't seem to scale well. I would like to see 10 million nodes on this network. Dont run current client without virtual machine, unless you're ready to encounter interesting problems with resource consumption. (cpu, memory, network, disk)
So, even though it's inspired by bitcoin, it doesn't quite have the same rock-solid original implementation. Bitcoin would have collapsed if there were any major cryptographic bugs, but it turns out that "Entire classes of bugs [were] missing." (-Dan Kaminsky, Security Researcher).
I hope that you can help out by reporting your findings back to them. I think Bitmessage is a really cool idea. It has the potential to allow communication to occur no matter what hostile power wants to censor it. It also finally make end-to-end message encryption a default rather than an after-thought.
> It would crash all clients after injecting just a single message to any node of the network. Message would also be persisted in datastore so it would recrash the client on restart.
Wouldn't that fail to propagate through the network? Crashing nodes can't forward messages to other nodes.
I don't understand how this is the top comment. Who cares about security, can you just get interested in the features instead ? The protocol is not even mainstream yet...
I am very interested in developing an iOS client for this. We are developing a pluggable framework for Tor integration on iOS called OnionKit [1] based off of Onion Browser for the ChatSecure project [2], the only open source OTR compatible chat client for that platform. It's in pretty rough shape right now because we got stuck trying to figure out how to make Apple's Networking APIs honor the proxy settings on TCP connections, so please contact us if you can help solve this problem.
Since it doesn't involve the transfer of money or copyrighted material, it shouldn't yet be rejected by Apple's reviewers as the BitTorrent and BitCoin protocol have been. Skype is still allowed, and that technically is (or used to be?) a peer to peer communications system.
Unfortunately, you aren't presently allowed by Apple to run a background socket on iOS for longer than 10 minutes unless it is a full VoIP application, so you would never be able to use it for push-style communication, without compromising a user's anonymity via a web backend that stores your APNS token (device specific messaging token for iOS devices).
Jeesh, why are people still putting up with Apple's domineering control over what they're allowed to do with their own devices?
I know none of what you said is new news, but seeing it all come together like that really highlights the problem with Apple's policies.
IMO, a much more useful app to build would be an HTML5 Bitmessage app that users can just run in their browser (similar to the blockchain.info/wallet app for bitcoin). This would make the technology accessible to a much larger group of people.
I really like how readable the overview paper is [1]—I'd recommend reading it if you want to understand what is being proposed here. I especially thought the section on a passive operating mode was interesting. The idea that you can hide an ACK in another message, which is then broadcast to ACK both of the original messages is pretty clever. However, since Bradley's message to Charlie is also broadcast to everyone, wouldn't Eve get the same amount of information as if Bradley had just ack'd the message in the first place?
Anyhow, assuming I misunderstood something, passive listening doesn't seem to work well with their description of stream scalability, since Alice would now think she knows Bradley's stream, when it was actually Charlie's stream. For this to work, I suppose Alice would have to know that Bradley would be a secret listener to begin with.
In any case, it is definitely an interesting read. Seems like the type of thing Julian Assange would love to have. [2]
I had a brief look at the paper. I got stuck on the section about scalability. I can't see how that could be implemented so that authentication can be done given that the nodes are untrusted (by which I mean implemented with a much smaller amount of computation and storage than was required in the non-optimized approach).
Oh hey, I had an idea to make this exact protocol a few weeks ago, just for fun. I didn't think of adding a POW in though.
Anyway, this is a pretty cool implementation. Just one question though, how does a node know if a certain message is for it, rather than another node? The whitepaper didn't specify anything about attaching a recipient to the message.
Node tries to decrypt all the message it receives to see if it was for them. It's there in the whitepaper:
>Just like Bitcoin transactions and blocks, all users would receive all messages. They would be responsible for attempting to decode each message with each of their private keys to see whether the message is bound forthem.
This is interesting. Four minutes for proof of work is tough, though. That's a long time to wait to send a message.
Bitcoin itself could often use sideband communication protocols for, e.g. transaction details, but this doesn't seem to tick all the boxes: incentives alignment needs to be worked on, and I would suggest that the spamming prevention is somewhat naive; there should be a market.
Consider -- all bitmessage messages are considered "high quality" by default, and therefore sent directly to one's phone.
Botnet operators determine that while one botnet client could send 100 e-mails per minute, the open rate on one bitmessage message is nearly 100%, making it economically feasible to botnet spam bitmessage.
I would like to see more self leveling, and a pricing market baked in to something like this, as well as a way to send messages instantly.
The proof of work concept is really interesting. It's a good way to deter spamming. I wonder whether email can utilize the same concept to force a cost for sending email. May be a two-tier system, emails with POW signature would be sent faster, while plain old email has lower priority.
POW is very important, without it I wouldn't have had any problems destroying the network totally and quickly. Because protocol allows very efficient attack amplification. Even with POW I can do serious damage, but I'm required to run cluster of high end servers. Without POW I can use any random computer to waste whole network using network propagation and attack amplification.
I find it troublesome that some of the code in BitMessage seems to be taken directly from Stackoverflow.com responses (it actually reminds me a lot of what I see happening at school). With that being said -- I do appreciate that this is new and can be improved upon quickly by a community of people with interest in such a system.
I don't see anything wrong with taking a working and bug-free code/function and using it in your own software given the snippet is in public domain. Why re-invent the wheel?
I used to have an idea which is similar to this project. With BT network, we can exchange the database or part of the database between nodes. So the IP address will not be the personal ID anymore, everyone could register an ID for the service.
I'm not sure I see myself using BitMessage (yet) but if nothing else this FAQ has introduced me to TorChat, which looks promising for simple private text messaging - and whatdoyaknow, the latest version is in Debian Sid (and a slightly older one is in Wheezy).
I don't really see what BitMessage provides over TorChat for example, other than being able to deliver messgages when the sender is offline. It's a much easier protocol, and much less that can go wrong.
> other than being able to deliver messgages when the sender is offline.
This is exactly the point. Most people can not afford to run a mailserver 24/7. With Bitmessage you only have to be online very shortly every other day.
I'm a noob. from what I've read webRTC is encrypted. Is that all I need to have secure communications (video, audio chat). Or do I need something more like this. Is it only text chat?
The client UI is very nice and straightforward. But it's borderline unusable on old laptop (on my trusty 1000he atom n270) because of the raw power needed to compute and send messages.
I think it will be interesting to see if this goes down a similar path to the old newsgroups wherein someone develops a protocol to send binary data through bitmessage efficiently.
It has been done, there's at least one base64 channel on bitmessage. I imagine its horrible slow to send though, the POW difficulty scales with the size of the message.
I did a bit of playing with the client. Once you generate an address under the 'Your Identities' tab, right click and select 'Special Address behaviour' and have it 'Behave as a pseudo-mailing-list address'.
Here's a test one if you feel like trying it out: BM-2DCGcvGwvGUr7yYSzWWa6rBrVok8mM7HtK
I don't think the name matters but I called it 'kruhft-list'.
[+] [-] Sami_Lehtinen|13 years ago|reply
[+] [-] jamoes|13 years ago|reply
I hope that you can help out by reporting your findings back to them. I think Bitmessage is a really cool idea. It has the potential to allow communication to occur no matter what hostile power wants to censor it. It also finally make end-to-end message encryption a default rather than an after-thought.
[+] [-] MacsHeadroom|13 years ago|reply
Keep hacking, my friend.
[+] [-] Zr40|13 years ago|reply
Wouldn't that fail to propagate through the network? Crashing nodes can't forward messages to other nodes.
[+] [-] jokoon|13 years ago|reply
[+] [-] MacsHeadroom|13 years ago|reply
[deleted]
[+] [-] chrisballinger|13 years ago|reply
Since it doesn't involve the transfer of money or copyrighted material, it shouldn't yet be rejected by Apple's reviewers as the BitTorrent and BitCoin protocol have been. Skype is still allowed, and that technically is (or used to be?) a peer to peer communications system.
Unfortunately, you aren't presently allowed by Apple to run a background socket on iOS for longer than 10 minutes unless it is a full VoIP application, so you would never be able to use it for push-style communication, without compromising a user's anonymity via a web backend that stores your APNS token (device specific messaging token for iOS devices).
[1] https://github.com/ChatSecure/OnionKit [2] https://chatsecure.org
[+] [-] jamoes|13 years ago|reply
I know none of what you said is new news, but seeing it all come together like that really highlights the problem with Apple's policies.
IMO, a much more useful app to build would be an HTML5 Bitmessage app that users can just run in their browser (similar to the blockchain.info/wallet app for bitcoin). This would make the technology accessible to a much larger group of people.
[+] [-] mrmaddog|13 years ago|reply
Anyhow, assuming I misunderstood something, passive listening doesn't seem to work well with their description of stream scalability, since Alice would now think she knows Bradley's stream, when it was actually Charlie's stream. For this to work, I suppose Alice would have to know that Bradley would be a secret listener to begin with.
In any case, it is definitely an interesting read. Seems like the type of thing Julian Assange would love to have. [2]
[1] https://bitmessage.org/bitmessage.pdf
[2] https://news.ycombinator.com/item?id=5574589
[+] [-] cantos|13 years ago|reply
[+] [-] neilparikh|13 years ago|reply
Anyway, this is a pretty cool implementation. Just one question though, how does a node know if a certain message is for it, rather than another node? The whitepaper didn't specify anything about attaching a recipient to the message.
[+] [-] dpacmittal|13 years ago|reply
>Just like Bitcoin transactions and blocks, all users would receive all messages. They would be responsible for attempting to decode each message with each of their private keys to see whether the message is bound forthem.
[+] [-] vessenes|13 years ago|reply
Bitcoin itself could often use sideband communication protocols for, e.g. transaction details, but this doesn't seem to tick all the boxes: incentives alignment needs to be worked on, and I would suggest that the spamming prevention is somewhat naive; there should be a market.
Consider -- all bitmessage messages are considered "high quality" by default, and therefore sent directly to one's phone.
Botnet operators determine that while one botnet client could send 100 e-mails per minute, the open rate on one bitmessage message is nearly 100%, making it economically feasible to botnet spam bitmessage.
I would like to see more self leveling, and a pricing market baked in to something like this, as well as a way to send messages instantly.
[+] [-] chadillac83|13 years ago|reply
[+] [-] ww520|13 years ago|reply
[+] [-] josephagoss|13 years ago|reply
Apparently it did not catch on that well and a decade later Satoshi used it among other things to create Bitcoin.
[+] [-] Sami_Lehtinen|13 years ago|reply
[+] [-] e1ven|13 years ago|reply
http://en.wikipedia.org/wiki/Hashcash
[+] [-] YAYERKA|13 years ago|reply
[0] https://github.com/Bitmessage/PyBitmessage/blob/master/src/a...
[1] http://stackoverflow.com/questions/1119722/base-62-conversio...
[+] [-] dpacmittal|13 years ago|reply
[+] [-] so898|13 years ago|reply
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] vy8vWJlco|13 years ago|reply
[+] [-] hucker|13 years ago|reply
[+] [-] sprash|13 years ago|reply
This is exactly the point. Most people can not afford to run a mailserver 24/7. With Bitmessage you only have to be online very shortly every other day.
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] illbert|13 years ago|reply
[+] [-] joshontheweb|13 years ago|reply
[+] [-] johnchristopher|13 years ago|reply
[+] [-] smitec|13 years ago|reply
[+] [-] nwh|13 years ago|reply
[+] [-] kruhft|13 years ago|reply
[+] [-] kruhft|13 years ago|reply
Here's a test one if you feel like trying it out: BM-2DCGcvGwvGUr7yYSzWWa6rBrVok8mM7HtK
I don't think the name matters but I called it 'kruhft-list'.
[+] [-] kruhft|13 years ago|reply
https://bitmessage.org/forum/index.php/topic,1420.0.html
[+] [-] socrates1024|13 years ago|reply
[+] [-] FellowTraveler|13 years ago|reply
[+] [-] droopyEyelids|13 years ago|reply
[+] [-] ancarda|13 years ago|reply
[+] [-] unknown|13 years ago|reply
[deleted]