Previously, I had written a post on Stacker News titled "The ICANN Domain Problem, Solved With Nostr?", I presented the issue of how ICANN is the central controlling authority of internet domain names, and how we don't genuinely own them, and that issue spills over the solution that NIP-05 is trying to provide on Nostr.
The purpose of that post, and this one, is to showcase the issue of NIP-05, with the bigger issue being ICANN itself, to hopefully open up the discussion so that people can figure out a solution, all the while trying to present a potential solution myself. People have presented valid criticisms of the idea and presented holes in what I had presented as a potential solution, and they were valid ones. After some time, another solution presented itself to me, however, it might rub Bitcoiners the wrong way, but considering the opened floodgates with Ordinals, I thought might as well potentially make use of it.
What's The ICANN Problem?
Among the many reasons why people love Bitcoin is because it's not centrally controlled by anyone or a group of colluding individuals. The same goes for Nostr, which is seeing continuous growth in user adoption as they migrate from other centralized social platforms and other services to it. As such, current domain holders can completely lose access to their domain that's registered at ICANN, by an entity in ICANN, or by an external influence.
In short, the ICANN problem is that you are not truly the owner of any domain you've purchased under their rule. With that said, this leads to the issue that Nostr is trying to currently solve, which is simple, human-readable handle names, and a solution was presented called NIP-05 handles, but because of the ICANN, it is a bandaid solution.
The NIP-05 Problem
Nostr's NIP-05 handle solution attempts to address the issue of creating human-readable names for decentralized domains. Instead of using NPUB addresses directly, the idea is to associate handles with domains to improve user accessibility and convenience. However, upon closer examination, it becomes apparent that this approach poses several significant challenges and fails to achieve the desired decentralization and censorship resistance.
One of the primary concerns with the NIP-05 handle solution is its reliance on domain names. As we know, the domain name system is currently managed by ICANN, a centralized authority. This centralization introduces a critical vulnerability, as it means that a controlling entity could potentially take control of a domain associated with NIP-05 handles.
In such a scenario, if an authoritative entity seizes control of a domain, all the handles associated with that domain would be rendered useless, causing users to lose their hard-earned and recognizable identities. This loss could lead to a severe setback for user outreach and branding, as individuals and businesses may have built their online presence around these handles. Such an outcome significantly undermines the purpose of decentralized domains, as it introduces a single point of failure and compromises the integrity of the entire system.
The Failed Nostr Solution
The previous idea that I had presented to solve the ICANN problem, in gist, is to have a file that all relays would hold and update with domain names and connect them with users' NPUBs, but that had its issues:
1. Consensus on File State
One of the major with the Nostr idea was a robust mechanism for relays or entities referencing the file to reach a consensus on its current state. In a decentralized domain system, it's crucial to ensure that all participants are on the same page regarding the associations between names and their corresponding public addresses. Without a consensus protocol, discrepancies and inconsistencies would arise, leading to fragmented and unreliable domain resolution.
2. Ease of Squatting
Another pressing concern was the ease of domain squatting, where individuals could register and hold multiple names, limiting others' access to those names at little to no cost. The potential for abuse could hinder fair access to domain names. It would be a first-come-first-served process with no reasonable financial barriers.
New Solution: Utilize Bitcoin
Here's my newest attempt at trying to provide a solution to the ICANN problem, which is to make Bitcoin itself the new home for domains instead of ICANN. While others have presented the idea of other chains that are attached or anchored to Bitcoin that has already done this, I'd view it as still an issue since those chains are not as decentralized or powerful as Bitcoin itself and can be susceptible to failure.
Secondary Block Rewards: Domain Name Tokens (DNTs)
At the moment, the Bitcoin protocol rewards Miners that discover a block with an amount of BTC. The idea here is to add another kind of reward alongside the current one: Domain Name Tokens (DNTs).
Let's say this idea has been implemented into Bitcoin. An individual has successfully mined a Bitcoin block, and that person was rewarded with the current usual 6.25 BTC. Alongside that, they are also rewarded with, for example, 1,000 DNTs would be rewarded to that Miner, which can be then used, given, sold, or traded with other people in the world. The price of a DNT would be determined by supply and demand.
Once an individual has acquired a DNT, which was originally gained through POW, and then gained before use through a potential financial cost, they would then update the DNT that they own by attaching a name to it (permanent), and other relevant information like an IP address or a Nostr NPUB or note ID (can be changed later), and then send it (to yourself? to a contract? not sure how this part would work) to have it confirmed in the Bitcoin network, and if the name is available (ideally, there'd be a system that checks the network if a name is available or not before you send), you'd have that DNT recorded in the Bitcoin network with the associated name that no one can take, which would also have data that would connect it to a server to showcase your website on a browser.
Third Block Reward Type: Human Readable Bitcoin Address Tokens (HRBATs)
Accidentally thought of this when I was writing down the main idea above for the domain name tokens on Bitcoin. If users can obtain tokens so that they can be used to register/record a word and attach with its data, specifically an IP address or a Nostr NPUB or note ID, then another type of token that is pretty much the same as the domain one, but specifically for Bitcoin addresses.
This would follow the same idea as above, where miners would be rewarded with Y amount of HRBATs, and would be given/sold to the masses. A person with an HRBAT can then sign and send it with a name, have it confirmed and recorded in the Bitcoin blockchain, and then attach a Bitcoin address of their choosing to it. The results? We would now have human-readable Bitcoin addresses to transact with.
- Before: "Hey John, you can send me that 0.05 BTC to bc1qar0srrr7x...5l643ly...9re59gtzz...mdq"
- After: "Hey John, you can send me that 0.05 BTC to HummusMan9K"
End Thoughts
Here are a few extra thoughts I had while I was thinking about these issues and solutions:
- I don't think both of these types of rewards should be case-sensitive, as it would lead to various malicious issues if it was.
- I'm not sure if this requires a new BIP or not, and if it does and the solution is sound, then the latest issue would be approval from the Bitcoin network and approval time (as well as sound development/code of course).
- Other data can be attached to a DNT, such as a Bitcoin address, or a Bitcoin LN address as well.
- Even though a DNT is pretty much the same thing almost as an HRBAT, the reason I'd suggest there'd be two different types is for better organization and push for separate uses. A DNT would have "Domain Name", "Server Address", "Bitcoin Address", and "Bitcoin LN Address" fields, while HRBAT would have "Bitcoin Address Name", "Bitcoin Address", and "Bitcoin LN Address" fields.
- Internet browsers would need to add support for DNTs, and an agreed method of accessing them via the URL field needs to be figured out. Perhaps something like "Visit my website on bd:freakoverse" where "bd" stands for "Bitcoin Domain", is to point toward the Bitcoin network. Browsers can offer a quick toggle to switch between ICANN domains and Bitcoin domains next to the URL field, and a user can set whichever is the default.
The reward is nobody else can use that private key to authenticate the name.