rxl

Thanks! Really appreciate it.

1. The replication factor of the DHT is set to be high. 2. We'll be committed to seeding the network and will work with others to have them run nodes. 3. We will provide a full index of the DHT, so the data can be retrieved via our API as an alternative to checking the DHT (the data can be stored and mirrored anywhere, since it's hash-addressed).

Bitcoin technically has the capability to store at least 1K bytes per transaction using multi-sig outputs. 66 bytes per output * 15 possible outputs (for standard transactions) = 1K bytes. And you could do even more than that with non-standard transactions, making transactions with 3K bytes or more.

That said, you probably don't want to do this, because it contributes to blockchain bloat.

We made the decision of storing the data in a DHT because it's more efficient and you can store much more data than a few thousand bytes.

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.

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.

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.

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.

Apologies for the delay! We are trying really hard to handle the barrage of incoming requests and will get back to you shortly!

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

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.

Yes, we want to support Dogecoin soon. One simple thing we need, though, is an icon similar to the fontawesome bitcoin icon.

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.

Include the spaces. Exactly as it appeared.

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.

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!

Ok we will clarify this, thanks for the feedback.

Ah you're right, it's not really a buying guide. The comparison chart is sortable though.

Great suggestion. A system like this would also work well to:

1) increase the variability of information consumed by the community

2) combat group think (which is all too prevalent these days on HN)

3) provide a more level playing field for people who don't make an effort to abuse the voting system and exceed the front page threshold

Bitcoin, Litecoin, Feathercoin, etc. are all decentralized currencies, and this fact should give you at least one very good reason to trust them.

Ripple has been pre-mined and is not decentralized, but in fact controlled by one entity (regardless of what the creators may claim).

There is a huge difference here. Not even a comparison.

First, let me quote http://ripplescam.org/:

  But wait – you can become your own validator! [...]
  The consensus system ensures there is only one ledger – the most accepted one.
  If you run your own validator, you must connect with OpenCoin Inc servers, or you
  will be building a different ledger. In practice, it is not possible to
  “dethrone” OpenCoin Inc as you have to co-operate with OpenCoin Inc.

Second, I'll point out that while minimizing the number of validators may be attractive, it also makes the currency much more vulnerable to top-down control, via governments, corporations, etc.

Last, if you're reading this, I'd suggest that you read up a bit about Ripple on Bitcoin Forum before you make conclusions about the currency - there are a lot of interesting discussions about its viability (like this one: https://bitcointalk.org/index.php?topic=146964.0).

Ripple has several huge problems that will prevent it from gaining as much steam as other cryptocurrencies.

First, OpenCoin pre-mined the XRP's so they could hack the cryptocurrency trend and make tons of money if their currency took off.

Second, Ripple is NOT a decentralized currency, but in fact a "distributed" currency, which is actually a much bigger deal than you might think. This means it has a single point of failure, can be easily abused by the creators, and is extremely vulnerable to intervention by governments and other big players.

(You can read all about it here: http://ripplescam.org/)

Bottom line: the strength of a currency depends almost entirely on the trust in that currency, and I have no reason whatsoever to place trust in ripples. It's a wiser move to put your money in a non-scam currency, like Bitcoin or Litecoin.

This article is quite sensationalist and doesn't seem to consider the fact that every company today is in a different stage of its life cycle.

FB was founded in 2004, while Google was founded in 1998, so it's appropriate to compare today's Facebook with 2007's Google, pre-android and all.

Box was founded in 2005, salesforce: 1999, linkedin: 2001, jawbone: 1999, workday: 2005, amazon: 1994.

Note that the two oldest companies in this list are Amazon and Google, so it's no wonder that they are the ones who have expanded the most beyond their initial markets.

It's always taken a while to build a great company that competes in 2+ markets, and that hasn't changed.