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.
I created a protocol called Nomen which uses Bitcoin and Nostr to solve this problem.
Here is the indexer: https://nomenexplorer.com/
In short, claims to unused are published on bitcoin via OP_RETURN and Nostr is used to provide the data transport layer. Bitcoin is the time stamp server essentially, nostr is where record changes are published.
Every time I bring it up, people say “cool” and then almost no one has used it. I don’t know if it’s something most people consider a problem needing solved, or if I just haven’t made it easy enough to use yet.
reply
Just read it (yet to test it). Pretty cool! Still digesting it, but one question (I'll save other questions for later): After the initial creation of a NAMESPACE ID with a bitcoin address, where there's a <NAME><OWNER PUBKEY> (owner nostr public key i'd assume, correct?), if I'd want to transfer the ownership from myself to another person, would I have to use the exact same bitcoin address to do so, or any bitcoin address is fine but what's required is the signature of the nostr address of <NAME><OWNER PUBKEY>?
reply
Your second thought is correct. There is no connection between the bitcoin addresses/UTXOs and the claims. Any UTXO is fine as long as the transfer of ownership is signed by the correct key.
reply
Do you have any thoughts on the scalability of this solution given the demand for blockspace?
Would it make sense to publish a checksum of multiple claims on-chain? What if two npubs try to make the same claim in the same block?
reply
There is no plan to allow multiple names to "share" a UTXO via a merkle root, nor should there be, IMO. I thought about it, but there are issues with this:
  1. There must be scarcity of names. If the goal is human-meaningful names, then there must be some limit on "scaling" them, or someone could just claim every useful name in human speech inside a single Merkle root.
  2. Data availability. All ownership data is "on chain" and thus always available. The record associated with a name have more flexible data availability requirements (like DNS records) and are thus available on nostr relays. However, the most important part, ownership, is always available on chain. Unless you wanted to use something like an inscription envelope, fitting a lot of data on chain is not possible. If you store all the names in a merkle root, then the data must be stored SOMEWHERE off chain.
That doesn't mean scaling is impossible, there are multiple ways I envisioned scaling.
The first is via "custodial" sub-domains where someone just issues new custodial names via nostr events associated with your key and you can then issue records against that. That would have a trust model similar to modern DNS.
The next way to scale is via sidechains. Something like Liquid, for instance, has an identical UTXO model to Bitcoin and you could easily issue names on Liquid. However, because of the different block cadence, you can't have the names occupying the same namespace.
So, while "ursuscamp" might be a name on the base layer (Bitcoin), the equivalent name on Liquid would be "ursuscamp.lq" or something like that.
So "mom.ursuscamp.lq" would be at the custodial sub-domain "mom" assigned to the name "ursuscamp.lq" where the ownership information is on the Liquid sidechain.
So it's really quite scalable as is.
reply
Thanks for sharing, that makes perfect sense!
Have you given any thought to adoption yet? It seems like a bit of a chicken and egg problem, because you need both the servers and the clients to adopt the system for it to benefit from network effects.
What would it take for a naive user (like me) who has a VPS to start using this system?
reply
Handshake.org ($HNS) solves this. You can buy a sovereign TLD, which you can purchase from namebase.io or shakestation.io. I use a custom domain for both Nostr and Bluesky, and other social networks like Lens, Farcaster, etc. will likely follow. HNS supports emojis and non-English characters, which is https://very.🆒/
reply
I hate that I can never truly own a domain.
If we ignore for a second that this would need a hard fork it won't solve the problem as long as only a small fraction of society uses Bitcoin
reply
I remember Bitnames was also offered up as a solution, built on a drivechain but hey BIP300 looks a long way off
reply
Missed that first post, read it. Good series.
reply
reply
Just read up on it a bit. Seems good.
Basically, after everything is done for example: "hey fred, send me 0.5 btc to freakoverse.sats" (assuming wallets take the first person to take the name based on date/block) or if I'm paranoid "...to freakoverse.sats@800890.2" (@block.line).
Got a few questions for this though (not sure if they're answered by someone, so will have to dig for them):
  • can you attach an IP address to a .sats name? (if yes, then would browsers be able to read them and have normal website functionality, assuming they'd support the ordinals and sats name systems)
  • can you have anything other than ".sats", create your own TLD, or have non at all?
  • can you modify the content of a .sats ordinal, like changing the btc address (and IP if that's possible in point 1).
  • are there normal non-custodial wallets that support this yet, like Trust Wallet or Blue Wallet.
reply
have you read up on bitDNS?
reply
There have been countless ideas for doing DNS using Bitcoin as the ownership/transfer ledger, it's a perfect use case for the Bitcoin chain as namespace is the only other digitally scarce asset.
Spending Bitcoin to assert a namespace title onto the chain enforces costliness.
... but introducing a shitcoin circles back to the whole namecoin mess, naive, and overcomplicated.
A viable solution will have no fork requirement, so it's looking like the only valid utility for oridinals since OP_RETURN wasn't adequate.
Get back to the drawing board.
reply
Why do you think a token is required? Isn't a domain name an NFT in itself? Isn't this the logical use case for Ordinals? A means to trade and an anti-spam mechanism to limit registrations and put a cap on the resource exhaustion attack that frivolous registrations would create...
I do think that it is a little outside of the scope of Nostr protocol for this, as Nostr is a kind of pubsub peer to peer network. It is the conduit that could be used for finding registration data, but it is really a whole protocol in itself, that nip-05 could be also connected to. Just needs a short TLD to distinguish it.
Domain names simply need a way to stop a flood of registrations that result in a lot of work for the network with no compensation.
Bitcoiners need to start thinking about the question of, "ok, so, no token required, but where is this data securely and faithfully replicated to?"
IPFS? Something like IPFS? It has to have chain access if it's based on ordinal style NFTs. It needs to be possible to get paid to host the database somehow, or it needs to be essential to running an ecommerce operation so it is absorbed into the cost.
reply
you had me until recommending embedding a shitcoin into the epicenter of Bitcoin
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).
This is a hard fork
reply
I believe merged-mining (mining for two chains at once) is possible without a hard-fork. Infact it was proposed by satoshi himself when talk about BitDNS was going on to instead do the DNS stuff on a seperate chain:
I think it would be possible for BitDNS to be a completely separate network and separate block chain, yet share CPU power with Bitcoin. The only overlap is to make it so miners can search for proof-of-work for both networks simultaneously. The networks wouldn't need any coordination. Miners would subscribe to both networks in parallel. They would scan SHA such that if they get a hit, they potentially solve both at once. A solution may be for just one of the networks if one network has a lower difficulty. I think an external miner could call getwork on both programs and combine the work. Maybe call Bitcoin, get work from it, hand it to BitDNS getwork to combine into a combined work. Instead of fragmentation, networks share and augment each other's total CPU power. This would solve the problem that if there are multiple networks, they are a danger to each other if the available CPU power gangs up on one. Instead, all networks in the world would share combined CPU power, increasing the total strength. It would make it easier for small networks to get started by tapping into a ready base of miners.
There's also a Merged mining specification on the Bitcoin Wiki https://en.bitcoin.it/wiki/Merged_mining_specification
reply
This is why I love SN
reply
well, shittokens are now on bitcoin with ordinals, which I was against but it happened, so *shrug
Might as well make use of it and have it solve the ICANN problem. I'm not a technical person, so I don't know how or can this be implemented, but I'm just presenting the idea to make bitcoin as the source of decentralized authority instead of ICANN for human readable addresses, for websites or for bitcoin addresses.
reply
there's a difference between creating brc 20s and changing Bitcoin's block reward
reply
What is befuddling in all this is that for some reason NFT bros only talk about secondary markets but the most visible primary market for NFTs is domain names.
Problem isn't solved without the mechanism to pay the nodes that store, relay and propagate the current state of the registry.
reply
Wouldn't the incentive be that they'd be rewarded with those naming tokens and they can:
  • use them themselves (use incentive)
  • sell them (financial incentive)
  • get network fees as people update their tokens (financial incentive)
reply
Making a reward for spending sats to make an NFT doesn't need another reward.

The reward is nobody else can use that private key to authenticate the name.

That's what the cost of a DNS record is based on, and why it is a speculative asset, and has been a form of savings for decades now (Mark Jeftovic has many stories as this was his thing).
Secondary markets are irrelevant to the base ledger. People wait days for domain name transfers currently. I doubt that waiting for a bitcoin confirmation is gonna be onerous.
Price discovery is in the remit of those operating the order books, it does not have to touch the chain at all, and we already have a type of NFT record, among several options that have existed since someone figured out you can put arbitrary data on chain with OP_RETURN.
And I'm pretty sure that robosats, and similar, don't have any blockchain behind them but function perfectly well as marketplaces. Neither would any market in Bitcoin NFT based DNS registration protocol.
reply