The ICANN Problem, Solved with Bitcoin and Nostr via Nomen
3834 sats \ 15 comments \ @freakoverse 17 Sep 2023 nostr
https://imgprxy.stacker.news/Z1peBfhFGwtJfY2WlLdJ6CmE0rh1Y-yl5x9snxDUij8/rs:fit:600:500:0/g:no/aHR0cHM6Ly9pbWFnZS5ub3N0ci5idWlsZC9kMDQ0MTkyYWRjOTEzMWU2NWFiODVmYmUyNjQ0ZmI1MWM1OGYyMDdkMjkyM2U0YWZiMzQyMmQ0MTFhMDQ1NzA2LnBuZw
I've written two other posts in regard to the ICANN problem, the first was suggesting Nostr as the solution, and the second suggested having Bitcoin as the solution. Both of these ideation attempts to provide a solution to the ICANN problem had their own criticism, discussions, and suggestions of already existing solutions, and I'd like to dive into those suggestions and end it with what seems to be the most optimal solution.

Namecoin, BitDNS, DriveChains, SpaceChains

It seemed like, at the time, BitDNS was the solution everyone had in regard to solving the centralization problem of domain names, and Satoshi Nakamoto was involved in its discussion as well. Sometime after, a new network with its own blockchain and token called Namecoin emerged to be the very application that was discussed.

The Problem with Namecoin

  1. It's a different blockchain that isn't Bitcoin, which by itself would not make it reliable and untrustworthy as others would be able to mess with it, whereas, in comparison, it doesn't have the proper security that Bitcoin has built up and continues to get stronger.
  2. Dealing with secondary storage of a different blockchain.
  3. Drivechains and Spacechains, aside from having the same issues of the two points above, while interesting, aren't reliable in a consistent manner and may indirectly affect Bitcoin in a negative manner when it comes to the behavior of miners, from what I understood.

Unstoppable Domains

This one got a lot of hype and marketing behind it, as well as some browser support as well. It's also utilizing other EVM chains like Polygon. It seems like there's a set price for whatever name you'd want to register/record, and that's outside of the transaction fee that you'd have to pay to obtain a name.

The Problem with Unstoppable Domains

  1. This solution is running on the Ethereum blockchain, one that is not decentralized, at least not anywhere near the level of Bitcoin.
  2. Similar to Namecoin, you'll have to deal with a chain and its storage that's not even focused on domain names.
  3. From personal usage from a while back, it was (may still be) very slow.
  4. Considering what Ethereum has gone through, fees can get ridiculously high, which would affect updates to those domain names.
  5. It's complex. Having to deal with multiple chains leads to confusion.

Ordinals: Inscriptions

This is the first attempt, while not being the main reason for its creation, at releasing a solution to the ICANN problem directly in Bitcoin. It's not a separate blockchain. This basically inscribes data, a name in our case, onto a single Sat (or multiple Sats depending on how you go about it), recording that data forever in Bitcoin, and having an address in that inscribed sat.

The Problem with Ordinals: Inscriptions

  1. There's a size limitation, and it is costly to update data and its records.
  2. Transforms Sats from money to assets in an ideological sense, and gives money ID, resulting in a potential danger of having Sats being fungible.
  3. Stores undesirable and/or problematic data that Bitcoin miners and node operators don't want to hold, and such data cannot be removed.

Nomen

This solution is the second attempt that tries to solve the centralization of domain names, where the name registration is recorded in Bitcoin directly, however, another piece of technology is used to handle ownership and data management, Nostr.
What's interesting about Nomen is that you don't have to create a new Bitcoin transaction every time you want to update the data under the registered name, aside from changing the ownership, as everything is handled on Nostr's side. What's happening on Bitcoin is just registering the name and who the owner is (a Nostr key pair).
I gave it a shot and it's simple enough (not in a UX sense yet of course). I used Bluewallet, where I created a PSBT with a bit higher fee than usual to account for the extra data, added my desired name and my Nostr address as the owner, using the tool provided in Nomen Explorer, broadcasted the modified PSBT, updated my record at the same tool site, and that was it.

The Problem with Nomen

  1. It doesn't rely on Bitcoin only, however, it seems like, having Nostr involved in this solution, is a necessary action to move past the issues of what Ordinals: Inscriptions has.

Conclusion

Unless another solution pops up that is similar to Nomen but only relies on Bitcoin, then my vote seems to be going toward having Nomen as the solution here, especially when various apps are created that provide both a Bitcoin wallet and Nostr accounts services and make a seamless UX experience.

Keys to Nomen's Success

Assuming that Nomen is the way to go, here are my thoughts on how to have it succeed as it climbs to stand next to ICANN and hopefully overtake it in the future. These steps are in order of quick deployment and usage (I'd say point 2 and 3 are interchangeable):
  1. The first immediate step would be to utilize it with Nostr as it replaces the system under (or completely replaces it with a new NIP) NIP-05, along with utilizing other methods to set up the necessary details via setting up your website on Nostr and connect everything together.
  2. The second step would be to have Bitcoin and crypto wallets to integrate Nomen so that people can start sending each other BTC (normally or through LN) using those registered/recorded names. Human-readable Bitcoin addresses.
  3. We then have a browser extension so that people can install it into their browsers, like any Chromium-based browser like Google Chrome
  4. Considering that ICANN and Nomen domains shouldn't conflict with one other, the method of accessing a Nomen website should be easy, in regards to entering the domain name in the browser URL. Something along the lines of, as an example, "bd:freakoverse" (Bitcoin Domain : Domain Name). Entering that in the browser URL field will trigger the browser to see it as a Nomen domain, fetching the appropriate data and loading the in page.
  5. Small and major browsers would start integrating Nomen natively into their browsers, allowing people to access these new domains/websites without having the need to install an extension.
  6. For those who care about decentralized domains and freedom tech, you'd aim to create exclusive content on your Nomen website, and/or provide such content to others for their own websites, or support others in some way to achieve this. When such content is established, you'd set up a traditional website and provide context that the content people are looking for is accessible on a Nomen site and that they'd have to install a browser extension to reach it or use a browser that has Nomen natively. All the while, if you have a website already with people visiting it each month or so, start advertising your Nomen website on it with proper guidance for those who'd hit that CTA.

Thanks For Reading

What are your thoughts on all of this? Do you think Ordinals: Inscriptions and/or Nomen will succeed as the system/protocol for solving the ICANN problem, or have we yet to reach a good solution to this problem?
write
preview
related posts
204 sats \ 1 reply \ @0330830bf9 17 Sep 2023
I and countless others have described similar systems. The idea of using Bitcoin as proof-of-costliness and timestamps for name registration is almost as old as Bitcoin itself. Nostr seems like the missing piece given it's ability to provide a second layer for storing and updating zone data.
It makes sense from one angle, as specific namespace is the only thing more scarce than Bitcoin. It's a logical value to store on chain.
But... I've all but given up on pushing something like this for a few reasons.
  1. ICANN DNS isn't really that broken and censorship of it is an imaginary problem. The most reviled people/states in the world have their own domains without fuss.
  2. Whatever system we try to displace it with still relies on legacy DNS underneath, just because that's how everything on the internet is built around it from ISP's to Browsers. AltDNS systems are just like Altcoins, pointless due to the gravity of the big daddy coin (or DNS system in this case)
  3. Squatting is a positive market function, and any facet of a new system that can mitigate this is a fundamental flaw in that system. Squatting is proof the existing system works by the market pricing scarce namespace appropriately.
  4. As soon as someone mentions a browser extension I stop taking them seriously. Relatively few people can/will use a browser extension, and without large numbers of users such projects are unsustainable. The lift away from SSL-Everywhere design cannot be hand-waived away with another browser extension.
There is an area that should be explored more acutely than DNS with some of these principles though: Human readable names for key-based identities.
NIP-05 is a good example of a half-baked solution that even so has proven some utility.
  • It provides a human readable translation to a key
  • If everyone owned a TLD would we even care about nostr?
  • If enforcing costliness with Bitcoin was a good idea, wouldn't everyone have a TLD already?
  • Few seem to care that it's usually trust-based
That last point is the sticky one and what to solve for, trust-less nyms... not DNS.
If we're to use indexers of OP_Returns, why not just use our peers in a Web-of-Trust type naming system? Ultimately namespace comes down to "What do other people know this entity as?" and nostr already has a concept of petnames.
If 100 out of 100 of the people you follow know someone as something, odds are you'll agree to as well. It doesn't matter what the timestamps say, as is admitted in the linked spec.
reply
0 sats \ 0 replies \ @freakoverse OP 17 Sep 2023
  1. If it's possible for them to censor or steal, then it's a possibility and that is indeed a fact. The whole nature of Bitcoin, as an example, is not trust but verify.
  2. I'm not that technical of a person, so I can't properly respond to this, however from my colleagues who are knowledgeable about it, and from seeing alt solutions, it's a hurdle but not that big of a hurdle.
  3. I'm in agreement here.
  4. I'm not saying people should rely on it, it's just a step in the process, which I did mention after that, browsers would have native support for these new Nomen domains. Heck, if they can go straight to native support / having a browser with native support built-in, and forget about the extension, then by all means. It's just a bonus.
  5. I mean sure, but in that regard, both who want to follow and be followed, at least for me and others, would like to have a concrete name that people without a doubt would know it's me or them. Considering I view ICANN as an issue, then NIP-05 is just a temporary ducktape solution.
reply
13 sats \ 0 replies \ @melvincarvalho 17 Sep 2023
Just got my first nomen name. I love it. Going to use it with dnstr
https://dnstr.org/
reply
10 sats \ 0 replies \ @ursuscamp 17 Sep 2023
Regarding UX, it can definitely be improved. I want to implement a Nostr bot and/or website that can accept a Lightning or ecash payment and make the onchain tx for you. Then you just need to sign a Nostr even to publish records.
reply
10 sats \ 5 replies \ @ursuscamp 17 Sep 2023
Thanks for your interest in nomen!
Just last night I opened three issues to address some potential future issues with the protocol:
https://github.com/ursuscamp/nomen/issues/6 - This is meant to address the data availability issues with ownership data. It proposes moving the protocol from version 0 to version 1.
https://github.com/ursuscamp/nomen/issues/7 - This discusses a way we might handle miners and griefers front-running names, a problem we have seen in the Inscriptions space.
https://github.com/ursuscamp/nomen/issues/8 - Describes a method for handling squatters that is optional and based on a web of trust.
reply
0 sats \ 1 reply \ @om 17 Sep 2023
How does selling a name work?
reply
20 sats \ 0 replies \ @ursuscamp 17 Sep 2023
There is a transfer mechanism described in the spec. No tooling currently exists to create them and I wouldn’t suggest constructing them manually if you’re technically inclined.
I think they’re likely to change to something described in issue 6 above. The currently envisioned transfer is brittle and necessitates users keep events signed by previous owners. But we can fix that.
reply
0 sats \ 2 replies \ @freakoverse OP 17 Sep 2023
/6: For me personally, while this solution is interesting, I wouldn't be a fan of it. I think a better solution would be to just have high-profile entities to just mention their order of claim. Ex: Someone took "Amazon" and then the actual Amazon that we know comes in and registers, they'd just market themselves as "Amazon:2" or something, and browsers/clients, over time, may suggest a "popular" domain to be pushed at the top and writing the domain and/or highlighted.
/7: This is interesting... in terms of decreasing the issue of someone not knowing if a name is shadow-claimed or not, why not, referencing the proposed solution in /6, have a list for those who haven't revealed their claimed name after X blocks (let's say 48 hours worth of blocks of 10 minutes as an example), would be put on that .shadow list (or browsers/clients would do the calc themselves to see if they unsalted their transactions within the X amount of blocks), otherwise it's a valid claim. This might be the smallest compromise to protect people from front-runners and decrease the risk of someone having already taken their name.
/8: No comment on this. I like it =3
reply
0 sats \ 1 reply \ @ursuscamp 17 Sep 2023
/6: For me personally, while this solution is interesting, I wouldn't be a fan of it. I think a better solution would be to just have high-profile entities to just mention their order of claim. Ex: Someone took "Amazon" and then the actual Amazon that we know comes in and registers, they'd just market themselves as "Amazon:2" or something, and browsers/clients, over time, may suggest a "popular" domain to be pushed at the top and writing the domain and/or highlighted.
What you’re describing here sounds more like squatting prevention. 6 describes putting all of the ownership data on chain so the indexer doesn’t require data from Nostr to maintain a chain of custody.
Am I misunderstanding what you mean?
/7: This is interesting... in terms of decreasing the issue of someone not knowing if a name is shadow-claimed or not, why not, referencing the proposed solution in /6, have a list for those who haven't revealed their claimed name after X blocks (let's say 48 hours worth of blocks of 10 minutes as an example), would be put on that .shadow list (or browsers/clients would do the calc themselves to see if they unsalted their transactions within the X amount of blocks), otherwise it's a valid claim. This might be the smallest compromise to protect people from front-runners and decrease the risk of someone having already taken their name.
Interesting! We could also make it so if they don’t reveal their shadow claim in 48 hours, their claim is invalid, making it impossible to sit on any claim for a long period of time.
reply
3 sats \ 0 replies \ @freakoverse OP 18 Sep 2023
Ah, sorry about that, I got my order wrong. The first and last should've been switched. Here's the correct ordering:
/6: No comment on this. I like it =3
/7: This is interesting... in terms of decreasing the issue of someone not knowing if a name is shadow-claimed or not, why not, referencing the proposed solution in /6, have a list for those who haven't revealed their claimed name after X blocks (let's say 48 hours worth of blocks of 10 minutes as an example), would be put on that .shadow list (or browsers/clients would do the calc themselves to see if they unsalted their transactions within the X amount of blocks), otherwise it's a valid claim. This might be the smallest compromise to protect people from front-runners and decrease the risk of someone having already taken their name.
/8: For me personally, while this solution is interesting, I wouldn't be a fan of it. I think a better solution would be to just have high-profile entities to just mention their order of claim. Ex: Someone took "Amazon" and then the actual Amazon that we know comes in and registers, they'd just market themselves as "Amazon:2" or something, and browsers/clients, over time, may suggest a "popular" domain to be pushed at the top and writing the domain and/or highlighted.
reply
0 sats \ 0 replies \ @SovranSystems 18 Sep 2023
Nice post!
reply
0 sats \ 0 replies \ @om 17 Sep 2023
Please also have a look at Handshake and Stacks. Handshake has tooling to supply https certificates to a browser without a browser extension; I haven't seen such a thing anywhere else. Stacks for the purpose of this conversation is like Namecoin but notarizes on Bitcoin mainchain which reduces the security problem. Also, .btc domains.
I also think that your review of UD was somewhat unfair as it works on Polygon now. End users don't have to deal with multiple chains or pay high fees.
IMO however we're nowhere near a good solution which should satisfy the following:
  • a user shouldn't have to download any chain but should be able to use a server
  • a server shouldn't learn both the user's IP and the user's query
  • a server shouldn't be able to lie to the user
reply
0 sats \ 2 replies \ @phygit 17 Sep 2023
Interesting, but you forget a few things.
  1. UX/Usage As often here, you focus on the technicality but not enough on usability (user point of view). If I read well, the Nomen solution requires to know Bitcoin AND own some bitcoin in a wallet AND have a Nostr account AND know what you're doing. You already lost 99.9% of the world population here. All this to register a "domain name" that is actually not recognized as such...
  2. ENS Funny that your long post fails to mention ENS (Ethereum Name System), the most important alternative name system of all times. ENS has been live for 6 years and has about 3 millions names registered (despite quite expensive prices). Like it of not, sounds like a huge success to me. At one point bitcoiners will have to accept reality.
  3. Unstoppable Domain You're a bit fast on your analysis on UD. Their system is working very well. It's fast, simple, and cheap (not mentioning that contrary to pretty much all other systems, the registrants own their names forever with no additional fees). UD is also a huge success and they are making deals with tons of people, from browser to gaming industry. You seem to consider that having a browser compatibility is a detail, but it's actually the key to success.
All in all, as much as I agree that ICANN should be replaced by something more decentralized, I don't think that Bitcoin fits in.
I can't help but seeing in your post yet another example of the "Bitcoin maxi frustration", characterized by the urge to replicate on Bitcoin everything that has been done on Ethereum for many years (NFTs, DeFi, ZK and now naming system).
This is absurd. We should work on making Bitcoin the world global currency, and that's already a fucking tough job. Multiplying copycats and stuff that don't need to be done on Bitcoin can only blur the message and delay Bitcoin success.
reply
0 sats \ 0 replies \ @archerships 2 Dec 2023
Unstoppable Domains is trying to patent their tech:
https://www.coindesk.com/video/ens-founder-on-patent-dispute-with-unstoppable-domains/
Should be dismissed on that grounds alone, IMO.
reply
0 sats \ 0 replies \ @freakoverse OP 17 Sep 2023
We're probably not going to move forward with the discussions in regard to points 2 and 3. We have our base stances on those from the looks of it so will move on from it.
In regards to point 1 however, yes, I'm in agreement here (aside from the issue of having btc, that is an 'issue' everywhere), as it was mentioned/implied in the post. With that said, it's only a matter of time before the UX part becomes sexy (discussions about that is already underway by interested individuals).
reply