31 sats \ 3 replies \ @ursuscamp 31 Jul 2023 \ parent \ on: The ICANN Problem, Solved With Bitcoin bitcoin
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.
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