@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 ...
Topic: [ANNOUNCE] Bitmessage - P2P Messaging system based partially on Bitcoin - page 24. (Read 89873 times)
February 14, 2013, 01:50:36 AM
February 14, 2013, 12:39:13 AM
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.
February 13, 2013, 11:32:00 PM
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?
February 13, 2013, 09:35:30 PM
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?
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.
February 13, 2013, 07:12:01 PM
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?
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?
February 13, 2013, 05:38:11 PM
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.
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.
February 13, 2013, 04:44:02 PM
Thank you 
February 13, 2013, 04:35:17 PM
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 (something that stop the user to try it again), because I was going to use it to make many different tests.
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
(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.
February 13, 2013, 04:26:01 PM
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 (something that stop the user to try it again), because I was going to use it to make many different tests.
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
(something that stop the user to try it again), because I was going to use it to make many different tests. February 13, 2013, 04:22:55 PM
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.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.
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.
February 13, 2013, 04:09:27 PM
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.
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.
January 16, 2013, 07:44:45 PM
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.
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]
[02:46:03]
[02:46:58]
[02:49:03]
[02:49:23]
[02:49:36]
[02:49:54]
[02:50:25]
[02:50:27]
[02:50:39]
[02:51:09]
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?
January 16, 2013, 06:01:53 PM
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.
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]
[02:46:03]
[02:46:58]
[02:49:03]
[02:49:23]
[02:49:36]
[02:49:54]
[02:50:25]
[02:50:27]
[02:50:39]
[02:51:09]
January 16, 2013, 05:37:43 PM
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.
January 16, 2013, 05:28:52 PM
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!
January 16, 2013, 05:12:26 PM
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!
January 16, 2013, 04:42:43 PM
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!
January 16, 2013, 04:34:08 PM
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.
January 16, 2013, 03:21:25 PM
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.
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.
January 16, 2013, 02:22:36 PM
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.
The message is still showing this: "Waiting on their public key. Will request it again soon."
I have the green dot.
Jump to: