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

[bytemaster]

I see no reason why BitMessage insists on addresses being a hash of the public key rather than the actual public key.  It isn't like anyone can remember or will manually type in the address.  This would allow you to get rid of the entire discovery step.

I believe this sort of hashing is helpful for spam prevention.  In a network of this type, an identifier is needed for determining whether or not a message is intended for a specific peer, so that the peer can then retrieve and decrypt it.  If a public key is used as an identifier, any peer could simply monitor the network, scrape these keys, and send out spam messages for the user to decrypt.  If a hash is used instead, not only can a peer still identify that a message is for him, but he can reject any messages that fail to decrypt properly, as a result of spam bots not knowing his public key.

With this is in mind, users still need a way of securely sharing public keys, while minimizing spam to the simplest of problems, that problem being whether or not you want to speak to someone.  I propose such a way in the Bitmask paper with regards to permission packets and identity profile messages.  Think of it as using skype, and only accepting communication from either those who have added you to their list of contacts, or vice-versa.

Exactly, this is what we are doing with Project Quixote.  Operates like skype. 

Spam is prevented by proof-of-work and reputation of sender.

[1715185735]

1715185735

[greBit]

For example, is there a reason why BM could not be implemented as a reliable-and-anonymous message channel by just building on top of a DHT such as freenet or similar? This would scale far better and we would not need to care about ACKs.

Freenet already has a mail system that does everything Bitmessage does, with stronger privacy protections.

I have attempted to use Freenet's mail... it doesn't work!

I wasn't necessarily suggesting Freenet as a solution, (I for one have developed an irrational loathing of Java), but it does serve as one example of a well reviewed body of research that could be used as a basis for the development of a BitMessage2 protocol. There are plenty of others.

[jashper]

I see no reason why BitMessage insists on addresses being a hash of the public key rather than the actual public key.  It isn't like anyone can remember or will manually type in the address.  This would allow you to get rid of the entire discovery step.

I believe this sort of hashing is helpful for spam prevention.  In a network of this type, an identifier is needed for determining whether or not a message is intended for a specific peer, so that the peer can then retrieve and decrypt it.  If a public key is used as an identifier, any peer could simply monitor the network, scrape these keys, and send out spam messages for the user to decrypt.  If a hash is used instead, not only can a peer still identify that a message is for him, but he can reject any messages that fail to decrypt properly, as a result of spam bots not knowing his public key.

With this is in mind, users still need a way of securely sharing public keys, while minimizing spam to the simplest of problems, that problem being whether or not you want to speak to someone.  I propose such a way in the Bitmask paper with regards to permission packets and identity profile messages.  Think of it as using skype, and only accepting communication from either those who have added you to their list of contacts, or vice-versa.

Exactly, this is what we are doing with Project Quixote.  Operates like skype.  

Spam is prevented by proof-of-work and reputation of sender.

How do you end up associating a person's user name in the network with a particular public key, without other peers attempting to also claim ownership of the same user name?

[greBit]

How do you end up associating a person's user name in the network with a particular public key, without other peers attempting to also claim ownership of the same user name?

My guess is that this will be done via some namecoin alternative - BitName/BitDNS - https://bitcointalk.org/index.php?topic=250612.0

[jgarzik]

Exactly, this is what we are doing with Project Quixote.  Operates like skype. 

Spam is prevented by proof-of-work and reputation of sender.

Yawn   Try fidelity bonds and sacrifices.

[nimda]

For example, is there a reason why BM could not be implemented as a reliable-and-anonymous message channel by just building on top of a DHT such as freenet or similar? This would scale far better and we would not need to care about ACKs.

Freenet already has a mail system that does everything Bitmessage does, with stronger privacy protections.

Yes, and I2P has Bote, etc. Problems:

They are much heavier software with slower startup times and higher network load
No one-click setup
Java
Not specifically marketed as secure email

[greBit]

Yes, and I2P has Bote, etc. Problems:

They are much heavier software with slower startup times and higher network load
No one-click setup
Java
Not specifically marketed as secure email

Bote?

Leaving implementation details aside, the 10+ years of research solving an extremely similar problem to Bitmessage is worth a cursory glance. Could their protocols not influence the design of BM?

[nimda]

Yes, and I2P has Bote, etc. Problems:

They are much heavier software with slower startup times and higher network load
No one-click setup
Java
Not specifically marketed as secure email

Bote?

Leaving implementation details aside, the 10+ years of research solving an extremely similar problem to Bitmessage is worth a cursory glance. Could their protocols not influence the design of BM?

Certainly, but I think their lack of adoption is part of the problem Bitmessage tries to solve. It's already possible to reproduce Bitmessage's functionality by sending GPG encrypted anonymous emails over Tor, but almost nobody does.

Bote: https://en.wikipedia.org/wiki/I2P#E-mail

[greBit]

Certainly, but I think their lack of adoption is part of the problem Bitmessage tries to solve. It's already possible to reproduce Bitmessage's functionality by sending GPG encrypted anonymous emails over Tor, but almost nobody does.

Bote: https://en.wikipedia.org/wiki/I2P#E-mail

Yeah of course.

My argument is that like encryption, designing an anonymizing P2P protocol is hard to do correctly. We see that BM has a pretty large attack surface and has scalability issues.

It would be nice if the development of BitMessage2 could follow a more scientific approach. Build upon previous and well tested work instead of pulling a scheme out of thin air.

[K1773R]

For example, is there a reason why BM could not be implemented as a reliable-and-anonymous message channel by just building on top of a DHT such as freenet or similar? This would scale far better and we would not need to care about ACKs.

Freenet already has a mail system that does everything Bitmessage does, with stronger privacy protections.

Yes, and I2P has Bote, etc. Problems:

They are much heavier software with slower startup times and higher network load
No one-click setup
Java
Not specifically marketed as secure email

aslong you dont use orcale's java and use openjdk/openjre, java isnt a problem on the privacy/security way. tough i agree it isnt really suitable due to performance, it should be C

[HostFat]

0.4.0

Raised default demanded difficulty from 1 to 2 for new addresses
Added v4 addresses: pubkeys are now encrypted and tagged in the inventory
Use locks when accessing dictionary inventory
Refactored the way inv and addr messages are shared
Give user feedback when disk is full
Added chan true/false to listAddresses results
When replying using chan address, send to whole chan not just sender
Refactored of the way PyBitmessage looks for interesting new objects in large inv messages from peers
Show inventory lookup rate on Network Status tab
Added SqlBulkExecute class so we can update inventory with only one commit
Updated Russian translations
Move duplicated SQL code into helper
Allow specification of alternate settings dir via BITMESSAGE_HOME environment variable
Removed use of gevent. Removed class_bgWorker.py
Added Sip and PyQt to includes in build_osx.py
Show number of each message type processed in the API command clientStatus
Use fast PoW unless we're explicitly a frozen (binary) version of the code
Enable user-set localization in settings
Fix Archlinux package creation
Fallback to language only localization when region doesn't match
Fixed brew install instructions
Added German translation
Made inbox and sent messages table panels read-only
Allow inbox and sent preview panels to resize
Count RE: as a reply header, just like Re: so we don't chain Re: RE:
Fix for traceback on OSX
Added backend ability to understand shorter addresses
Convert 'API Error' to raise APIError()
Added option in settings to allow sending to a mobile device (app not yet done)
Added ability to start daemon mode when using Bitmessage as a module
Improved the way client detects locale
Added API commands: getInboxMessageIds, getSentMessageIds, listAddressBookEntries, trashSentMessageByAckData, addAddressBookEntry, deleteAddressBookEntry, listAddresses2, listSubscriptions
Set a maximum frequency for playing sounds
Show Invalid Method error in same format as other API errors
Update status of separate broadcasts separately even if the sent data is identical
Added Namecoin integration
Internally distinguish peers by IP and port
Inbox message retrieval API functions now also returns read status

[genjix]

Did you guys see http://flowingmail.com/ yet? I reached out to the devs & think their project can go far.

[nimda]

Did you guys see http://flowingmail.com/ yet? I reached out to the devs & think their project can go far.

Seems to me like there'd be a loss of anonymity.

[favdesu]

Did you guys see http://flowingmail.com/ yet? I reached out to the devs & think their project can go far.

I'd rather go with mailpile.is which is already funded and in active development

[Peter R]

I'm just learning about BitMessage now.  I love the concept of BitMessage: as described in the introduction to the white paper, it fills a very important need.  But, after reading Sections 3 & 4, the "proof of work" for spam mitigation seems wasteful (and annoying to wait 4 min for delivery).  We're asking everyone to waste money (work) to prove they aren't spamming, when perhaps we could just ask them for money (bitcoin) directly to offset the costs of running the service.  Then they can spam all they want because it is profitable to process/store their transmissions.  (EDIT: I see this idea has been discussed earlier in the thread).

I don't have a solution    but there must be some way to create a *free market* for private communication transmission/storage/delivery using bitcoins.

EDIT 2: I'm imagining that Alice broadcasts her message so that it is packaged with a little bitcoin treat that somehow gets unlocked when Bradley downloads it, and the bitcoins get paid out in some fair but competitive way to the nodes that helped out.  

[nimda]

I'm just learning about BitMessage now.  I love the concept of BitMessage: as described in the introduction to the white paper, it fills a very important need.  But, after reading Sections 3 & 4, the "proof of work" for spam mitigation seems wasteful (and annoying to wait 4 min for delivery).  We're asking everyone to waste money (work) to prove they aren't spamming, when perhaps we could just ask them for money (bitcoin) directly to offset the costs of running the service.  Then they can spam all they want because it is profitable to process/store their transmissions.  (EDIT: I see this idea has been discussed earlier in the thread).

I don't have a solution    but there must be some way to create a *free market* for private communication transmission/storage/delivery using bitcoins.

EDIT 2: I'm imagining that Alice broadcasts her message so that it is packaged with a little bitcoin treat that somehow gets unlocked when Bradley downloads it, and the bitcoins get paid out in some fair but competitive way to the nodes that helped out.  

This is a FAQ (or if it's not an asked question, it at least comes up frequently).

Proof-of-work is NOT for spam mitigation. Just like with email, spam catching is up to the client. This is why I prefer to integrate with Thunderbird.

Proof-of-work is for flood prevention. It makes it costly to try to DoS the network by sending lots of messages.

[dadach]

Note: If you loose your password, your account is lost!

LOSE not LOOSE

[bitcoin-world.de]

Have tested this app. Its very very good. I will bring it to the german community nearer.

[jago25_98]

just segfaults for me...

Oh great BitMessage overlords, can a poor non-programmer get a lowly Windows binary of bmgen?

(I have python but I don't know how to find and install "highlevelcrypto" for the error "ImportError: No module named highlevelcrypto".  I know enough to install python but not enough to import/install libraries.)

Edit:  Nevermind!  I just downloaded the bitmessage source code and put bmgen.py into the folder that had highlevelcrypto.py in it.  All worked wonderfully!  I know it's not the most elegant solution, but by God it spits out a vanity address, and I'm happy.  Now I just need to figure out how to import custom addresses....

Edit 2:  Nevermind again, I just opened keys.dat in a text editor and saw that it was pretty obvious how to import addresses.  I'm all set now.  Awesome.  Thank you everybody involved!!!!!

Edit 3:  It seems to do addresses that start with BM-2 or BM-2D really really fast, and everything else is super slow.  Is that some random anomaly on my part?

[Vani]

Great program. Use it for almost 2 weeks now!