Topic: [ANNOUNCE] Bitmessage - P2P Messaging system based partially on Bitcoin - page 28. (Read 89873 times)
November 29, 2012, 02:14:27 PM
A few complaints. Due to firewall restrictions, I'm only able to connect through a handful of whitelisted ports. It'd be nice if the program could automatically determine an open one to use. Second of all, I have to click on my "From" address in order for it to populate the from field, despite it being selected by default.
November 29, 2012, 02:08:09 PM
Did someone say backdoor?
How do you mean?
November 29, 2012, 01:47:55 PM
Great idea. If you implement discussion boards it may become even more popular than Freenet-Frost.
You can send message to me - BM-2neVjntfgA38WbRufTFoooUrtRpGeNATJ1m
You can send message to me - BM-2neVjntfgA38WbRufTFoooUrtRpGeNATJ1m
November 29, 2012, 01:43:07 PM
The UI is actually quite gorgeous!
November 29, 2012, 12:29:51 PM
Quite interesting! It's vaguely reminiscent of TorChat or whatever it's called. The whitepaper provides several key points such as the anti-spam measures. I applaud you good sir.
November 29, 2012, 09:49:07 AM
This is great. Thanks for taking it on. I'm very much encouraged by the professionalism of the paper and the website. I'll try the app out later.
Based on reading the paper I have a few comments. I don't know if the design is set in stone by now or if you're still open to modifications.
The streams construction is very clever and I think it could work well. One question is what if I have an old and widely propagated address in a root stream, and eventually it gets overloaded? Some people have to move. But nobody wants to give up their old and well known address.
For thin client nodes, they can't tune into the torrent of all messages (they may be on mobiles). You could consider a Bloom filter construction for them as we are doing for Bitcoin, so nodes can express interest in some probabilistic subset of all messages. Because Bloom filters can be merged, nodes could merge together the filters set by connected clients and provide the superset of them to other connected nodes. As you get closer to the "core" of the network all bits would be set and it'd revert to pure broadcast, but this construction also allows nodes to adapt how much traffic they receive according to how much instantaneous bandwidth they have available (eg, if run on an end user computer they can throttle back their relaying whilst the user is streaming a movie by adjusting the filter FP rate).
Spammers routinely use hacked computers to send spam, so they aren't using their own CPU to calculate PoWs. This doesn't affect Bitcoin much because PoW calculations don't have to be done by users of the network, so specialized equipment can be used to outrun botnets, but in a PoW-to-play scheme you can't rely on users having much CPU. This is especially true if you want to support mobile users, which you do. As you note, your other mitigations are thwarted by crawlers that look for addresses, which is one of the most common ways to gather email addresses today. So I find the anti-spam provisions unconvincing. The magic 2 day storage window is also questionable, many users don't check their mail every two days.
An alternative approach is to link Bitmessage and Bitcoin together. A few approaches present themselves. Nodes on the Bitmessage network, which would hopefully stick around for the long term, could establish micropayment channels between each other. Micropayment channels aren't operational today because we need to re-enable transaction replacement in the main Bitcoin network, but you could certainly experiment with this approach on the testnet. To send a message then, you establish some connections to long-lived peers, send a few millicents to to each node and then submit your message. Nodes relay some of the money you sent along their broadcast paths until eventually it's exhausted. In this way, nodes are incentivized to be online all the time (and possibly store the messages for longer), and message propagation eventually stops due to either flooding the network completely or (in a very large network) exhausting the micropayments.
This means legitimate users can outbid spammers who are flooding the network. Given messages arriving from many nodes and a limited broadcast/storage capacity, nodes would prioritize messages for broadcast by the amount of money provided, and the money would ripple through the network further incentivizing nodes to prioritize the legit messages above those of the spammers.
Bitcoin and PoWs are complementary - you could allow Bitmessage-specific PoWs to start with as a way to bootstrap the network in the early days and simplify on-boarding of new users, but also support Bitcoin micropayment channels in parallel so if/when spammers arrive that have lots of CPU users can smoothly migrate to the other solution.
One issue with this is bogus nodes that accept money but then don't relay or store the messages. Without introducing some notion of node reputation and prefering long term nodes, I don't see a good way to solve that right now. An idea is to abandon IP for this project and build the entire P2P network on top of Tor hidden services. This means that a node can maintain a persistent, long term identity even if the underlying IP addresses change, brand new nodes could be tested by their peers to ensure they're actually performing the services they claim they will, and the amount of traffic (and thus money) trusted to them gradually ramped up.
Based on reading the paper I have a few comments. I don't know if the design is set in stone by now or if you're still open to modifications.
The streams construction is very clever and I think it could work well. One question is what if I have an old and widely propagated address in a root stream, and eventually it gets overloaded? Some people have to move. But nobody wants to give up their old and well known address.
For thin client nodes, they can't tune into the torrent of all messages (they may be on mobiles). You could consider a Bloom filter construction for them as we are doing for Bitcoin, so nodes can express interest in some probabilistic subset of all messages. Because Bloom filters can be merged, nodes could merge together the filters set by connected clients and provide the superset of them to other connected nodes. As you get closer to the "core" of the network all bits would be set and it'd revert to pure broadcast, but this construction also allows nodes to adapt how much traffic they receive according to how much instantaneous bandwidth they have available (eg, if run on an end user computer they can throttle back their relaying whilst the user is streaming a movie by adjusting the filter FP rate).
Spammers routinely use hacked computers to send spam, so they aren't using their own CPU to calculate PoWs. This doesn't affect Bitcoin much because PoW calculations don't have to be done by users of the network, so specialized equipment can be used to outrun botnets, but in a PoW-to-play scheme you can't rely on users having much CPU. This is especially true if you want to support mobile users, which you do. As you note, your other mitigations are thwarted by crawlers that look for addresses, which is one of the most common ways to gather email addresses today. So I find the anti-spam provisions unconvincing. The magic 2 day storage window is also questionable, many users don't check their mail every two days.
An alternative approach is to link Bitmessage and Bitcoin together. A few approaches present themselves. Nodes on the Bitmessage network, which would hopefully stick around for the long term, could establish micropayment channels between each other. Micropayment channels aren't operational today because we need to re-enable transaction replacement in the main Bitcoin network, but you could certainly experiment with this approach on the testnet. To send a message then, you establish some connections to long-lived peers, send a few millicents to to each node and then submit your message. Nodes relay some of the money you sent along their broadcast paths until eventually it's exhausted. In this way, nodes are incentivized to be online all the time (and possibly store the messages for longer), and message propagation eventually stops due to either flooding the network completely or (in a very large network) exhausting the micropayments.
This means legitimate users can outbid spammers who are flooding the network. Given messages arriving from many nodes and a limited broadcast/storage capacity, nodes would prioritize messages for broadcast by the amount of money provided, and the money would ripple through the network further incentivizing nodes to prioritize the legit messages above those of the spammers.
Bitcoin and PoWs are complementary - you could allow Bitmessage-specific PoWs to start with as a way to bootstrap the network in the early days and simplify on-boarding of new users, but also support Bitcoin micropayment channels in parallel so if/when spammers arrive that have lots of CPU users can smoothly migrate to the other solution.
One issue with this is bogus nodes that accept money but then don't relay or store the messages. Without introducing some notion of node reputation and prefering long term nodes, I don't see a good way to solve that right now. An idea is to abandon IP for this project and build the entire P2P network on top of Tor hidden services. This means that a node can maintain a persistent, long term identity even if the underlying IP addresses change, brand new nodes could be tested by their peers to ensure they're actually performing the services they claim they will, and the amount of traffic (and thus money) trusted to them gradually ramped up.
November 29, 2012, 04:59:32 AM
Interesting ... are there any live test nodes up yet?
Yes - you can send a message to BM-2nnaRUg6eCsskHHueKjWf6m5sHmhW7ChBSs , which is an address listed on http://bitmessage.org . Yesterday I sent a message there and got a reply
November 29, 2012, 12:32:12 AM
Very interesting project and white paper!
November 29, 2012, 12:05:19 AM
Did someone say backdoor?
November 28, 2012, 11:48:26 PM
Cool project! 
November 28, 2012, 07:20:30 PM
Interesting ... are there any live test nodes up yet?
November 28, 2012, 02:39:44 PM
Very interesting!
I read through the whitepaper quickly and thus this probably is a silly question, but is it not easy to associate a certain public key, which acts as a sender's address if I understand correctly, with a certain IP by listening to broadcasted messages long enough?
I read through the whitepaper quickly and thus this probably is a silly question, but is it not easy to associate a certain public key, which acts as a sender's address if I understand correctly, with a certain IP by listening to broadcasted messages long enough?
That's an excellent question. Public keys are broadcast throughout a Bitmessage stream in the same way that Bitcoin transactions are broadcast throughout the Bitcoin network. In the same way that it is incredibly difficult to tell where a Bitcoin transaction originates, it is difficult to tell where a public key originates. If a particularly paranoid person thinks that the government, or whoever, is watching his particular Internet connection, he can take it a step further by distributing his public key encrypted within another message as described in the 'Passive Operating Mode' section of the whitepaper.
November 28, 2012, 02:13:57 PM
Very interesting!
I read through the whitepaper quickly and thus this probably is a silly question, but is it not easy to associate a certain public key, which acts as a sender's address if I understand correctly, with a certain IP by listening to broadcasted messages long enough?
I read through the whitepaper quickly and thus this probably is a silly question, but is it not easy to associate a certain public key, which acts as a sender's address if I understand correctly, with a certain IP by listening to broadcasted messages long enough?
November 28, 2012, 01:13:37 PM
Announcing Bitmessage!
https://Bitmessage.org
Bitmessage is a P2P communications protocol which is used to send encrypted messages to another person or to many subscribers. It is decentralized and trustless, meaning that you need-not inherently trust any entities, like root certificate authorities. It also aims to hide "non-content" data, like the sender and receiver of messages, from passive eavesdroppers.
Here is the whitepaper!
The program is in Beta so feedback is appreciated.
https://Bitmessage.org
Bitmessage is a P2P communications protocol which is used to send encrypted messages to another person or to many subscribers. It is decentralized and trustless, meaning that you need-not inherently trust any entities, like root certificate authorities. It also aims to hide "non-content" data, like the sender and receiver of messages, from passive eavesdroppers.
Here is the whitepaper!
The program is in Beta so feedback is appreciated.
Jump to: