Pages:
Author

Topic: [ANNOUNCE] Bitmessage - P2P Messaging system based partially on Bitcoin - page 22. (Read 89873 times)

sr. member
Activity: 249
Merit: 251
A Chrome addon? The article Javascript Cryptography Considered Harmful is still on my mind.

A web-based Bitmessage client should never exist. Just like that article talks about, there is no way to securely deliver the code. If HTTPS is secure and trustworthy then Bitmessage need-not exist. I argue that it isn't.
full member
Activity: 160
Merit: 100
A Chrome addon? The article Javascript Cryptography Considered Harmful is still on my mind.
staff
Activity: 4270
Merit: 1209
I support freedom of choice
Now I hope that someone will port it as Chrome and Android app Smiley
sr. member
Activity: 249
Merit: 251
staff
Activity: 4270
Merit: 1209
I support freedom of choice
sr. member
Activity: 249
Merit: 251
Any chance of getting Bitmessage to support file attachments? This would make it more like full-fledged email rather than "email lite" as it is now.


Yes, I/We just need to research and decide on an encoding format for messages. MIME would be good except that whatever format we use should use 8 bit bytes rather than 7 bit bytes since we have all 8 to work with (unlike what SMTP has).
staff
Activity: 4270
Merit: 1209
I support freedom of choice
You can still upload files on filehosting and sharing the link, I think it's better than moving them on the entire Bitmessage network.
Anyway, you can use base32.
full member
Activity: 122
Merit: 100
Any chance of getting Bitmessage to support file attachments? This would make it more like full-fledged email rather than "email lite" as it is now.
staff
Activity: 4270
Merit: 1209
I support freedom of choice
0.2.6

  • New Feature: Pseudo-mailing-lists (available by right-clicking one of your addresses)
  • New Feature: Portable Mode (available in the settings)
  • Added missing context menu on the blacklist tab

Faster than the dev Grin
legendary
Activity: 1036
Merit: 1000
DARKNETMARKETS.COM
That's sounds insane  Shocked
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.
full member
Activity: 160
Merit: 100
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.
legendary
Activity: 1036
Merit: 1000
DARKNETMARKETS.COM
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  Huh
legendary
Activity: 1708
Merit: 1020
[...] 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.
sr. member
Activity: 249
Merit: 251
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.
legendary
Activity: 3920
Merit: 2349
Eadem mutata resurgo
Quote
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.

Quote
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.
legendary
Activity: 2114
Merit: 1031
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?
sr. member
Activity: 249
Merit: 251
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.
legendary
Activity: 2114
Merit: 1031
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://bitcointalksearch.org/topic/encryptdecrypt-arbitrary-text-using-bitcoin-keys-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)...
legendary
Activity: 3920
Merit: 2349
Eadem mutata resurgo
Quote
[...]


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.
legendary
Activity: 1708
Merit: 1020
Quote
[...]


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)
Pages:
Jump to: