3 ms·

> 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 t

> 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.