pull down to refresh

0 sats \ 1 reply \ @ursuscamp 28 Oct \ on: DNN: Decentralized Naming Network nostr
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:
  1. a transaction to send bitcoin to the address for their Nostr pub key
  2. a second transaction to send bitcoin from the key to itself as the “marker” transaction
  3. a third transaction to send their remaining bitcoin not spent in fees back to their actual main wallet (optional but likely to occur)
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).
write
preview
0 sats \ 0 replies \ @freakoverseOG OP 22h
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:
  1. cost efficiency: even with multiple transactions, acquiring a name/ID on this protocol is, in most cases, cheaper than ICANN.
  2. retention and future use: a user who funds a nostr address to acquire a name might leave their small balance there, either to acquire another name later, using the same address or another nostr address.
  3. social and transactional utility: that funded nostr address can serve practical purposes, such as sending funds to other nostr users (or other bitcoin addresses by other people), giving the address social or transactional value beyond just name acquisition.
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
reply