pull down to refresh

I've been toying with the following idea, and I would like to know what other people think about it, if it sounds feasible, desirable, practical, or not...just whatever your opinions or thoughts are, I would be curious to hear.
To overcome DNS centralization, I propose the following paradigm shift:
  • Allow multiple registrations of the same name.
  • Use ordinal inscriptions on Bitcoin (see ordinals.com for info) to "register" the domain names directly on the Bitcoin blockchain.
  • DNS servers (or their reincarnation) would accept record updates only from the owner, checking a signature against the Bitcoin blockchain.
  • Propagation of DNS records could happen between DNS servers in a similar way as today.
  • To resolve a domain name, DNS servers would return a disambiguation list of matches instead of a single match (if there are more than one).
  • If there are multiple matches, the web browser or such would present the user with the choice, showing a popularity number and other registration information such as a description.
  • For convenience, The user could have the option to "lock-in" their choice, not to be prompted again for that domain name.
These are obviously different semantics from how domain names work today as 100% unique identifiers, but why not? If it solves many problems such as:
  • Squatting. The more people register a particular name (like google.com) for example, the less valuable that domain would become, by virtue of not being scarce.
  • Scamming. The disambiguation would be presented with a "popularity" number (and other info) to easily distinguish who's who. The real google.com would stand out. (And if a competitor passes them up, they deserve to be recognized.)
  • Ownership. The "new DNS servers" would validate record updates using a signature that can be checked against the owner of the inscription as recorded in the Bitcoin blockchain. This is made possible by ordinal inscriptions (see ordinals.com).
  • Loss. If keys to a particular domain are accidentally lost (i.e. Bitcoin wallet keys are lost, or the inscription is accidentally given away in a transaction), the domain could be re-registered with a new ordinal inscription. Popularity would have to be re-earned, but that would be a fair penalty for losing the keys.
Please, shoot holes in the idea. I'd love to know the reasons you think nobody should waste time on it.
i oppose any method allowing the reuse of names. the system is worthless without name exclusivity.
reply
If exclusivity is permanent, there's no defense against squatters and scammers, which is a directly contradictory problem, but also undesirable.
In a different comment, I proposed a "best effort" of first come first serve on names, the rough consensus of the network would allow people to individually ignore scammers and squatters and refuse to propagate their name updates, eventually crowding them out of the network.
I just believe that popularity prompt is bad UX. First come first serve must be the modus operandi until enough individuals act to counteract the network effects.
reply
defense against squatters is simple in theory, make names expensive and nontransferable. no point in squatting on a name if it costs a lot and you can't sell it.
reply
If you can devise a scheme that does this without a separate, dedicated block chain, I would be interested in hearing that.
reply
once inscribed, names can be sent to a burn wallet instead of the user. they are essentially nontransferable from that point on. but can still be easily "looked up" for resolution. updates could be more complex but still doable. and burning the sats involved kind of increases the cost without increasing the price... so to speak.
reply
But how do you enforce that? Bitcoin doesn't recognize names natively. If I write a transaction that says "the name ursuscamp belongs to me, here's my pub key", what will stop you from also writing a transaction later that says "the name ursuscamp later belongs to me, here's my pubkey"?
The only answer I can think of is soft consensus, like first come first serve. Unless you can come up with some scheme that gets Bitcoin to treat names as native assets, such that if you attempt to publish a second transaction also claiming a name, nodes will reject that transaction as invalid.
We might just be talking about the same thing, since you're referring to inscriptions, which are themselves really just a social convention.
reply
I think we mean the same thing. it would have to be a social convention, yes. the OP was proposing ordinal inscriptions, so I ran with that method as a given.
I am not familiar enough with the bitcoin code to make any intelligent guess as to how it could be enforced on a protocol level, and I'm not sure I'd even want such a thing.
reply
Then I believe we would be in agreement.
Totally agree on UX issue. I originally had the idea of "pinning" so that this UX pain only needs to happen on first visit. Still not ideal, though.
I also totally agree that permanent exclusivity suffers from an opposite problem.
reply
I have had many similar thoughts recently. I have been discussing this with @lightcoin and on the Nostr telegram.
The thought I had which was most similar is using a decentralized propagation mechanism, like DNS. Other schemes I've seen have tried to make sure that every participant agrees, or reaches consensus, on exactly which name is correct. Using something like IPFS to hold the entire global file of names.
However, propagation will make this protocol much simpler and it already works well enough for the real life internet.
Some key differences I had in my thoughts:
  1. Names can actually be nameSPACES anchored by a merkle root. When block space gets expensive again, your name can actually be part of a namespace managed by a third party. Each update issued by the namespace manager will include all additions/updates to previous names + new names, published with a link back to the previous update. This is effectively a side chain anchored to Bitcoin consensus.
  2. All names inside namespaces are actually signed in a multi-sig by both the namespace manager AND the owner/purchaser of the name. That adds censorship resistance. The namespace manager CANNOT seize your name because he doesn't have your private key. It's permanently embedded in the merkle root of his namespace chain on the Bitcoin blockchain. However, he might be able to keep you from updating in the future if you need to, which brings me to:
  3. The ability for a name owner to publish a unilateral transaction directly to the bitcoin blockchain in case he gets blocked by the namespace manager from updating his name. This can serve as a permanent redirect from the old name to a new name in a different namespace.
  4. Presenting a list of competing namespaces to the user is bad UX and has a centralization component to determine who is the most popular. Namespaces must be first come, first serve. The first one that claims a namespace owns it in the protocol. So what about Johnny-come-latelies? What if someone takes Google on the Bitcoin namespace protocol and they aren't google? Well, remember, this is rough consensus. Not everyone has to agree on the correct names! If someone takes google and Google comes on the scene and also registered Google on the blockchain, once people realize that real Google is on the scene, they just instruct their clients to permanently ignore the Fake Google and not propagate their names anymore.
  5. Point 4 also serves in the case of catastrophic namespace mismanagement. If Amazon screws up royally and loses their keys, they can create a new Amazon, and people will get the picture real quick. Again, rough consensus, not total consensus!
As you can see, this very similar to your idea, and I think it has lots of promise. I've been considering writing a client that can run alongside Core and watch blocks for names, and also create PSBT's to claim names when you publish them.
reply
Interesting, thanks for sharing.
The UX challenge in my version is definitely real, but let's explore it a bit. I originally had the idea of "pinning" so that any UX pain due to disambiguation could be minimized to the first visit, but perhaps even that could be significantly improved. In a Nostr setting, the popularity rank could be scoped to the relay. Community-centric popularity rankings (i.e. having your client sample from its favorite relays) could have nice advantages, and at the same time mitigate that centralization danger. Clients could automate disambiguation in many cases to minimize UX pain (and should lock-in so users don't get unsuspectingly surprised by a different same-named domain on a future visit). UX/UI would definitely have to be in focus.
Such a radically new paradigm as non-unique names would have costs / trade-offs. Perhaps the best middle ground would be for clients to forever support both ends of the spectrum (traditional DNS and non-unique naming). The advantages of trad DNS would remain, while a non-unique naming system would provide an escape valve to discourage from and protect against power structures abusing the more authoritative DNS system. Relays could even inform their own ranking based on the existing DNS system for seamless transition. That is to say, if I control a mysite.com registration in both trad DNS and on the Bitcoin blockchain, then I would keep both up-to-date. If a divergence happens, the hybrid system would seamlessly failover to the non-unique naming system, still pointing clients to my intended site. This would also facilitate a painless transition from trad DNS to non-unique naming without any ugly UX disambiguation for text-book cases. In cases where no such authoritative link exists (such as brand-new Bitcoin-only registrations), your "first come, first served" approach could be applied as policy, not requirement. This would relegate manual disambiguation to an available option / feature, rather than making it an obstacle to acceptance.
In that sense, the "non-unique" part (of this newly coined term "non-unique naming") would serve mainly as the relief valve, but would not get in anybody's way. Spoofs of google.com would never bother anyone because they would have to be sought out. First-time registrations would have priority, but squatters could still be circumvented with community support through manual disambiguation until relays quickly get the hint and switch over to the more popular site.
reply
What's nice is that we can define the protocol for establishing names on the Bitcoin blockchain, and name conflicts will have to be handled somehow. So if it gained any traction at all, some convention for handling naming conflicts would necessarily arise. Whether it's your idea, my idea, or something we haven't thought of yet.
reply
Sounds a bit like how i2p’s domain system works!
It is interesting, however if you think about UX it is still a bit worse. I am trying to imagine my grand mother trying to go to her bank and this prompt pops up and she chooses the wrong one and gets scammed instead.
reply
Does having a centralised DNS really affect a large enough part of the population that it is needed? Personally, I don't think so! I've seen this same fringe thinking when ENS, Unstoppable domains, and namecoin came around and I just don't see it,
If you had content that you feel would get you flagged and your domain taken down just spin that up on a tor version of the site.
reply
domains are primarily about ease of use and name recognition. tor solves neither of these, it is more for hosting and no simpler than just using the site IP for navigation.
reply
is DNS centralization an actual problem? how many instances have there been of censorship?
reply
Plenty of instances of domains being seized by the FBI.
reply
It hasn't been abused to the level that it could be, yet. But you have to think it will happen eventually. Plus, it's totally KYC-ed globally, top to bottom.
reply