(I wasn't sure where to make this post, if it should be posted on here/nostr or on bitcoin, but decided here).
DNN, a Bitcoin-anchored naming system for nostr and the web.
- Doesn't bloat Bitcoin (no data added to it).
- Not a blockchain / there's no shitcoin.
- Permissionless.
- Censorship-resistant.
- Scalable.
- Cheap / no recurring payment.
- Have whatever name you want and change it whenever you want.
- Human-readable & human-memorable ID/address/true-name.
- A lot of secondary-effect solutions and benefits that come out of this.
I essentially examined the issues of past attempts to eliminate reliance on ICANN and noticed their problems, and collected others' criticisms of them, which led me to develop this approach.
Here's a presentation of the idea: https://video.nostr.build/ce76b435f360425f24ec98faeb037527bc33af90e453511c67b8ca813f62b14c.mp4
Aside from that, you can read up on the README file and other files (NIP-DN and node policy) from the repo found on this slave site: https://icannot.xyz/
Would like to hear people's thoughts on it.
If this turns out to be a proper solution, then I'd continue developing it, assuming I'd have funds for it, or if devs come along to help develop it.
If I am understanding this correctly, it is similar to a “phone number” or human-readable bitcoin transaction ID that also has associated metadata? Interesting idea if that’s true.
So the Bitcoin event is connected to the Nostr event because the Nostr events public key is encoded as a bitcoin address right? In essence, while this “adds no burden to bitcoin” in a practical sense it requires multiple transactions for a name since no one uses their Nostr pub key as a bitcoin address. So it would involve:
When I was originally working on Nomen I also considered using a scheme that involved using a Nostr pub key as a bitcoin address/pub key as well, but I kept hitting this same wall. I ended deciding it was both less costly to Bitcoin and overall less tiresome to the user to just allow them to use any Bitcoin transaction from any address with just an attached OP_RETURN as the anchor. This is actually even easier now since core v30 relaxed op return restrictions, giving more room to create a sane protocol (I originally made some discouraging mistakes in Nomen due to having to work within the 83 byte limit).
Happy you checked it out =3
I understand that concern, or rather, it’s more of a practical consideration than a true problem. To acquire a DNN name/ID, a user would typically need at least two transactions: one to fund the Nostr address, and another to perform the transaction that anchors the name/ID. A third transaction could be used to return remaining funds.
On one hand, it is a practical issue, more so on that third transaction if it happened, for the user, but beneficial for miners, of course, since they'd get more fees x3. However, I'd counter the general presented practical issue with 3 points:
What I'd summarize from all of these points is, yes, there's a bit of a practical overhead, but it wouldn't dissuade the user from using this protocol, especially considering its counter-benefits and general various primary and secondary-effect benefits.
Side note: This is also making me think of a 'nostr-first' approach of a wallet wallet, where a wallet can be developed/released, where it would, from its seed, generate multiple nostr addresses and from it their corresponding bitcoin addresses. With altered UX tweaks, this would result in having a user use their wallet (new wallet based on this setup/scheme of course) for their normal bitcoin transactions/saving, but also can be used for nostr purposes as well (with careful UX planning as to avoid, or rather decrease the chances of, privacy and ID matching). Just an interesting thought I had while writing this reply =3
What are the alternatives you have found not satisfying your expectations that push you to build this solution?
Most of them require running a separate blockchain that is not the most secure in comparison to Bitcoin, and most of them seem to be centralized (or at least not as decentralized), and having to deal with a currency that is not as solid as Bitcoin, and for those that have used Bitcoin, they're adding non-transactionary data and bloating bitcoin with said data where aside from being limited by their sizes, there might be a future that these loop-holes get removed.
So I basically looked at all their problems (from what I knew and from what people have mentioned), and thought, "Can there be something that doesn't have any of those issues?" and came up with this solution with those points mentioned in the OP.
From my pov, it seems like this solves all those issues, scales well, and is secured (without bloating/adding junk to Bitcoin), etc.
Interesting scheme. I was curious how it was both "anchored in the bitcoin" and not putting data on-chain which is laid out in (4):
This inversion of offchain referencing onchain rather than the reverse is not something I've seen before.
I was also curious how one can "Have whatever name you want and change it whenever you want" and it appears that that's only true if your name carries metadata about how to verify the name:
This can be shortened to another encoding I guess:
The above example becomes:
Which is objectively more human friendly even if it's unsatisfying.
Overall I feel like I'm not able to "Have whatever name I want" but it's an interesting scheme.
I'm basically differentiating between an "ID" and a "name", where "alice.n50.5" can be "bob.n50.5" where the change happens in nostr event kind:61600