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.
Don't assume that Bitcoin hasn't had it's share of implementation problems. There's been a couple of remote DOS bugs, remote command execution vulnerabilities, and an integer overflow that lead to the creation of 32 million additional bitcoins.
Good point. Fortunately, there haven't ever been any vulnerabilities so severe that the entire network was shut down until a software update could be released (as the grandparent said he was looking for with bitmessage).
There was certainly a bug recently where the whole blockchain split and one half of the split ended up losing all the bitcoins they had mined on that limb. As far as cryptocurrencies go, I'd say that was a serious vulnerability.
Thanks for that link... it seems as though there were a lot of people that were thankful and a lot that were against it. Assuming the "guess" of the change address getting 200BTC, that was 800BTC that they paid out. Not knowing enough about it all, why was one of the commenters there saying that it was from the EFF do you know?
It was paid out of bitcoin faucet funds, the bulk of which were donated by the EFF when they stopped accepting bitcoin. A position on which they have recently changed their stance.
I was referring to CVE-2010-5139. Essentially somebody discovered that they could craft a transaction that caused a crazy number of Bitcoin to be introduced to the chain at that transaction, and used this to credit themselves on the main network. At that point the the exploit was patched and a new chain formed back before the transaction occurred, orphaning it in the process.
> 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.
It depends where the issue is exactly triggered in code. If it's possible to get data persisted which crashes system on recall, then it's possible. BM also uses pickle on 'non-secure' data, which could allow much wider exploits with lower level attack code.
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 think the ultimate human cost of not providing free native, easy-to-use cryptographically secure communications apps on iOS is worse than the ideological battle against Apple's idiotic walled garden.
It's not just a threat against activists under oppressive regimes, it's a matter of "national security". Centralized chat services like WeChat [1] (developed by by Tencent in China) or WhatsApp [2] get more popular, the governments of the world will be able to intercept all private communication on a large scale. Although to be fair, privacy has been effectively dead pretty much worldwide for a while now.
> Jeesh, why are people still putting up with Apple's domineering control over what they're allowed to do with their own devices?
Because when the average user hits a badly written app that constantly uses the network in the background and kills the battery in 2 hours, they're not gonna go sift through logs to see what's taking the power assertions.
Except that could still happen on iOS and has nothing to do with the complaint about Apples strict policies. Plus it also makes the false assumption that users have to sift through logs on platforms that aren't as strict with the apps they allow into their market place.
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).
True, you're going to need gigabytes of memory. My test client used over 6 gigabytes o memry after small inventory injection play. I have a few great ideas how to create efficient propagating attacks, but I haven't yet tried those.
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.
As long as we're speculating wildly, I have a theory... (Bear with me now) It is possible, if not probable, that Ted Nelson is himself Satoshi and was only trying to throw everyone off the trail (or it's Adam Back, I can't be sure, but it's definitely one of the two, if not both...).
I love the Satoshi speculations a lot, I think Bitcoin is awesome enough as it is, but to add that the creator is unknown just makes the story even more compelling.
If Bitcoin does take off or a derivative based on Bitcoin, it will be weird having this anonymous guy as the creator. Most computer science history has no large mystery like Bitcoin will have. (If Bitcoin is still around in a decade or more)
It's funny, of all the William Gibson imaginings that have found their way into real life, Bitcoin is probably the most purely Gibsonian, in its plotline of the anonymous, genius creator of some earth-shaking thing whose identity is the stuff of legendary speculation.
Makes me wonder if there's a Bigend out there with a crack team of Satoshi researchers on a globetrotting adventure...
With millions of dollars piling into bitcoin, both via startups and via direct purchase of coins on the markets, it does seem likely that someone somewhere has put a "due dilligence" team on the case.
Assuming that Satoshi remains anonymous. It is entirely possible that he could out himself at some point in the future, or be outed by friends/family/collegues after he died (or before).
Theres also the speculation that Satoshi is not an individual, but rather a government or organization. In this case, there are almost defiantly written records of 'who' he is.
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 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 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'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'.
