pull down to refresh
Yeah...but you have the same oracle-ish kind of problem that NFTs have: I could stick my name in an OP_RETURN and that wouldn't mean anything other than that my name is in an OP_RETURN.
For this to have currency, you need lots of people to run it (just like DNS)...but in that case I'm just not seeing why it is important to stick it in the chain.
If I have to trust someone or some protocol to interpret the data embedded in the block, why not just trust the them like I trust DNS?
I don't think bitcoin is very good at all for doing these kinds of embedding things, and I disagree that using your protocol gives me a "sovereign name that I truly own" anymore than a birth certificate from my local thug mafia government does.
The key difference is verification, not embedding.
Anyone can put data in an OP_RETURN. With Spaces, ownership of @Scoresby is proven by a Merkle proof that any Bitcoin node can independently verify, no trusted third party required.
Unlike DNS, which registrars or governments can revoke, a Spaces handle gives you cryptographically enforceable ownership secured by Bitcoin’s Proof of Work. Once anchored, no one, not even the issuer can take it or change it. The ownership of the name is permanently anchored on Bitcoin.
You don’t trust the protocol to interpret it. You verify the proof yourself against the blockchain just like any other Bitcoin transaction. The records (Lightning address, Nostr key, website, etc.) are stored off chain for speed, low cost and not to bloat the Bitcoin chain.
So yes when you want to use the name @Scoresby to say receive a Lightning payment, you are temporarily relying on the certrelay network to give you the current records.
However, You can always cryptographically verify that the records belong to the correct name using the Merkle proof. The records are signed by your key. If the certrelay lies or goes down, you can still prove ownership of the name itself on Bitcoin.
Much better than DNS, NIP-05, or any existing alternative.
This is very similar to how Lightning works: the channel state is off chain, but the security is anchored on Bitcoin.
Yes, it needs adoption to become widely recognized, like every idea. The critical upgrade is that the root of truth lives on Bitcoin’s immutable ledger, not under any authority’s control.
That’s why it’s meaningfully more sovereign than a government birth certificate or DNS name.
The on chain footprint is a tiny 32-byte root, yet extremely strong and flexible.
It's not how lightning works at all. At any point I can exit to the chain and the chain understands bitcoin. If I close my channel, I have the sats in a UTXO.
With your thing I have some data embedded in a block. For the data to have any meaning I have to rely on the existence of people who follow your protocol. Let's say I do your thing right now and I claim ownership of my username via your proof. This doesn't stop anyone from claiming they are Scoresby. At best all it does is show that I had a private key that was somehow associated with claiming this name in the manner prescribed by your protocol.
What I'm trying to point out is that Bitcoin is really only good for one thing: keeping track of where sats are. (well, actually two things: allowing people to move sats around even when others don't want them to and also keeping track of where sats are). It works because sats are native to bitcoin.
Usernames are not native. They are strings of data (which you compress into a merkle proof). It doesn't change the fact that we need some kind agreement on how to interpret the data. That's where your protocol comes in. And that's where the problem is: what if someone else doesn't follow your protocol and claims to be Scoresby? Can I stop them? What if someone who is not me claims the name in Spaces before I do?
I don't see how these problems are solved, and if these problems aren't solved, why not just trust DNS?
You're right, usernames are not native to Bitcoin like sats. They’re strings of data, and any naming system requires some social agreement.
The real question is how much trust that agreement requires.
Humans have a fundamental need to convert long, hard to remember cryptographic keys into simple, human readable names. Spaces solves this while staying true to Bitcoin’s ethos.
Ownership of a Spaces handle is permanently anchored on Bitcoin via a Merkle proof that any node can independently verify. No company, registrar, or government can revoke it.
Adoption is required for the names to be widely recognized, just as it was for Bitcoin itself. But once adopted, you get verifiable sovereign ownership that DNS can never match.
This is a meaningful step toward sovereign identity on Bitcoin, just like Bitcoin was a meaningful step away from trusting banks.
A standard Nostr keypair gives you a 64 character string as your identifier.
Spaces Protocol gives you something much better:
We already know it's valuable and people want it, look at NIP-05, people want human readable, but NIP-05 has a major problem.
NIP-05 ties Nostr identities to DNS, which means trust ultimately flows through ICANN, registrars, and certificate authorities. NIP-SPACES swaps that out. Identities are anchored to Bitcoin and verified locally with Merkle proofs. No registrar can revoke you, no DNS hijack can impersonate you, and verification works without trusting anyone's server.
If you've used
name@domain.comfor Nostr verification, NIP-SPACES gives youname@spacewith cryptographic guarantees instead of administrative ones.https://github.com/buffrr/nips/blob/spaces/NIP-SPACES.md