Domain Name Resolution for Short Named Satoshis #2551
dannydeezy
started this conversation in
Ideas
Replies: 1 comment
-
The cool thing with the padded version is a sat hunter could go acquire 14 of the hope+padding names and then actually consolidate them into a single utxo, then sell that utxo on a marketplace, so that the end user can actually buy a full majority of the hope sats in a single purchase |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Because every sat has an alphabetical name and you can inscribe on sats, they are pretty nice domain instruments for a censorship-resistant decentralized domain name system. A basic DNS resolver is pretty simple to implement - just treat inscriptions as DNS records, or URL redirects, and route to the most recent inscription. See some example implementations:
However one major challenge to adoption is that short sat names are not mined for a long time! A sat with a cool name like "hope" won't be mined until the year 2137, so a naive DNS resolver is limited to 11 (and soon 10) character sat names.
But... Perhaps there's an elegant way to have short words still be "rented" before they are mined. For example, the sat "hope" is not available until 2137, but currently the following sats do exist: hopeaaaaaaa, hopebbbbbbb, hopeccccccc, ... hopezzzzzzz etc. Perhaps we can come up with a nice system of rules for DNS resolvers to follow when the sat "hope" is not yet mined (or not yet inscribed)....
For example, if somebody types "sat/hope" into the browser, the DNS resolver can do the following:
Using this majority-rules system makes it harder to domain squat because you need to hunt down a majority of the sats for a high quality name. Also as time goes on, more "hope" sats will come into circulation, and the owner would need to proactively ensure they maintain a majority of the "hope" sat ownership (though this could be outsourced to a specialist sat hunter)
A risk with this approach is that some can expire but that's not totally unlike the existing system people are accustomed to.
The resolver can be in-browser via an extension (could easily be added to existing extensions like Unisat, Xverse, or Alby), or even we could add it directly into ORD in the future with an additional endpoint.
Thoughts on this? Would love some feedback!
https://twitter.com/i/status/1689001019433500672
Beta Was this translation helpful? Give feedback.
All reactions