Pages:
Author

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

staff
Activity: 4270
Merit: 1209
I support freedom of choice
@Atheros
ok, but can you explain why I can send Bitcoin to other users even if the client doesn't know my public key?
I'm not so expert about the deep works of Bitcoin ...
sr. member
Activity: 249
Merit: 251

Just tried the latest version and seems to work ok ... well done Atheros, this looks like a really promising piece of work.

Any idea when security audit might get done?

Thank you; that's very nice of you to say.

It really depends on who can audit it. I'll be spamming a cryptography mailing list tomorrow.
legendary
Activity: 3920
Merit: 2349
Eadem mutata resurgo

Just tried the latest version and seems to work ok ... well done Atheros, this looks like a really promising piece of work.

Any idea when security audit might get done?
sr. member
Activity: 249
Merit: 251
I tried other tests with a friends, and I got this status message: "Public key was requested earlier. Receiver must be offline. Will retry."
So the receiver must be online to receive the messages? I thought that it was working as Bitcoin, so both clients can connect whenever they wont and they will get the message from other nodes.
Am I wrong? Do both clients must be online to receive messages?

You need their public key from them before you can send a message. After you send or receive one message to or from them then you will always have their public key.

Alice -----pubkey request----->
         <-----------pub key--------- Bob            (after seeing the pubkey request)
Alice --------message-------->                         (after receiving the pubkey)
         <-------acknowledgement----Bob            (after receiving the message)

At this point Alice and Bob have eachother's pubkeys, AND the public as a whole has Bob's pubkey. If anyone sends a message to Bob then they won't have to do the first two steps. Their software will simply mark Bob's pubkey as "used personally" so that it never deletes it.

The two clients never need to be online at the same time but the person to whom you sent the message must go online long enough to do the POW for the pubkey message and send it out (a couple minutes).  Currently if you restart Bitmessage while this particular POW is being completed, it doesn't continue the POW gracefully. For msg and broadcast messages on the other hand, the POW task automatically continues if the user restarts Bitmessage while it is being completed.
staff
Activity: 4270
Merit: 1209
I support freedom of choice
I tried other tests with a friends, and I got this status message: "Public key was requested earlier. Receiver must be offline. Will retry."
So the receiver must be online to receive the messages? I thought that it was working as Bitcoin, so both clients can connect whenever they wont and they will get the message from other nodes.
Am I wrong? Do both clients must be online to receive messages?
sr. member
Activity: 249
Merit: 251
Of course!

I have patched the UI to disallow the send and inform the user of the problem. The code is in the master branch on Github and the version number is the same as before.
staff
Activity: 4270
Merit: 1209
I support freedom of choice
sr. member
Activity: 249
Merit: 251
Yes.
Is it impossible?
If NOT, will it possible in the near feature?
If NOT again, so you should show an error message explaining exactly that it isn't possible Smiley (something that stop the user to try it again), because I was going to use it to make many different tests.

It is currently impossible but it can probably be made possible. Bitmessage currently does not process its own messages and public key requests- it only broadcasts them to other nodes. But evidently it needs to process them so that tests like yours will succeed. I will have it fixed shortly or at least will prevent the UI from going forward with the send.
staff
Activity: 4270
Merit: 1209
I support freedom of choice
Yes.
Is it impossible?
If NOT, will it possible in the near feature?
If NOT again, so you should show an error message explaining exactly that it isn't possible Smiley (something that stop the user to try it again), because I was going to use it to make many different tests.
sr. member
Activity: 249
Merit: 251
Steps:
1) Created the first identity.
2) Created the second identity
3) Set Tor proxy on network settings
4) Restarted Bitmessage
5) Sent a message from the first identity to the second
6) The message remain on status "Sending public key request. Waiting for reply. Requested at ......"

I have already wrote the same on your forum, but I didn't get a reply.
Sorry, I hadn't checked the forum today.
Are you trying to send a message from one identity to the other on the same machine?

EDIT:I assume this is the case. Bitmessage currently does not process its own messages and public key requests- it only broadcasts them to other nodes. But evidently it needs to process them so that tests like yours will succeed. I will have it fixed shortly or at least will prevent the UI from going forward with the send.
staff
Activity: 4270
Merit: 1209
I support freedom of choice
Steps:
1) Created the first identity.
2) Created the second identity
3) Set Tor proxy on network settings
4) Restarted Bitmessage
5) Sent a message from the first identity to the second
6) The message remain on status "Sending public key request. Waiting for reply. Requested at ......"

I have already wrote the same on your forum, but I didn't get a reply.
legendary
Activity: 3920
Merit: 2349
Eadem mutata resurgo
Not sure who you were talking to on IRC but there are only total of 70,000 names registered on namecoin blockchain, hardly "spammed to death" considering the size of the namespaces available, i.e. all dictionary, names, etc in all languages .... 70,000 is drop in the ocean. You are surely misinformed.

Namecoin blockchain is tiny compared with bitcoin at present and is lightweight to run on pc, or you can make calls to the namecoin enabled DNS servers out there if you trust them. Namecoin is still working but just waiting for more applications, this will be an excellent one.

I pulled this out of my IRC log:

[02:45:51] It's 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.
[02:46:03] Which is quite sad, because it's a useful idea.
[02:46:58] There are some fundimental challenges, e.g. it's not possible today to have a lite (not full blockchain) namecoin resolver which is secure.. though its fundimentally possible to create.
[02:49:03] That's unfortunate. I was thinking about why it couldn't be (or hasn't been) used to alias Bitcoin addresses but I guess that is the reason.
[02:49:23] (it seems that all altchains get more or less technically abandoned... none of them even bother to backport critical security fixes from bitcoin)
[02:49:36] hmm
[02:49:54] Atheros2: well it could be but you currently would need a copy of the whole namecoin chain, which is small compared to bitcoin but _huge_ compared to the actual amount of namecoin usage.
[02:50:25] gmaxwell: I see.
[02:50:27] (nmc's database is about 1.1gb right now)
[02:50:39] gmaxwell: Indeed, that's pretty big.
[02:51:09] it would be bigger but it seems it's too boring to even bother attacking right now.

Yeah, gmaxwell has had some sort of vendetta going against namecoiners for a while now ... but he whinges about a lot of things, so who's to know how serious he is?
sr. member
Activity: 249
Merit: 251
Not sure who you were talking to on IRC but there are only total of 70,000 names registered on namecoin blockchain, hardly "spammed to death" considering the size of the namespaces available, i.e. all dictionary, names, etc in all languages .... 70,000 is drop in the ocean. You are surely misinformed.

Namecoin blockchain is tiny compared with bitcoin at present and is lightweight to run on pc, or you can make calls to the namecoin enabled DNS servers out there if you trust them. Namecoin is still working but just waiting for more applications, this will be an excellent one.

I pulled this out of my IRC log:

[02:45:51] It's 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.
[02:46:03] Which is quite sad, because it's a useful idea.
[02:46:58] There are some fundimental challenges, e.g. it's not possible today to have a lite (not full blockchain) namecoin resolver which is secure.. though its fundimentally possible to create.
[02:49:03] That's unfortunate. I was thinking about why it couldn't be (or hasn't been) used to alias Bitcoin addresses but I guess that is the reason.
[02:49:23] (it seems that all altchains get more or less technically abandoned... none of them even bother to backport critical security fixes from bitcoin)
[02:49:36] hmm
[02:49:54] Atheros2: well it could be but you currently would need a copy of the whole namecoin chain, which is small compared to bitcoin but _huge_ compared to the actual amount of namecoin usage.
[02:50:25] gmaxwell: I see.
[02:50:27] (nmc's database is about 1.1gb right now)
[02:50:39] gmaxwell: Indeed, that's pretty big.
[02:51:09] it would be bigger but it seems it's too boring to even bother attacking right now.
legendary
Activity: 3920
Merit: 2349
Eadem mutata resurgo
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."


Not sure who you were talking to on IRC but there are only total of 70,000 names registered on namecoin blockchain, hardly "spammed to death" considering the size of the namespaces available, i.e. all dictionary, names, etc in all languages .... 70,000 is drop in the ocean. You are surely misinformed.

Namecoin blockchain is tiny compared with bitcoin at present and is lightweight to run on pc, or you can make calls to the namecoin enabled DNS servers out there if you trust them. Namecoin is still working but just waiting for more applications, this will be an excellent one.
legendary
Activity: 2128
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!

Sounds like time to buy some namecoins!
sr. member
Activity: 249
Merit: 251
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!
legendary
Activity: 2128
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.

*mind explodes* - I assume this is awesome, but don't completely understand what will motivate me to start using it and get others to use it.  

I hope for there to be a spark that gets me using it soon!
legendary
Activity: 3920
Merit: 2349
Eadem mutata resurgo
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.
sr. member
Activity: 249
Merit: 251
I tried to send a message from an identity to another one, but both are on the client. ( I did it with the old version v0.1.4 )
The message is still showing this: "Waiting on their public key. Will request it again soon."
I have the green dot.

Sending from one identity to the other on the same client does result in strange behavior. The client doesn't process its own public key requests, public keys, or messages. It would be non-trivial to get it to do this as the part of the program that does the PoWs isn't connected to the part of the program that processes incoming messages. I'm not sure how v0.1.4 managed it. I suppose that it can be done but I would rather work on the ECC upgrade first.
staff
Activity: 4270
Merit: 1209
I support freedom of choice
I tried to send a message from an identity to another one, but both are on the client. ( I did it with the old version v0.1.4 )
The message is still showing this: "Waiting on their public key. Will request it again soon."
I have the green dot.
Pages:
Jump to: