6 ms·

According to the white paper, "all users receive all messages." How, then is the system scalable to a large network?

benregenspan 13y ago
The whitepaper proposes to handle this by having nodes join separate clusters once their databases reach a certain size.
- synctext 13y ago
  Please consider this a security review by a tenured P2P professor: The whitepaper describes a simple and focused system relying on partitioning in an attempt to preserve scalability. Bitmessage has many architectural similarities to Usenet and also offers no valid response to spam. Using a proof-of-work system to combat spam is proposed, but to-date science has not yet seen a working approach anywhere. Details are missing on this vital element plus defenses against the Sybil attack are missing from this design. Mechanisms such as the "averageProofOfWorkNonceTrialsPerByte" in this system only slow down attacks and do not stop them. Check the impossibility proof by Harvard to see that systems like Bitmessage which react to any message cannot build an effective Sybil defense: http://dash.harvard.edu/handle/1/4907301 http://dash.harvard.edu/handle/1/4907301 So this is known as a hard unsolved problem. Further diving into the scalability issue is this project thread on their forum: https://bitmessage.org/forum/index.php?PHPSESSID=8cl6qeafitkac363ufcqma3tp5&topic=3391.0 https://bitmessage.org/forum/index.php?PHPSESSID=8cl6qeafitk... It would be great if the partitioning concept and algorithms could be explained in detail. It's again a hard problem, even group size estimation in a hostile environment is already non-trivial. So how group consensus is formed to do a break-up is difficult and prone to attacks. This design is not incentive compatible. TOR has over 50% Bittorrent traffic, it's difficult to stop users from using(abusing?) TOR like that. Systems like Bittorrent and Bitcoin have some incentives, but Bitmessage with broadcasts and proof-of-work might even have a negative incentive for participation. I have seen no mechanism to prevent it's users broadcasting Blueray rips. This would bring down the system, one cluster at a time. Please check this work, it shows how to bring this type of P2P networks down: www.christian-rossow.de/publications/p2pwned-ieee2013.pdf‎ Publicity like "Bitmessage Sends Secure, Encrypted, P2P Instant Messages" might be nice. It creates a false sense of safety. If you want to protect against NSA snooping, you're up against a real army of crypto experts with decades of experience each. Nice to see that this project has such an active Github community, 480 closed issues and 1159 commits. But, in my opinion it's back to the drawing boards... Sorry. Disclaimer: working for 8 years on Tribler, a streaming Bittorrent client.
  - awt 13y ago
    Bitmessage's POW concept is not only proposed but implemented and being used in practice.
  - berdario 13y ago
    my2c: The common meme in the bitmessage community is that the POW helps mitigate flooding, but it's not quite there for spam prevention
  - richardlblair 13y ago
    I appreciate the write up, it's why I popped into the thread. That said, at least these folks are trying to protect against the NSA. What do you purpose we all do? Lay down and accept that they watch everything we do? Fuck that. Let's continue to build tools as a community. They may have a lot of people, but our community is bigger. So, fuck them. People should continue to experiment, and try new things until we come up with various way to protect against the god damn NSA.
    - synctext 13y ago
      Indeed, we should not roll over and declare privacy an illusion. A lot of people are experimenting with designs that will never work. It's just wasting programming resources, while projects like Tor starve for volunteers. My research team is currently merging Tor and Bittorrent (http://forum.tribler.org/viewtopic.php?f=2&t=5128&p=8585#p8585 http://forum.tribler.org/viewtopic.php?f=2&t=5128&p=8585#p85...). Clear designs (and lots of them) are more important then experimental code I believe.
      - Natanael 13y ago
        Doesn't I2P fit better, considering the design requirements? Tor would require very significant changes to scale better for high volume traffic, but I2P already handles it reasonably well.
        slashdotaccount 13y ago
- berdario 13y ago
  There are a bunch of different proposals for scaling bitmessage (with and without "streams") https://bitmessage.org/forum/index.php?topic=2550.msg5271 https://bitmessage.org/forum/index.php?topic=2550.msg5271
Ihmahr 13y ago
They have some vague ideas for scalability that they do not know how to implement. Also they have some major security issues that I pointed out to them, but they simply ignored. I am sure bitmessage will never be a success because it is fundamentally broken.
- berdario 13y ago
  I've read some criticism of bitmessage sometimes, but it's been quite scarce (as with all interesting feedback) as of now... care to link to the bug report/forum post/blog post where you wrote the security issues you mentioned?
- Atheros 13y ago
  Hello, I'm not sure what questions you have asked in the past but I would be happy to answer them here. -Atheros / Jonathan (creator of Bitmessage)
  - wcummings 13y ago
    Have you seen this post (https://news.ycombinator.com/item?id=6866972 https://news.ycombinator.com/item?id=6866972), and what do you think of it? I'm interested in bitmessage but it being unvetted / not heavily reviewed gives me pause. Do you have any doubts about the design (that can't be easily solved)? Cheers, wc
    - Atheros 13y ago
      Regarding the link, The proof of work requirement exists to keep the network from being flooded too easily. It has the side benefit that it may make sending spam uneconomic. That said, any attacker with a good GPU without a financial incentive could send a very inconvenient number of messages through the network as has happened before. About the paper "On the Sybil-Proofness of Accounting Mechanisms", I'm not sure of its relevance as Bitmessage uses neither accounting nor reputation. The stream branching algorithm will indeed require a good group size estimation algorithm. My current best thought is to use child streams whenever there are a certain number of messages already going through each of one's current streams per unit time. "So how group consensus is formed to do a break-up is difficult and prone to attacks." Luckily using child streams doesn't require consensus; one can decide for one's self. To join a child stream, all one does is say that they are a member of that stream in version messages, create Bitmessage addresses with that stream number imbedded therein, and advertise the node's existence in the parent stream from time to time. But malicious attackers could cause problems by flooding a stream and getting others to make a bad decision about when to start using a child stream. "I have seen no mechanism to prevent it's users broadcasting Blueray rips. This would bring down the system, one cluster at a time." The proof of work mechanism is supposed to prevent that. Broadcasting torrent files in Bitmessage broadcasts would require much less computing resources for the sender. "Please check this work, it shows how to bring this type of P2P networks down..". Which attack specifically? And why hasn't anyone used it to take down Bitcoin? Regarding your last question, if someone throws an FPGA at the PoW algorithm, they could flood the network with a lot of data and that concerns me. And, as mentioned above, deciding when to use child streams in the context of a hostile environment remains and open question. -Atheros

The whitepaper proposes to handle this by having nodes join separate clusters once their databases reach a certain size.

synctext 13y ago
Please consider this a security review by a tenured P2P professor: The whitepaper describes a simple and focused system relying on partitioning in an attempt to preserve scalability. Bitmessage has many architectural similarities to Usenet and also offers no valid response to spam. Using a proof-of-work system to combat spam is proposed, but to-date science has not yet seen a working approach anywhere. Details are missing on this vital element plus defenses against the Sybil attack are missing from this design. Mechanisms such as the "averageProofOfWorkNonceTrialsPerByte" in this system only slow down attacks and do not stop them. Check the impossibility proof by Harvard to see that systems like Bitmessage which react to any message cannot build an effective Sybil defense: http://dash.harvard.edu/handle/1/4907301 http://dash.harvard.edu/handle/1/4907301 So this is known as a hard unsolved problem. Further diving into the scalability issue is this project thread on their forum: https://bitmessage.org/forum/index.php?PHPSESSID=8cl6qeafitkac363ufcqma3tp5&topic=3391.0 https://bitmessage.org/forum/index.php?PHPSESSID=8cl6qeafitk... It would be great if the partitioning concept and algorithms could be explained in detail. It's again a hard problem, even group size estimation in a hostile environment is already non-trivial. So how group consensus is formed to do a break-up is difficult and prone to attacks. This design is not incentive compatible. TOR has over 50% Bittorrent traffic, it's difficult to stop users from using(abusing?) TOR like that. Systems like Bittorrent and Bitcoin have some incentives, but Bitmessage with broadcasts and proof-of-work might even have a negative incentive for participation. I have seen no mechanism to prevent it's users broadcasting Blueray rips. This would bring down the system, one cluster at a time. Please check this work, it shows how to bring this type of P2P networks down: www.christian-rossow.de/publications/p2pwned-ieee2013.pdf‎ Publicity like "Bitmessage Sends Secure, Encrypted, P2P Instant Messages" might be nice. It creates a false sense of safety. If you want to protect against NSA snooping, you're up against a real army of crypto experts with decades of experience each. Nice to see that this project has such an active Github community, 480 closed issues and 1159 commits. But, in my opinion it's back to the drawing boards... Sorry. Disclaimer: working for 8 years on Tribler, a streaming Bittorrent client.
- awt 13y ago
  Bitmessage's POW concept is not only proposed but implemented and being used in practice.
- berdario 13y ago
  my2c: The common meme in the bitmessage community is that the POW helps mitigate flooding, but it's not quite there for spam prevention
- richardlblair 13y ago
  I appreciate the write up, it's why I popped into the thread. That said, at least these folks are trying to protect against the NSA. What do you purpose we all do? Lay down and accept that they watch everything we do? Fuck that. Let's continue to build tools as a community. They may have a lot of people, but our community is bigger. So, fuck them. People should continue to experiment, and try new things until we come up with various way to protect against the god damn NSA.
  - synctext 13y ago
    Indeed, we should not roll over and declare privacy an illusion. A lot of people are experimenting with designs that will never work. It's just wasting programming resources, while projects like Tor starve for volunteers. My research team is currently merging Tor and Bittorrent (http://forum.tribler.org/viewtopic.php?f=2&t=5128&p=8585#p8585 http://forum.tribler.org/viewtopic.php?f=2&t=5128&p=8585#p85...). Clear designs (and lots of them) are more important then experimental code I believe.
    - Natanael 13y ago
      Doesn't I2P fit better, considering the design requirements? Tor would require very significant changes to scale better for high volume traffic, but I2P already handles it reasonably well.
      - slashdotaccount 13y ago
berdario 13y ago
There are a bunch of different proposals for scaling bitmessage (with and without "streams") https://bitmessage.org/forum/index.php?topic=2550.msg5271 https://bitmessage.org/forum/index.php?topic=2550.msg5271

Ihmahr 13y ago

They have some vague ideas for scalability that they do not know how to implement. Also they have some major security issues that I pointed out to them, but they simply ignored. I am sure bitmessage will never be a success because it is fundamentally broken.

berdario 13y ago
I've read some criticism of bitmessage sometimes, but it's been quite scarce (as with all interesting feedback) as of now... care to link to the bug report/forum post/blog post where you wrote the security issues you mentioned?
Atheros 13y ago
Hello, I'm not sure what questions you have asked in the past but I would be happy to answer them here. -Atheros / Jonathan (creator of Bitmessage)
- wcummings 13y ago
  Have you seen this post (https://news.ycombinator.com/item?id=6866972 https://news.ycombinator.com/item?id=6866972), and what do you think of it? I'm interested in bitmessage but it being unvetted / not heavily reviewed gives me pause. Do you have any doubts about the design (that can't be easily solved)? Cheers, wc
  - Atheros 13y ago
    Regarding the link, The proof of work requirement exists to keep the network from being flooded too easily. It has the side benefit that it may make sending spam uneconomic. That said, any attacker with a good GPU without a financial incentive could send a very inconvenient number of messages through the network as has happened before. About the paper "On the Sybil-Proofness of Accounting Mechanisms", I'm not sure of its relevance as Bitmessage uses neither accounting nor reputation. The stream branching algorithm will indeed require a good group size estimation algorithm. My current best thought is to use child streams whenever there are a certain number of messages already going through each of one's current streams per unit time. "So how group consensus is formed to do a break-up is difficult and prone to attacks." Luckily using child streams doesn't require consensus; one can decide for one's self. To join a child stream, all one does is say that they are a member of that stream in version messages, create Bitmessage addresses with that stream number imbedded therein, and advertise the node's existence in the parent stream from time to time. But malicious attackers could cause problems by flooding a stream and getting others to make a bad decision about when to start using a child stream. "I have seen no mechanism to prevent it's users broadcasting Blueray rips. This would bring down the system, one cluster at a time." The proof of work mechanism is supposed to prevent that. Broadcasting torrent files in Bitmessage broadcasts would require much less computing resources for the sender. "Please check this work, it shows how to bring this type of P2P networks down..". Which attack specifically? And why hasn't anyone used it to take down Bitcoin? Regarding your last question, if someone throws an FPGA at the PoW algorithm, they could flood the network with a lot of data and that concerns me. And, as mentioned above, deciding when to use child streams in the context of a hostile environment remains and open question. -Atheros