131 sats \ 5 replies \ @ursuscamp 30 Jul 2023 \ on: The ICANN Problem, Solved With Bitcoin bitcoin
I created a protocol called Nomen which uses Bitcoin and Nostr to solve this problem.
Here is the indexer: https://nomenexplorer.com/
The spec: https://github.com/ursuscamp/nomen/blob/master/docs/SPEC.md
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.
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:
-
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.
-
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