[ANNOUNCE] Bitmessage - P2P Messaging system based partially on Bitcoin

[Atheros]

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.

[1714120101]

1714120101

[1714120101]

1714120101

[1714120101]

1714120101

[1714120101]

1714120101

[1714120101]

1714120101

[1714120101]

1714120101

[ffcitatos]

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?

[Atheros]

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?

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.

[marcus_of_augustus]

Interesting ... are there any live test nodes up yet?

[HostFat]

Cool project!

[🏰 TradeFortress 🏰]

Did someone say backdoor?

[01BTC10]

Very interesting project and white paper!

[ffcitatos]

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

[Mike Hearn]

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.

[caffeinewriter]

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.

[caffeinewriter]

The UI is actually quite gorgeous!

[uncaer9]

Great idea. If you implement discussion boards it may become even more popular than Freenet-Frost.
You can send message to me - BM-2neVjntfgA38WbRufTFoooUrtRpGeNATJ1m

[marcus_of_augustus]

Did someone say backdoor?

How do you mean?

[caffeinewriter]

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.

[ffcitatos]

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.

+1 on the from address problem

[caffeinewriter]

Also I'd like to see the ability to use proxies, which would circumvent my problem I'm having with ports.

[HostFat]

I would like to have something like this on smartphones

[caffeinewriter]

I would like to have something like this on smartphones

Agreed. Also, I'd like to see this be more cross-platform, and a changelog. (Mac, Linux, etc.)

[slothbag]

I tried it out, looks good, seems to run as advertised.

Looks like its doing some bootstrapping over port 8332 (bitcoin rpc) had me worried for a minute about backdoors.

This may be a silly question, but sending messages is a pretty simple feature and something thats been available for long time in many different p2p softwares.. Retroshare for example is p2p, using cryptographic keys for encryption and privacy.. it allows sending of messages and forums etc.

Not sure what makes BitMessage special?

[Sergio_Demian_Lerner]

Completely broken security of Bitmessage...

Check my blog post: http://bitslog.wordpress.com/2012/11/30/bitmessage-completely-broken-crypto/