Adding namecoin "id/" namespace support into bitmessage

[domob]

was waiting for any bug reports and minor fixes before doing anything else on it.. but we could have ID Tab, with all that too

I think that would be great - but since I personally prefer the command-line to a lot of UIs, you will probably have to discuss that with others who plan on using that feature.

[moa]

excellent work .. we can add bitmessage field to configure names part of qt (to make it very easy)

That would be great! What about even adding a whole set of possible options for identities (as described on the wiki)? Like real name, email address, bitmessage, bitcoin address, namecoin address, PGP fingerprint?

was waiting for any bug reports and minor fixes before doing anything else on it.. but we could have ID Tab, with all that too

I also propose a new field "nmcsig" as I think it will become more widely used to put a self-signed message/hash, etc into the value to prove ownership of the nmc-address where the name/value pair are stored.

e.g.

Code: Select all

id/somename {"nmcsig":"HDKmzKf1vY7XDnmOYy6Wx0HDQVZMjHpftv/PnFDXnDjvVSm8PXX++BMCfHZK1OitECSXGA7c7MQ4Elkujmuh+eA="}

There is an example of this method being used here; (feel free to imitate;))

http://opentransactions.org/forum/index ... sg40#msg40

http://explorer.dot-bit.org/n/91499

Why do this?
Since namecoin allows anyone to send a name-value to any other nmc address, anyone viewing the blockchain can never be sure if the owner of the nmc key actually put that name-value pair at that address. However, if the name is self-signed and stored as part of the value by that nmc priv key then it is much more likely that that name should be at that address with those values.
I suppose there could also be a "selfsigname" field that is specifically the nmcsig of the "name" part of the "id/name" supposedly signed by the address it resides at and not some other generic nmc signed message.

[domob]

Why do this?
Since namecoin allows anyone to send a name-value to any other nmc address, anyone viewing the blockchain can never be sure if the owner of the nmc key actually put that name-value pair at that address. However, if the name is self-signed and stored as part of the value by that nmc priv key then it is much more likely that that name should be at that address with those values.
I suppose there could also be a "selfsigname" field that is specifically the nmcsig of the "name" part of the "id/name" supposedly signed by the address it resides at and not some other generic nmc signed message.

Sounds like a good idea to me - if there's some kind of consensus formed as to this field, I can definitely implement it in some way into my patch.

EDIT: Thinking about it - why is the situation you try to avoid different from just someone registering a name and not sending it around at all? If you were not yet a namecoin user, I can easily register "id/moa" with a rogue BM address to fake users into sending messages for you to me if they don't check that you indeed have a BM-enabled NMC identity. How is the situation you describe different from this one?

[moa]

Why do this?
Since namecoin allows anyone to send a name-value to any other nmc address, anyone viewing the blockchain can never be sure if the owner of the nmc key actually put that name-value pair at that address. However, if the name is self-signed and stored as part of the value by that nmc priv key then it is much more likely that that name should be at that address with those values.
I suppose there could also be a "selfsigname" field that is specifically the nmcsig of the "name" part of the "id/name" supposedly signed by the address it resides at and not some other generic nmc signed message.

Sounds like a good idea to me - if there's some kind of consensus formed as to this field, I can definitely implement it in some way into my patch.

EDIT: Thinking about it - why is the situation you try to avoid different from just someone registering a name and not sending it around at all? If you were not yet a namecoin user, I can easily register "id/moa" with a rogue BM address to fake users into sending messages for you to me if they don't check that you indeed have a BM-enabled NMC identity. How is the situation you describe different from this one?

Yeah, you're right .... but the particular case that bought it up was if the name expired (say by accident memory lapse, owner drops into a coma, etc) and then an attacker grabbed the name and sent it back to original owner's nmc address but this time with a BM-attacker, or fingerprint:hacker, value etc. Having the nmcsig(value) in there prevents this happening ... actually you make me think of a good point here. I should have said nmcsig(value) NOT nmcsig(name) ... I only said this because the case I was looking at we use for the name a secured hash, i.e. a value.

So for example if you had

Code: Select all

id/somename {"bitmessage":"BM-goodguysbmaddress","selfsigbm":"NMCSIG(BM-goodguysbmaddress)"}

in the blockchain you would know that the name hadn't expired at some point and been sent back to that NMCaddress with a rogue BM-address value.

However, as you say there already would also need to be another communication channel for id/daniel to say "hey you can use id/daniel to bitmessage me now" for it to work as it is. Whereas in this case the initial communication would have been "hey you can use id/daniel at NMCAddress to bitmessage me now"

Hmmmm, but I'll have to toss this one around some more also I think. Needs more eyes on it

[phelix]

spin off topic: http://nf.bit/viewtopic.php?t=1027 Self Signing as Security Feature in Case of Expiry

[phelix]

Thread on the bitmessage forum: https://bitmessage.org/forum/index.php/ ... 563.0.html

Should I send the bounty to your normal address? Otherwise please pm.

[domob]

Thread on the bitmessage forum: https://bitmessage.org/forum/index.php/ ... 563.0.html

Should I send the bounty to your normal address? Otherwise please pm.

I'll send you one with PM when I get back to my wallet to generate it. Thanks!

Do you (or someone else) have more suggestions for what the code should also do? If not, I'll try to figure out how to "officially" submit a push request into the Bitmessage repository and see whether this gets done. (Atheros seems interested judging from the thread at the bitmessage forum.)

[phelix]

Thread on the bitmessage forum: https://bitmessage.org/forum/index.php/ ... 563.0.html

Should I send the bounty to your normal address? Otherwise please pm.

I'll send you one with PM when I get back to my wallet to generate it. Thanks!

Bounty paid out. Thank you for the great work.

Do you (or someone else) have more suggestions for what the code should also do? If not, I'll try to figure out how to "officially" submit a push request into the Bitmessage repository and see whether this gets done. (Atheros seems interested judging from the thread at the bitmessage forum.)

If you ask me like that... be modular so it will also be possible to be used for other software, e.g. electrum desktop.

[domob]

Thread on the bitmessage forum: https://bitmessage.org/forum/index.php/ ... 563.0.html

Should I send the bounty to your normal address? Otherwise please pm.

I'll send you one with PM when I get back to my wallet to generate it. Thanks!

Bounty paid out. Thank you for the great work.

Received it, thanks!

Do you (or someone else) have more suggestions for what the code should also do? If not, I'll try to figure out how to "officially" submit a push request into the Bitmessage repository and see whether this gets done. (Atheros seems interested judging from the thread at the bitmessage forum.)

If you ask me like that... be modular so it will also be possible to be used for other software, e.g. electrum desktop.

I think the basic interfacing code to do RPC calls is (somewhat) reusable. Do you think it would make sense to abstract it even more so that one file can be copied to a new project without any changes? This would basically just mean removing the BM specific configuration routines and putting them into another file. I don't think this should be done, though, because I'm not sure whether the BM people like it to have even two new files in their code just for Namecoin integration.

Do you think it would indeed be a good idea to try integrating that into Electrum? I can try that out - although I've so far not yet used it at all.

[moa]

I think the basic interfacing code to do RPC calls is (somewhat) reusable. Do you think it would make sense to abstract it even more so that one file can be copied to a new project without any changes? This would basically just mean removing the BM specific configuration routines and putting them into another file.
Do you think it would indeed be a good idea to try integrating that into Electrum? I can try that out - although I've so far not yet used it at all.

It does raise the interesting point to ponder what a generic namecoin-enabler plug-in/add-on might look like ... e.g. I see people are configuring Thunderbird to use BM-protocol http://www.youtube.com/watch?v=ppk_zzjZRIgso a namecoin id/ enabled Thunderbird or any email client and once you start down that path ... then the possibilities seem to increase considerably for using this technique for authenticated messaging of many kinds