3 ms·

> Ok. So essentially it trades trust-on-first-use with trust-on-first-registration? That is, you implicitly trust that whomever registers example.bit first, is

> Ok. So essentially it trades trust-on-first-use with trust-on-first-registration? That is, you implicitly trust that whomever registers example.bit first, is the "correct" owner? Well, that is just how names work. Google was the first to register google.com, and now you "trust" that google.com belongs to them. The blockchain is no different, except that it gives you even more reason to trust that the ownership hasn't changed. > the only room for injection is at registry time (modulus the 30 min window as discussed in the links), rather than simply mitm the connection at the time of first use? Right, and registry time isn't really an attack. It's a legitimate registry. Someone could register google.ninja right now, but you wouldn't trust it because Google has established the .com (via word of mouth and links, essentially) as the de-facto website. > And bootstrapping trust into the blockchain is basicially by trusting the ca-cert/github documentation? Sorry, not sure I understand what you're asking there.

ryan-c 12y ago
> Well, that is just how names work. Google was the first to register google.com, and now you "trust" that google.com belongs to them. You trust that google.com belongs to Google because you trust the DNS root zone to tell you who runs .com, and trust .com to tell you who runs google.com which tells you to talk to Google's servers.
- itistoday2 12y ago
  > You trust that google.com belongs to Google because you trust the DNS root zone to tell you who runs .com, and trust .com to tell you who runs google.com which tells you to talk to Google's servers. Yes, that is how DNS works. I was referring to simply the notion that Google registered google.com.
  - e12e 12y ago
    Right. But eg: .no domains are linked to a tax/org [ed:code/registration number] (or used to be, anyway). And generally you can't just go and claim to be "The Norwegian Parliament".no (or whitehouse.gov). So a registry that's strictly first come, first serve, does not work like DNS (or the CA system for that matter, despite all it's flaws).
    - itistoday2 12y ago
      That's true. The point is to secure the connection. If you wanted it, you could create a blockchain that's secured in a decentralized fashion, but upon which registrations depend on a central authority. That way you could have .edu/.gov names that are both MITM-proof and are not first-come first-serve. Maybe take a look at Ethereum or Blockstore if you want to do that.
e12e 12y ago
>> And bootstrapping trust into the blockchain is basicially by trusting the ca-cert/github documentation? >Sorry, not sure I understand what you're asking there. How do I know what the "correct" blockchain is? That I'm not dealing with a fork? Many thanks for all the various answers, I now have a much clearer picture of what dnschain is, and isn't. Some of my confusion was related to how/if dnschain is different from just running one's own dns infrastructure (and ca infrastructure, and ripe...). That data is anchored in the blockchain is all well and good, but that only gives some kind of consensus. It's also interesting to know what that consensus actually tells you. Like does it imply any kind of vetting, or just first-come, first-serve.
- itistoday2 12y ago
  > How do I know what the "correct" blockchain is? That I'm not dealing with a fork? Ah, well, my friend, you should dive deep into the world of blockchain consensus, of which much has been written on. Different blockchains use different consensus models. Namecoin and Bitcoin use the same one: proof of work via hashing. It's what prevents forks from happening (well, that and the block reward). Malicious forks can also happen via censorship, but as I explained in a previous link to a reddit comment, proof of work allows you to detect such attacks. Here it is again for your convenience: https://www.reddit.com/r/privacy/comments/2xjy13/love_this_idea_for_fixing_https_with_a/cp211ng https://www.reddit.com/r/privacy/comments/2xjy13/love_this_i... > Many thanks for all the various answers, I now have a much clearer picture of what dnschain is, and isn't. No prob. Thanks for saying thanks. :)
  - e12e 12y ago
    But there's still a bootstrap issue? If mr. evil is mitm me, before I can start namecoind [ed: for the first time] -- I need to bootstrap into the block? (This isn't entirely hypothetical, think running dnscoin on a laptop for local resolving, and you don't trust your home ISP). But I assume you can bootstrap with the usual methods (eg: your OS come with the cert of at least once CA you trust, so you can use tls/ssl, or you can connect to a known, trusted ssh host etc).

ryan-c 12y ago

> Well, that is just how names work. Google was the first to register google.com, and now you "trust" that google.com belongs to them. You trust that google.com belongs to Google because you trust the DNS root zone to tell you who runs .com, and trust .com to tell you who runs google.com which tells you to talk to Google's servers.

itistoday2 12y ago
> You trust that google.com belongs to Google because you trust the DNS root zone to tell you who runs .com, and trust .com to tell you who runs google.com which tells you to talk to Google's servers. Yes, that is how DNS works. I was referring to simply the notion that Google registered google.com.
- e12e 12y ago
  Right. But eg: .no domains are linked to a tax/org [ed:code/registration number] (or used to be, anyway). And generally you can't just go and claim to be "The Norwegian Parliament".no (or whitehouse.gov). So a registry that's strictly first come, first serve, does not work like DNS (or the CA system for that matter, despite all it's flaws).
  - itistoday2 12y ago
    That's true. The point is to secure the connection. If you wanted it, you could create a blockchain that's secured in a decentralized fashion, but upon which registrations depend on a central authority. That way you could have .edu/.gov names that are both MITM-proof and are not first-come first-serve. Maybe take a look at Ethereum or Blockstore if you want to do that.

e12e 12y ago

>> And bootstrapping trust into the blockchain is basicially by trusting the ca-cert/github documentation? >Sorry, not sure I understand what you're asking there. How do I know what the "correct" blockchain is? That I'm not dealing with a fork? Many thanks for all the various answers, I now have a much clearer picture of what dnschain is, and isn't. Some of my confusion was related to how/if dnschain is different from just running one's own dns infrastructure (and ca infrastructure, and ripe...). That data is anchored in the blockchain is all well and good, but that only gives some kind of consensus. It's also interesting to know what that consensus actually tells you. Like does it imply any kind of vetting, or just first-come, first-serve.

itistoday2 12y ago
> How do I know what the "correct" blockchain is? That I'm not dealing with a fork? Ah, well, my friend, you should dive deep into the world of blockchain consensus, of which much has been written on. Different blockchains use different consensus models. Namecoin and Bitcoin use the same one: proof of work via hashing. It's what prevents forks from happening (well, that and the block reward). Malicious forks can also happen via censorship, but as I explained in a previous link to a reddit comment, proof of work allows you to detect such attacks. Here it is again for your convenience: https://www.reddit.com/r/privacy/comments/2xjy13/love_this_idea_for_fixing_https_with_a/cp211ng https://www.reddit.com/r/privacy/comments/2xjy13/love_this_i... > Many thanks for all the various answers, I now have a much clearer picture of what dnschain is, and isn't. No prob. Thanks for saying thanks. :)
- e12e 12y ago
  But there's still a bootstrap issue? If mr. evil is mitm me, before I can start namecoind [ed: for the first time] -- I need to bootstrap into the block? (This isn't entirely hypothetical, think running dnscoin on a laptop for local resolving, and you don't trust your home ISP). But I assume you can bootstrap with the usual methods (eg: your OS come with the cert of at least once CA you trust, so you can use tls/ssl, or you can connect to a known, trusted ssh host etc).