Bitcoin-enabled solution to DNS centralization \ stacker news ~bitcoin

Bitcoin-enabled solution to DNS centralization

3213 sats \ 18 comments \ @kandycoder 29 Jan 2023 bitcoin

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.

view all related items

1558 sats \ 8 replies \ @TheL0wner 29 Jan 2023

i oppose any method allowing the reuse of names. the system is worthless without name exclusivity.

2 sats \ 7 replies \ @ursuscamp 30 Jan 2023

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.

0 sats \ 5 replies \ @cecil 30 Jan 2023

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.

0 sats \ 4 replies \ @ursuscamp 30 Jan 2023

If you can devise a scheme that does this without a separate, dedicated block chain, I would be interested in hearing that.

0 sats \ 3 replies \ @cecil 30 Jan 2023

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.

0 sats \ 2 replies \ @ursuscamp 30 Jan 2023

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.

3 sats \ 1 reply \ @cecil 30 Jan 2023

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.

0 sats \ 0 replies \ @ursuscamp 30 Jan 2023

Then I believe we would be in agreement.

reply on another page

0 sats \ 0 replies \ @kandycoder OP 30 Jan 2023

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.

10 sats \ 2 replies \ @ursuscamp 30 Jan 2023

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:

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

3 sats \ 1 reply \ @kandycoder OP 30 Jan 2023

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.

3 sats \ 0 replies \ @ursuscamp 30 Jan 2023

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.

5 sats \ 0 replies \ @ssats 29 Jan 2023

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.

0 sats \ 1 reply \ @TheBTCManual 30 Jan 2023

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.

0 sats \ 0 replies \ @cecil 30 Jan 2023

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.

0 sats \ 2 replies \ @benthecarman 29 Jan 2023

is DNS centralization an actual problem? how many instances have there been of censorship?

15 sats \ 0 replies \ @RdioActiv 30 Jan 2023

Plenty of instances of domains being seized by the FBI.

5 sats \ 0 replies \ @ursuscamp 30 Jan 2023

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.