OneName – Distributed Identity Database using Namecoin(onename.io)
onename.io
OneName – Distributed Identity Database using Namecoin
https://www.onename.io/
15 comments
Looks like they grabbed all one and two character names, plus a little over 600 others: http://pastebin.com/gnLGmvXu
/u/britneyspears is my favorite.
This service, and it seems by extension namecoin, raise some questions in my mind.
It seems to me that you will very quickly run out of useful names and instead get confusingly similar names. It gives the illusion of human-readable, but its really not. Refer to xkcd 1279 for why this becomes an issue :)
The bitcoin integration is flawed; People don't have one wallet address, any wallet can generate hundreds or thousands of addresses. Remember, there is no message you can send with a bitcoin payment so what you are expected to do is create a new bitcoin address for every payment you want made out to you.
What is with the limitation of only supporting 'a-z0-9' ? Swedes and Russians would probably appreciate a much larger set of characters. Not to mention Klingons!
It seems to me that you will very quickly run out of useful names and instead get confusingly similar names. It gives the illusion of human-readable, but its really not. Refer to xkcd 1279 for why this becomes an issue :)
The bitcoin integration is flawed; People don't have one wallet address, any wallet can generate hundreds or thousands of addresses. Remember, there is no message you can send with a bitcoin payment so what you are expected to do is create a new bitcoin address for every payment you want made out to you.
What is with the limitation of only supporting 'a-z0-9' ? Swedes and Russians would probably appreciate a much larger set of characters. Not to mention Klingons!
Hey Thomas, thanks for your comments.
1) Every username system has some limitation on usernames. Look at Twitter. There are 650 million twitter users, and all of them picked usernames in the same global namespace. This demonstrates that using a global namespace is quite doable.
2) You're right, people usually have multiple Bitcoin addresses and quite a few people prefer to use different addresses for different transactions. However, the protocol is extensible and is not limited to a single address. In the future, the protocol will support a list of bitcoin addresses instead of a single address. Further, you can use a hierarchical bitcoin address and direct people to different addresses in the hierarchy. In that sense, the bitcoin address listed is just a way to identify the tree of addresses the user owns. Last, the protocol supports data to be linked to from the blockchain, so if you want, you can have a next pointer lead to an API endpoint that returns a different bitcoin address every time.
3) As far as supporting only [a-z0-9_], those are the characters that most username systems support, including twitter. Some say this is due to the fact that those are the only "word" characters. Also, using this set makes it more difficult to confuse addresses. The domain name system has similar restrictions for similar reasons. I know that international readability takes a bit of a hit, but I'm sure we'll find ways to improve the experience. We're all up for suggestions.
1) Every username system has some limitation on usernames. Look at Twitter. There are 650 million twitter users, and all of them picked usernames in the same global namespace. This demonstrates that using a global namespace is quite doable.
2) You're right, people usually have multiple Bitcoin addresses and quite a few people prefer to use different addresses for different transactions. However, the protocol is extensible and is not limited to a single address. In the future, the protocol will support a list of bitcoin addresses instead of a single address. Further, you can use a hierarchical bitcoin address and direct people to different addresses in the hierarchy. In that sense, the bitcoin address listed is just a way to identify the tree of addresses the user owns. Last, the protocol supports data to be linked to from the blockchain, so if you want, you can have a next pointer lead to an API endpoint that returns a different bitcoin address every time.
3) As far as supporting only [a-z0-9_], those are the characters that most username systems support, including twitter. Some say this is due to the fact that those are the only "word" characters. Also, using this set makes it more difficult to confuse addresses. The domain name system has similar restrictions for similar reasons. I know that international readability takes a bit of a hit, but I'm sure we'll find ways to improve the experience. We're all up for suggestions.
Don't underestimate how much work Twitter has to do with a global namespace. Brand protection complaints and negotiation, conflict resolution, allowing renames, allowing reuse of abandoned names...it's not trivial, and unlike the Internet (where every registrar deals with a piece the userbase), they centralize all that labor.
Muneeb here, one of the devs of OneName. Just wanted to let everyone know that we got way more load than we expected and had to fire up a lot of additional namecoind servers. The new servers started coming online 1-2 hours back. So if you registered between 11am and 3:30pm EST then your profile processing could be delayed by a few extra hours. Sorry for the inconvenience, but firing up 10 extra namecoind servers while keeping the current setup from not choking was a "fun" experience :D
I need my breakfast now
I need my breakfast now
I'm concerned that I get the following email after signup:
"P.S. The passphrase you wrote down earlier is the secret key that gives you access to your username and profile. We don't have a copy of this key, so if you lose it, your username will be lost forever. Just in case that happens, though, we've created a backup code for you. When combined with our own backup code, your secret key will be able to be recovered. Here it is: [redacted]"
I don't understand why the service is emailing out this key.
"P.S. The passphrase you wrote down earlier is the secret key that gives you access to your username and profile. We don't have a copy of this key, so if you lose it, your username will be lost forever. Just in case that happens, though, we've created a backup code for you. When combined with our own backup code, your secret key will be able to be recovered. Here it is: [redacted]"
I don't understand why the service is emailing out this key.
We don't have your private key, and so we have you write down a passphrase that can derive the key (sha256(passphrase)). In addition, we have a last resort mechanism to help you recover your private key if it ever gets lost. We use shamir's secret sharing to split up the secret key, and send you a share. The pk can only be reconstructed when both shares are combined. We have zero information about your pk.
Why email it to me though? If all you need to essentially recreate the private key is this tidbit you've emailed me (plaintext, available to anyone), plus the (potentially compromised) tidbit on your server... What am I missing? Shamir's secret sharing doesn't help me if you already have access to all the pieces (your email account and a hacked server).
I assume, by "they don't have it", they actually mean "they had it when you input it into their sign-up form, kept it just long enough to put it into an email, and then erased it."
Sha256 is not a suitable key derivation function. Attackers could then crack the keys pretty easily (now the keys are only as secure as the passphrases). Use something like pbkdf2/bcrypt/scrypt.
How so? SHA256, pbkdf2, bcrypt, and scrypt are all deterministic--in all cases, I can get your key if I know your secret (passphrase and salt).
Admittedly, though, using SHA256(passphrase) without a salt to derive a key makes dictionary attacks easier than the others.
Admittedly, though, using SHA256(passphrase) without a salt to derive a key makes dictionary attacks easier than the others.
Are we supposed to use the generated Bitcoin address or supply our own? I assumed supply my own, yet when the next step asks to write down the pass-phrase I'm now unsure of it's intent.
You should use your own Bitcoin address (from coinbase, blockchain.info, or Bitcoin client). We generate a default BTC address (using the same passphrase/private-key) for people who don't already have bitcoin addresses.
I didn't have a pre-existing Bitcoin address; I signed up for a OneName account mainly to claim the handle that I prefer to use online. I now have a Bitcoin address, but is it just pretend? Or what? Perplexed.
You can get the private key for the bitcoin address we created for you by calculating the sha256 of the passphrase you wrote down. We're working on improving this process and in the mean time we'll clarify further. Thanks!
I dint get one :/ just a long list of errors after submitting my email at the bottom. On of which was "Bit coin address required"
What do you mean, you generate a default address?
Where is that wallet located? Are you a wallet supplier on that website too?
Where is that wallet located? Are you a wallet supplier on that website too?
Just registered my name and I have to say I really like the whole process. It was very smooth, and I like the way it looks and the potential it has.
Is there any way this can be a truly open-source project? Right now the "protocol" is open, but if wanted to host my own front-end for me and friends then I'm out of luck.
Is there any way this can be a truly open-source project? Right now the "protocol" is open, but if wanted to host my own front-end for me and friends then I'm out of luck.
It's just a pretty front end for a namecoin blockchain explorer. You can certainly create your own or use this one:
https://dotbit.me/block_explorer/name/u/cshrem
It's more than that. It's an extremely easy to use frontend. For instance, that link you posted doesn't have any way to see the JSON form of the profile. It also doesn't do any of the fanciness you mentioned below with joining together split up profiles that you mentioned in a comment earlier. More than that, this space needs some sort of de-facto standard for the protocol, and yours is as simple as any else.
Here's the use-case I'm thinking of. I want to create an in-browser pgp-messager using pgp keys that are on the nmc blockchain. If the onename "protocol" became ubiquitous this would be more or less trivial. A simple webpage with a "username" field and a "message" field. Javascript fetches the public key listed in the profile and encrypts the message (ignoring potential issues with using javascript for encryption).
That would be awesome, and there would be a million other applications besides. The problem is "onename.io" is a central point, both for failure and attack. If others could run this same pretty frontend, then there could be third field on that page for "onename endpoint", which would default to "onename.io" but could be anything. I could have my own personal instance, my employer could run one, my ISP for my neighborhood, etc... Farther down the line it could even be something built into a browser or OS, where you can specify custom default endpoints just like you do with DNS.
I don't really have any say with what you've created, it's your thing and you do with it as you see fit. But in my opinion your "pretty front end" is the best one so far, and I think could actually have appeal outside of crypto-geek-world. You just need to open-source it :P
Here's the use-case I'm thinking of. I want to create an in-browser pgp-messager using pgp keys that are on the nmc blockchain. If the onename "protocol" became ubiquitous this would be more or less trivial. A simple webpage with a "username" field and a "message" field. Javascript fetches the public key listed in the profile and encrypts the message (ignoring potential issues with using javascript for encryption).
That would be awesome, and there would be a million other applications besides. The problem is "onename.io" is a central point, both for failure and attack. If others could run this same pretty frontend, then there could be third field on that page for "onename endpoint", which would default to "onename.io" but could be anything. I could have my own personal instance, my employer could run one, my ISP for my neighborhood, etc... Farther down the line it could even be something built into a browser or OS, where you can specify custom default endpoints just like you do with DNS.
I don't really have any say with what you've created, it's your thing and you do with it as you see fit. But in my opinion your "pretty front end" is the best one so far, and I think could actually have appeal outside of crypto-geek-world. You just need to open-source it :P
Hey, thanks for the feedback!
I love your pgp-messenger idea - you should do it!
And you're right - the pretty front end is a big component. Two things, though - 1) we're working on open sourcing the profile crawler 2) it shouldn't be that difficult to roll your own pretty front end.
I love your pgp-messenger idea - you should do it!
And you're right - the pretty front end is a big component. Two things, though - 1) we're working on open sourcing the profile crawler 2) it shouldn't be that difficult to roll your own pretty front end.
Cool, but how do I update my profile after creating it? I don't see any way to log back in again?
We're working on a profile updating tool for the typical user and should have it out in the next couple of days.
In the meantime, if you're somewhat tech savvy, you can update your profile as follows:
1) download/install Namecoin-Qt or Namecoind
2) use the OneName profile builder and grab the JSON
3) calculate your WIF formatted private key from the passphrase (just a sha256 then a conversion to base58check - you can use https://github.com/halfmoonlabs/coinkit for that)
4) import your WIF into your namecoin client (you should now see the username in your possession)
5) perform a "name update" operation with the new JSON profile data
In the meantime, if you're somewhat tech savvy, you can update your profile as follows:
1) download/install Namecoin-Qt or Namecoind
2) use the OneName profile builder and grab the JSON
3) calculate your WIF formatted private key from the passphrase (just a sha256 then a conversion to base58check - you can use https://github.com/halfmoonlabs/coinkit for that)
4) import your WIF into your namecoin client (you should now see the username in your possession)
5) perform a "name update" operation with the new JSON profile data
[deleted]
Why not use and extend the id/ [0] namespace ?
[0] https://wiki.namecoin.info/index.php?title=Identity
[0] https://wiki.namecoin.info/index.php?title=Identity
"we looked into "id/", but for various reasons decided to go with an entirely new namespace. "id/" has been subject to a lot of name squatting, and we believe that by starting anew, we can provide a better experience for users."
Source : http://www.reddit.com/r/Bitcoin/comments/201g66/onename_the_...
Source : http://www.reddit.com/r/Bitcoin/comments/201g66/onename_the_...
By namesquatting names yourself? I'm getting the "This OneName username is reserved for..." message too.
Any other crypto currency on the road? Like Dogecoins?
Yes, we want to support Dogecoin soon. One simple thing we need, though, is an icon similar to the fontawesome bitcoin icon.
You mean something like this?
http://thenounproject.com/term/dogecoin/36264/
http://thenounproject.com/term/dogecoin/36264/
I'll keep an eye on this one, thanks!
Okay, so is this just for payments, or is there a way this could serve as a way to login to different websites like Persona, oauth, or similar systems?
Do different namespaces exist? DNS at least gives a ton of different options, so if a top-level domain you like is taken, you just use .net, .org, etc.
The global namespace seems like it might get crowded really fast. How to prevent that?
Do different namespaces exist? DNS at least gives a ton of different options, so if a top-level domain you like is taken, you just use .net, .org, etc.
The global namespace seems like it might get crowded really fast. How to prevent that?
A login system is definitely on the roadmap! We just decided to focus on the initial usecase of bitcoin payments.
You're right, the global namespace very well might get crowded, but we'll see how it plays out.
You're right, the global namespace very well might get crowded, but we'll see how it plays out.
You should consider cities or regions as namespaces and not countries like tld, because as you see with Ukraine, Kosovo etc they change. Birthcity or village remains through generations. Language is also very crowded, names just arent unique.
I don't want my identity tied to my city or region. I might not want to give out my birth city, or I may simply not identify with it anymore.
Forced namespacing is just a poor solution. Users can add whatever namespaces they want to their own username if they want to, after all, it's just a string.
Forced namespacing is just a poor solution. Users can add whatever namespaces they want to their own username if they want to, after all, it's just a string.
You can always register "<myname>.net" on OneName, no? Such namespaces are artificial, you can always emulate them on a system without them.
What is the process for taking the passphrase generated on the website, to being able to import it into the Namecoin-qt client?
We need to be clearer with this so apologies for the confusion. Calculate the sha256 of the passphrase to get the namecoin private key (in hex form). Then import the pk into namecoind or namecoin-qt with importprivkey.
Thanks for the response mate, I did try this but perhaps I made a mistake with spelling.
For everyones reference however, should we include the spaces when applying the sha256, or should it be one continuous string which we hash.
eg. sha256("police helicopter apple") or sha256("policehelicopterapple")
For everyones reference however, should we include the spaces when applying the sha256, or should it be one continuous string which we hash.
eg. sha256("police helicopter apple") or sha256("policehelicopterapple")
Include the spaces. Exactly as it appeared.
Thanks for the clarification, though I'm a tiny bit confused.
Using my passphrase, I can successfully generate a sha256 and then import my bitcoin client, which then provides the same bitcoin public address as shown on my profile (I left it as the default on profile creation).
This shows that I have calculated the hash on the correct passphrase (no errors). However when importing the same key into namecoin-qt I'm getting "Invalid private key (code -5)".
Am I doing something fundamentally wrong, the key should be able to be imported into both -qt clients right? One for the ownership of the bitcoin address and the other for ownership and management of the u/name. I'm determined to get my head around this
Edit:
Ok it looks like Armory will happily accept the 64 long private key, but namecoin-qt seems to prefer the 51 long keys. Perhaps in 'wallet import format'. No error anymore, still trying to determine if its worked though.
Using my passphrase, I can successfully generate a sha256 and then import my bitcoin client, which then provides the same bitcoin public address as shown on my profile (I left it as the default on profile creation).
This shows that I have calculated the hash on the correct passphrase (no errors). However when importing the same key into namecoin-qt I'm getting "Invalid private key (code -5)".
Am I doing something fundamentally wrong, the key should be able to be imported into both -qt clients right? One for the ownership of the bitcoin address and the other for ownership and management of the u/name. I'm determined to get my head around this
Edit:
Ok it looks like Armory will happily accept the 64 long private key, but namecoin-qt seems to prefer the 51 long keys. Perhaps in 'wallet import format'. No error anymore, still trying to determine if its worked though.
Yes, when importing the private key into Namecoin-Qt, it needs to be in wallet import format. Make sure it's a Namecoin WIF, though. You might find this library helpful: https://github.com/halfmoonlabs/coinkit.
I imported the address into namecoin-qt but don't see anything under Manage Names and I don't even see a transaction? Do we need to re-index or anything after importing the private key?
Your code is leaking data into the i/ namespace - is this a bug?
No this is a feature. Big profiles (larger than 519 bytes) are chunked into multiple key-value entries in the blockchain. The "head" chunk has a next pointer to the next chunk and so on. The head chunk's key is the username, in the "u/" namespace. We didn't want to polute the u/ namespace with follow on chunks, so we just decided to go with "i/", but really the next pointer can go to any key in the KV you want.
OK, would be nice to change the pay-to address ;)
How many and which usernames have been set aside by the dev team, and how were the decisions made to offer them to select people?