3 ms·

> This would require miners to somehow validate ownership at time of registration and on every update. They'd need to validate on initial registration, yes, bu

> This would require miners to somehow validate ownership at time of registration and on every update. They'd need to validate on initial registration, yes, but after that there's no reason (that I see) for them to validate again against DNS. Relevant proposal: https://forum.namecoin.info/viewtopic.php?f=5&t=1439 https://forum.namecoin.info/viewtopic.php?f=5&t=1439 > I've seen no plausible proposal on how to do that without introducing significant risks of forking the blockchain. I haven't heard a compelling argument as to why it would introduce "significant risk" of a fork. Define significant.

ryan-c 12y ago
I have seen that proposal, I do not consider it plausible, and the reasons it would cause fork issues are addressed in the thread there. * Pool A mines block trying to import example.com, and validates ownership via TXT record. * Pool B must either trust Pool A is right (e.g. not evil and not fooled) or verify Pool A's block itself. Pool B tries to validate example.com, and is unable to because someone saw the import attempt and began a DDoS on example.com's name servers, or because example.com is trying to fork the chain on purpose, or because Pool B's ISP is censoring example.com or any number of other reasons. Making blockchain validation depend on external data is trouble. There was a web of trust/voting scheme proposed as well, but nothing fleshed out, and any votes based on coins held are unusable because a single party (my best guess is BTCe) holds at least a third of all NMC ever mined.
- itistoday2 12y ago
  > Pool B must either trust Pool A is right (e.g. not evil and not fooled) or verify Pool A's block itself. Pool B tries to validate example.com, and is unable to because someone saw the import attempt and began a DDoS on example.com's name servers, or because example.com is trying to fork the chain on purpose, or because Pool B's ISP is censoring example.com or any number of other reasons. Ah, good point, sorry I must have missed that in the thread. That's actually a significant roadblock to importing names, so I'll update the post accordingly, thanks.
  - indolering 12y ago
    >> .com's cannot be MITM-proofed in a practical manner, unless they imported into a blockchain. > Trying to "import" domains from traditional TLDs into a blockchain really isn't a good idea. This would require miners to somehow validate ownership at time of registration and on every update. I've seen no plausible proposal on how to do that without introducing significant risks of forking the blockchain. You could import a domain into a blockchain using DPoS, with some number of delegates agreeing on a published DNS record over a given period of time. An attacker's ability to disrupt the process is limited by their ability to disrupt the publication of DNS information more generally. > Making blockchain validation depend on external data is trouble. This gets closer to the real problem. You are basically using the blockchain to perform triangulation of cryptographic information which is ultimately controlled by a third party. Throwing that information on the blockchain doesn't make it magically impervious to MITM attacks.

ryan-c 12y ago

I have seen that proposal, I do not consider it plausible, and the reasons it would cause fork issues are addressed in the thread there. * Pool A mines block trying to import example.com, and validates ownership via TXT record. * Pool B must either trust Pool A is right (e.g. not evil and not fooled) or verify Pool A's block itself. Pool B tries to validate example.com, and is unable to because someone saw the import attempt and began a DDoS on example.com's name servers, or because example.com is trying to fork the chain on purpose, or because Pool B's ISP is censoring example.com or any number of other reasons. Making blockchain validation depend on external data is trouble. There was a web of trust/voting scheme proposed as well, but nothing fleshed out, and any votes based on coins held are unusable because a single party (my best guess is BTCe) holds at least a third of all NMC ever mined.

itistoday2 12y ago
> Pool B must either trust Pool A is right (e.g. not evil and not fooled) or verify Pool A's block itself. Pool B tries to validate example.com, and is unable to because someone saw the import attempt and began a DDoS on example.com's name servers, or because example.com is trying to fork the chain on purpose, or because Pool B's ISP is censoring example.com or any number of other reasons. Ah, good point, sorry I must have missed that in the thread. That's actually a significant roadblock to importing names, so I'll update the post accordingly, thanks.
- indolering 12y ago
  >> .com's cannot be MITM-proofed in a practical manner, unless they imported into a blockchain. > Trying to "import" domains from traditional TLDs into a blockchain really isn't a good idea. This would require miners to somehow validate ownership at time of registration and on every update. I've seen no plausible proposal on how to do that without introducing significant risks of forking the blockchain. You could import a domain into a blockchain using DPoS, with some number of delegates agreeing on a published DNS record over a given period of time. An attacker's ability to disrupt the process is limited by their ability to disrupt the publication of DNS information more generally. > Making blockchain validation depend on external data is trouble. This gets closer to the real problem. You are basically using the blockchain to perform triangulation of cryptographic information which is ultimately controlled by a third party. Throwing that information on the blockchain doesn't make it magically impervious to MITM attacks.