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

[HostFat]

By portable do you mean, for example, be able to run it on a USB flash drive and take the keys and messages with you? This would be quite easy actually.

Yes, but would like also that it works on systems like google drive/dropbox/wuala.
So that I can just sync the google drive/dropbox/wuala folder from another computer and it will instantly work.
By the way, I think that making it working from an USB flash drive will be enough

[Atheros]

By portable do you mean, for example, be able to run it on a USB flash drive and take the keys and messages with you? This would be quite easy actually.

Yes, but would like also that it works on systems like google drive/dropbox/wuala.
So that I can just sync the google drive/dropbox/wuala folder from another computer and it will instantly work.

Building support for those programs into Bitmessage would be out of the scope of the project. You might consider using deterministic addresses and using the same passphrase on two computers thus creating the same addresses. You would receive messages on both computers and could reply using either one. They would have separate 'sent' folders but this solution would be secure and doesn't use a 3rd party service. The only caveat is that each computer should go online at least once every two days to receive messages or else only the one computer that is online will get them (this may be perfectly acceptable- for example if you go on vacation then it does not matter that your office computer is not receiving messages).

[HostFat]

I explained it wrong, I think that the USB flash drive will be enough.

[slothbag]

That Reddit post about BitMessage must have gained some attention.. we've gone from like 2-3 connections to like 40 overnight..

[kjlimo]

That Reddit post about BitMessage must have gained some attention.. we've gone from like 2-3 connections to like 40 overnight..

link please?  That might get some of my friends looking into it...

[slothbag]

That Reddit post about BitMessage must have gained some attention.. we've gone from like 2-3 connections to like 40 overnight..

link please?  That might get some of my friends looking into it...

There's been a few mentions.. heres one:
http://www.reddit.com/r/darknetplan/comments/18o5wg/bitmessage_decentralized_alternative_to_email/

[phelix]

Why not make it so one can use a Bitcoin address / keypair for messaging?

Bitcoin and Bitmessage keys will be interchangeable. Today I coded the key generation sections; Bitmessage will even save keys in Wallet Import Format.

However Bitmessage will use two keys- one for encryption and one for signing. Thus Bitcoin addresses (which are only a hash of a signing key) wouldn't be sufficient for Bitmessage. It seems to me that Bitmessage addresses could be turned into Bitcoin addresses but not the other way around.

This is gonna be cool.

Now you could store those Bitmessage/Bitcoin keys in a namecoin 'alias' namespace http://dot-bit.org/Namespace:Aliases and have the Bitmessenger client just send to a human-readable name from the namecoin blockchain ... voila ... end-to-end secure, autonomous look-up, authenticated, human-readable messaging system.

That is a good idea isn't it!

Unfortunately, I asked a 'hero member' (I forget who) on IRC about this possibility and why no one was doing it with Bitcoin addresses yet and he said that Namecoin is "more or less dead now. pretty much abandoned by its creators... it's been sort of spammed to death because they massively lowered the cost to get names, so there is effectively no anti-dos in it anymore."

Though that may be gone, the very notion that it could have and would have worked means that I personally believe that someone someday will come up with a way to link human-meaningful names to non-human-meaningful data (like Bitcoin and Bitmessage addresses). Then we will have solved Zooko's triangle!

please note that namecoin has solved this problem like two years ago

I am only now realizing the implications of your project. It's like you took two steps at once. I posted about the first step here: https://bitcointalk.org/index.php?topic=145098

[HostFat]

Another cool thing can be a different icon (with numbers) on the taskbar if there are some new unread messages.

[marcus_of_augustus]

Why not make it so one can use a Bitcoin address / keypair for messaging?

Bitcoin and Bitmessage keys will be interchangeable. Today I coded the key generation sections; Bitmessage will even save keys in Wallet Import Format.

However Bitmessage will use two keys- one for encryption and one for signing. Thus Bitcoin addresses (which are only a hash of a signing key) wouldn't be sufficient for Bitmessage. It seems to me that Bitmessage addresses could be turned into Bitcoin addresses but not the other way around.

This is gonna be cool.

Now you could store those Bitmessage/Bitcoin keys in a namecoin 'alias' namespace http://dot-bit.org/Namespace:Aliases and have the Bitmessenger client just send to a human-readable name from the namecoin blockchain ... voila ... end-to-end secure, autonomous look-up, authenticated, human-readable messaging system.

That is a good idea isn't it!

Unfortunately, I asked a 'hero member' (I forget who) on IRC about this possibility and why no one was doing it with Bitcoin addresses yet and he said that Namecoin is "more or less dead now. pretty much abandoned by its creators... it's been sort of spammed to death because they massively lowered the cost to get names, so there is effectively no anti-dos in it anymore."

Though that may be gone, the very notion that it could have and would have worked means that I personally believe that someone someday will come up with a way to link human-meaningful names to non-human-meaningful data (like Bitcoin and Bitmessage addresses). Then we will have solved Zooko's triangle!

please note that namecoin has solved this problem like two years ago

I am only now realizing the implications of your project. It's like you took two steps at once. I posted about the first step here: https://bitcointalk.org/index.php?topic=145098

Phelix: doublec and I were discussing this (over bitmessage as it happens) ... we could store bitmessage address in its own namespace in namecoin blockchain ... e.g. "bm/" namespace

$ namecoind name_new bm/phelix

$ namecoind name_update bm/phelix 'bm:oonwienfwna1244nfon aIKNneid'

or similar. Then we need a small piece of code, or an extension to bitmessage that looks up names from contact list inside bitmessage and pulls out the relevant BM-address from the namecoin blockchain.

I think the really cool part about this is you could have the code automatically generate new BM-addresses as often as you like and update the namecoin record at the same time. In this way, you can have your BM-address changing regularly for security, as suggested by BM author, but keep the name, i.e. bitmessage email address secured by namecoin blockchain in human readable form. If you need higher security and change addresses often you will incur more nmc fees and vice versa less security, less fees; you will pay for the security you get, in nmc fees.

Namecoin and bitmessage will work well together since they both solve different elements of resource allocation.

[phelix]

[...]

Phelix: doublec and I were discussing this (over bitmessage as it happens) ... we could store bitmessage address in its own namespace in namecoin blockchain ... e.g. "bm/" namespace

$ namecoind name_new bm/phelix

$ namecoind name_update bm/phelix 'bm:oonwienfwna1244nfon aIKNneid'

or similar. Then we need a small piece of code, or an extension to bitmessage that looks up names from contact list inside bitmessage and pulls out the relevant BM-address from the namecoin blockchain.

I think the really cool part about this is you could have the code automatically generate new BM-addresses as often as you like and update the namecoin record at the same time. In this way, you can have your BM-address changing regularly for security, as suggested by BM author, but keep the name, i.e. bitmessage email address secured by namecoin blockchain in human readable form. If you need higher security and change addresses often you will incur more nmc fees and vice versa less security, less fees; you will pay for the security you get, in nmc fees.

Namecoin and bitmessage will work well together since they both solve different elements of resource allocation.

Hmm I was thinking about directly using the namecoin keys a name is attached to (== bitcoin key) as encryption keys... (edit: note that this is a piece of cake with Atheros' libs)

[marcus_of_augustus]

[...]

Phelix: doublec and I were discussing this (over bitmessage as it happens) ... we could store bitmessage address in its own namespace in namecoin blockchain ... e.g. "bm/" namespace

$ namecoind name_new bm/phelix

$ namecoind name_update bm/phelix 'bm:oonwienfwna1244nfon aIKNneid'

or similar. Then we need a small piece of code, or an extension to bitmessage that looks up names from contact list inside bitmessage and pulls out the relevant BM-address from the namecoin blockchain.

I think the really cool part about this is you could have the code automatically generate new BM-addresses as often as you like and update the namecoin record at the same time. In this way, you can have your BM-address changing regularly for security, as suggested by BM author, but keep the name, i.e. bitmessage email address secured by namecoin blockchain in human readable form. If you need higher security and change addresses often you will incur more nmc fees and vice versa less security, less fees; you will pay for the security you get, in nmc fees.

Namecoin and bitmessage will work well together since they both solve different elements of resource allocation.

Hmm I was thinking about directly using the namecoin keys a name is attached to (== bitcoin key) as encryption keys... (edit: note that this is a piece of cake with Atheros' libs)

Maybe. Although it doesn't gain you much and makes things more complicated, e.g. extracting the priv. key from wallet ... and then particularly changing encryption keys regularly. Also I'm not intimate with how bitmessage works but I know Artheros is using separate keys for signing and encryption. Namecoin/bitcoin private keys should probably be kept for signing and not used for encryption as much as I've read about best practices ... icbw.

[kjlimo]

Why not make it so one can use a Bitcoin address / keypair for messaging?

Bitcoin and Bitmessage keys will be interchangeable. Today I coded the key generation sections; Bitmessage will even save keys in Wallet Import Format.

However Bitmessage will use two keys- one for encryption and one for signing. Thus Bitcoin addresses (which are only a hash of a signing key) wouldn't be sufficient for Bitmessage. It seems to me that Bitmessage addresses could be turned into Bitcoin addresses but not the other way around.

This is gonna be cool.

Now you could store those Bitmessage/Bitcoin keys in a namecoin 'alias' namespace http://dot-bit.org/Namespace:Aliases and have the Bitmessenger client just send to a human-readable name from the namecoin blockchain ... voila ... end-to-end secure, autonomous look-up, authenticated, human-readable messaging system.

That is a good idea isn't it!

Unfortunately, I asked a 'hero member' (I forget who) on IRC about this possibility and why no one was doing it with Bitcoin addresses yet and he said that Namecoin is "more or less dead now. pretty much abandoned by its creators... it's been sort of spammed to death because they massively lowered the cost to get names, so there is effectively no anti-dos in it anymore."

Though that may be gone, the very notion that it could have and would have worked means that I personally believe that someone someday will come up with a way to link human-meaningful names to non-human-meaningful data (like Bitcoin and Bitmessage addresses). Then we will have solved Zooko's triangle!

please note that namecoin has solved this problem like two years ago

I am only now realizing the implications of your project. It's like you took two steps at once. I posted about the first step here: https://bitcointalk.org/index.php?topic=145098

Phelix: doublec and I were discussing this (over bitmessage as it happens) ... we could store bitmessage address in its own namespace in namecoin blockchain ... e.g. "bm/" namespace

$ namecoind name_new bm/phelix

$ namecoind name_update bm/phelix 'bm:oonwienfwna1244nfon aIKNneid'

or similar. Then we need a small piece of code, or an extension to bitmessage that looks up names from contact list inside bitmessage and pulls out the relevant BM-address from the namecoin blockchain.

I think the really cool part about this is you could have the code automatically generate new BM-addresses as often as you like and update the namecoin record at the same time. In this way, you can have your BM-address changing regularly for security, as suggested by BM author, but keep the name, i.e. bitmessage email address secured by namecoin blockchain in human readable form. If you need higher security and change addresses often you will incur more nmc fees and vice versa less security, less fees; you will pay for the security you get, in nmc fees.

Namecoin and bitmessage will work well together since they both solve different elements of resource allocation.

OK, so am I suppose to start gobbling up namecoins in anticipation of price spike due to this increase functionality or no?  haha, always trying to stay ahead of the next big thing! (que Galazy S 2 commercials)...

[Atheros]

I think the really cool part about this is you could have the code automatically generate new BM-addresses as often as you like and update the namecoin record at the same time. In this way, you can have your BM-address changing regularly for security, as suggested by BM author, but keep the name, i.e. bitmessage email address secured by namecoin blockchain in human readable form. If you need higher security and change addresses often you will incur more nmc fees and vice versa less security, less fees; you will pay for the security you get, in nmc fees.

Namecoin and bitmessage will work well together since they both solve different elements of resource allocation.

Fortunately BM- addresses don't need to be changed for any security related reason. The reason is to help streams stay a reasonable size as Bitmessage takes on new users- the new addresses will automatically be created in more available streams. We won't ever have to tell people "Hey everybody, it would be good if you replaced some of your addresses with new addresses to free up the over-full streams", rather it will be just fine to say "Feel free to create new addresses and abandon your old ones as much as you like." People will appreciate being encouraged to "waste" addresses.

Maybe. Although it doesn't gain you much and makes things more complicated, e.g. extracting the priv. key from wallet ... and then particularly changing encryption keys regularly. Also I'm not intimate with how bitmessage works but I know Artheros is using separate keys for signing and encryption. Namecoin/bitcoin private keys should probably be kept for signing and not used for encryption as much as I've read about best practices ... icbw.

Indeed. Although no one has yet thought of a vulnerability related to using the same keys for both encryption and signing, all the cryptographers would tell you it is unwise to assume no one ever will.

Concerning Namecoin, I would love to integrate it with Bitmessage; non-human-friendly names are a big complaint. But I would want it to be able to actually scale- which means getting a name would have to cost a non-trivial amount of money. And my next concern is that if 30 million people each generate an average of 4 named addresses, the Namecoin blockchain would be 4 GB of raw data- without counting the overhead.

[kjlimo]

I think the really cool part about this is you could have the code automatically generate new BM-addresses as often as you like and update the namecoin record at the same time. In this way, you can have your BM-address changing regularly for security, as suggested by BM author, but keep the name, i.e. bitmessage email address secured by namecoin blockchain in human readable form. If you need higher security and change addresses often you will incur more nmc fees and vice versa less security, less fees; you will pay for the security you get, in nmc fees.

Namecoin and bitmessage will work well together since they both solve different elements of resource allocation.

Fortunately BM- addresses don't need to be changed for any security related reason. The reason is to help streams stay a reasonable size as Bitmessage takes on new users- the new addresses will automatically be created in more available streams. We won't ever have to tell people "Hey everybody, it would be good if you replaced some of your addresses with new addresses to free up the over-full streams", rather it will be just fine to say "Feel free to create new addresses and abandon your old ones as much as you like." People will appreciate being encouraged to "waste" addresses.

Maybe. Although it doesn't gain you much and makes things more complicated, e.g. extracting the priv. key from wallet ... and then particularly changing encryption keys regularly. Also I'm not intimate with how bitmessage works but I know Artheros is using separate keys for signing and encryption. Namecoin/bitcoin private keys should probably be kept for signing and not used for encryption as much as I've read about best practices ... icbw.

Indeed. Although no one has yet thought of a vulnerability related to using the same keys for both encryption and signing, all the cryptographers would tell you it is unwise to assume no one ever will.

Concerning Namecoin, I would love to integrate it with Bitmessage; non-human-friendly names are a big complaint. But I would want it to be able to actually scale- which means getting a name would have to cost a non-trivial amount of money. And my next concern is that if 30 million people each generate an average of 4 named addresses, the Namecoin blockchain would be 4 GB of raw data- without counting the overhead.

I'm not sure how much confusion will be placed regarding the new address for each new message. 

As for worry about Namecoin because of the blockchain implications, can't computers handle a 4 GB file?  And don't we only need a few computers downloading and verifying that information for the system to work? 

Isn't it the same argument for keeping the # of transactions small to keep the blockchain small?  We should be able to work with it, otherwise, why have it exist?

[marcus_of_augustus]

Concerning Namecoin, I would love to integrate it with Bitmessage; non-human-friendly names are a big complaint. But I would want it to be able to actually scale- which means getting a name would have to cost a non-trivial amount of money. And my next concern is that if 30 million people each generate an average of 4 named addresses, the Namecoin blockchain would be 4 GB of raw data- without counting the overhead.

As for worry about Namecoin because of the blockchain implications, can't computers handle a 4 GB file?  And don't we only need a few computers downloading and verifying that information for the system to work?

As to the non-trivial name costs issue, namecoin enabled bitmessage namespaces will take on a value as soon as people want to use them.  Secondary markets in BM-names might need to be established somewhere to allow for trading already allocated names.

There are a few ways to do this, none of them implemented yet though. You could do it like electrum and have a group of semi-trusted namecoin_DNS servers that are queried for name-BM-address look-up information (in fact electrum in written in python also so maybe some code can be used directly from there and implemented in bitmessage). Other people have talked about a SPV (i.e. lite) version of namecoin client.

In the end though, as it exists right now the namecoin blockchain is relatively small, and as was the same for bitcoin at that stage if you are going to be worrying about what to do if your system becomes immensely successful in the future then that is a nice worry to have, but should stay in the future. The problems can be addressed so probably don't need to be right now. The biggest job I would concentrate on would be upgrading the existing namecoin client with useful recent mods from bitcoin ... and keeping it up to date with the near future ones which address scalability specifically, not huge tasks.

[Atheros]

I'm not sure how much confusion will be placed regarding the new address for each new message. 

As for worry about Namecoin because of the blockchain implications, can't computers handle a 4 GB file?  And don't we only need a few computers downloading and verifying that information for the system to work? 

Particular addresses don't need to be changed especially not for every message. I'm not sure what this notion came from.

It would be bigger than 4 GB. I evidently shouldn't have said that because I wasn't including any overhead. Namecoin's database is 1.1GB right now and no one even uses it.

Isn't it the same argument for keeping the # of transactions small to keep the blockchain small?  We should be able to work with it, otherwise, why have it exist?

Bitcoin exists because it can exist not because it will exist. I suppose that that is still a reasonable argument for integrating with Namecoin.

[phelix]

[...] Although no one has yet thought of a vulnerability related to using the same keys for both encryption and signing, all the cryptographers would tell you it is unwise to assume no one ever will.
[...]

This kept me thinking. Please note it is only a secondary matter of e.g. key management but not a direct security concern.

I can easily use some bitcoin public key from the blockchain to encrypt a message and broadcast it as much as i like.

[lenny_]

PyBitmessage is written for Python 2.7, not Python 3 and that is the source of the problem. I currently don't know how easy it would be to get running on both and if it would be too much work to support both in the future.

So any ideas, how make Bitmessage working on Debian GNU/Linux 

[MadSweeney]

Made PyBitmessage to work in Ubuntu Lucid several months ago.  At first I used pythonbrew to install python 2.7, but at that time it can install only up to version 2.7.2, which isn't compatible with the client. So I ended up using just virtualenv to set up python 2.7.3. Also had to install PyQt and its dependencies by hand.

[lenny_]

That's sounds insane  
Software should change to be compatible with common, well known libraries and other tools, not users messing with their system just to get one app working.