-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 05/19/2015 10:02 AM, Daniel Martà wrote:
I'm not familiar with Namecoin, but I thought I'd just point out that someone will be working on OnioNS, the onion name system, as part of the SoP in Tor. The person who will be working on it just sent an e-mail to this very list yesterday.
You two seem to be after the same "human-readable way to access .onion domain names" target as you yourself described, so there might be room for collaboration.
I'm aware of OnioNS, but haven't yet had time to thoroughly read the proposal. It's certainly on my to-do list, if nothing else for cross-pollination of ideas.
- -Jeremy
Yes, I'm here. Last year I explored Namecoin as a possible alternative DNS for Tor hidden services. I spent some time over it, but I also ran into the same problems previously mentioned above: how to link HS RSA keys to Namecoin ECDSA keys. I came up with two solutions: sign the Namecoin key with the HS key and embed that signature in the blockchain, or introduce a new blockchain that relied on the same cryptography as hidden services (RSA, Ed25519, ECDSA, etc, as long as they matched). As I mentioned in the ACM paper, it's non-trivial to build this correlation and I came to the conclusion that solutions would look more like a hack than an elegant solution. Moreover, even if the correlation could be built, it's impractical to require clients to download the whole blockchain before use, so you still have to address the issue of preventing name servers from lying.
I hope you can see that it's a difficult problem. I think Namecoin could use a solution if you come up with one, and I would be interested in hearing about it. I came to the conclusion that Namecoin would not work and wrote something different. Namecoin does many things well and I took those good design ideas, but I also changed the setup to solve many of its weaknesses. Namecoin, GNS, and OnioNS are good alternative DNSs, each with their own approach. Let's see if we can work together here, we might be able to help one another.
Jesse V.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 05/19/2015 03:31 PM, OnioNS Dev wrote:
On 05/19/2015 10:02 AM, Daniel Martà wrote:
I'm not familiar with Namecoin, but I thought I'd just point out that someone will be working on OnioNS, the onion name system, as part of the SoP in Tor. The person who will be working on it just sent an e-mail to this very list yesterday.
You two seem to be after the same "human-readable way to access .onion domain names" target as you yourself described, so there might be room for collaboration.
I'm aware of OnioNS, but haven't yet had time to thoroughly read the proposal. It's certainly on my to-do list, if nothing else for cross-pollination of ideas.
- -Jeremy
Yes, I'm here. Last year I explored Namecoin as a possible alternative DNS for Tor hidden services.
Indeed, we conversed a few times last year about that topic. I'm quite looking forward to catching up on what you've come up with since those early conversations -- more ideas are always a good thing.
I spent some time over it, but I also ran into the same problems previously mentioned above: how to link HS RSA keys to Namecoin ECDSA keys. I came up with two solutions: sign the Namecoin key with the HS key and embed that signature in the blockchain, or introduce a new blockchain that relied on the same cryptography as hidden services (RSA, Ed25519, ECDSA, etc, as long as they matched).
I hadn't actually thought of the idea of using a parallel blockchain with different signature opcodes as a solution for this particular problem. I'm not sure if you're aware, but some people have proposed creating altcoins that use quantum-resistant signatures such as Lamport signatures just in case such quantum resistance turns out to be useful, so that actually isn't as crazy an idea as some might assume.
Generally for this purpose, I think signing a Namecoin name with a HS key makes more sense than a parallel blockchain. Signing a Namecoin *address* (what I assume you mean by key) would be harder, because Bitcoin-based currencies like Namecoin intentionally don't reuse addresses, so a name will get transferred to a new address every time it is altered or renewed. Of course, then you need to deal with the ability for the .onion key to revoke a Namecoin name's authority.
As I mentioned in the ACM paper, it's non-trivial to build this correlation and I came to the conclusion that solutions would look more like a hack than an elegant solution.
Certainly not trivial, but it doesn't seem like an overly complex issue to attempt, to me. But that's why I'm asking for feedback -- I'd prefer that any solutions have holes poked in them before implementation effort is expended on them, and certainly you've expended a lot more thought on this particular topic over the past year than I have. The biggest issue I'm aware of is cross-protocol attacks... are there other pitfalls you've encountered that I should be aware of?
Moreover, even if the correlation could be built, it's impractical to require clients to download the whole blockchain before use, so you still have to address the issue of preventing name servers from lying.
SPV-based systems appear well-suited to solve that problem for most cases. HashEngineering created a Namecoin port of the BitcoinJ SPV library (it only took him a few days, I think), and used it to create an Android Namecoin client. He didn't implement parsing of the name script opcodes, but that's not a super-complicated thing to do. Almost all of the code in Namecoin is the same as Bitcoin; the differences are pretty minimal, so Bitcoin's lightweight client modes such as SPV work pretty much verbatim when applied to Namecoin. Actually getting a working product that handles the name opcodes is mainly a matter of implementation rather than any novel engineering.
SPV by itself does allow a peer to falsely claim that a name hasn't been updated after the block that the SPV proof is for. Daniel Kraft (Namecoin's chief scientist) is experimenting with a fix for that, by having miners place a merkle trie commitment of the unspent name set in each block's coinbase transaction, whose accuracy would be enforced by blockchain validation. This mode (abbreviated SPV+UNO-CBC) would ensure that name values returned over SPV are current (up to a sufficient block depth to avoid a lucky miner being able to mine a few invalid blocks with bad commitments; 12 blocks seems to be reasonable there).
I hope you can see that it's a difficult problem. I think Namecoin could use a solution if you come up with one, and I would be interested in hearing about it. I came to the conclusion that Namecoin would not work and wrote something different. Namecoin does many things well and I took those good design ideas, but I also changed the setup to solve many of its weaknesses. Namecoin, GNS, and OnioNS are good alternative DNSs, each with their own approach. Let's see if we can work together here, we might be able to help one another.
Jesse V.
Totally agree -- working together is preferable to worrying about which solution is "the right one", so to speak. These things all have their benefits and drawbacks.
Cheers, - -Jeremy
-
Jeremy Rand -
OnioNS Dev