pull down to refresh
the @bitcoin operator commits batches periodically. If you already registered a name through Nacho app or atbitcoin.com, it will be included in the next batch
Any incentive to run a centrelay?
If you run your own certrelay, then your queries are private.
Operators have an incentive to keep the network operational because they sell handles. Users want their handles resolvable too. Luckily, certrelays are small and since HTTP based we can take advantage of caching, CDNs ... etc so quite cheap to run.
Also, no claim mail for me too.
sent an email. thanks
Queries are sent to certrelays: https://github.com/spacesprotocol/certrelay
Users publish signed records and certificates there, all verified against the Bitcoin-anchored state root without storing anything on-chain. It's HTTP-based so you can run a Fabric client directly in the browser to find peers and send queries.
the resolver in the hero section of the site is actually a Fabric client, verifying right in your browser: https://spacesprotocol.org/
i have sent an email with claim codes. let me know if you dont get it. there is an issue with lightning payments flow will fix it thanks.
it will ignore names that have a dot after the "@" symbol so wont confuse with emails. its been quite reliable. uses iOS OCR apis which are quite good. unless the handle is very poorly written, it should read it fine. You can reattempt the scan by hitting "scan again".
Handles are finally on mainnet. We've been working on this since 2024.
Quick look at the Nacho app resolving grace@key, verified on device. The scan feature is neat if you put a handle on a t-shirt:
We have built SDKs for JS, React Native, Go, Swift, Kotlin and Rust: https://spacesprotocol.org/docs/developers/sdk/
If you're building a wallet or app and want to integrate, we are happy to help.
Bug means bad operator can forge rebindings of the subspaces they themselves sold, these will resolve under normal (compact) resolution until a patch.
correct but there's an important point. the attacker is necessarily the operator betraying their own customers and it comes at a huge cost. If they submit an invalid commitment hash on-chain (since even an invalid compact proof needs an on-chain anchor) and later it was patched. They permanently lose the ability to sell new subspaces under that L1 space because they broke the chain of commitments.
Someone has to detect the bug, author the new circuit, and the whole resolver/wallet ecosystem has to upgrade. Right now presume that's like a small team but in future idea is to have it percolate.
exactly same as patching a vuln with any software
No it doesn't require the L1 space operator to do anything. The roots published on-chain are just plain merkle roots independent of the zk circuit.
So new a circuit/zk arch, does not require changes to anything that's on-chain.
The zk circuit is just a compression of the verbose proof. that's all.
One day there will be formal verification for all of the zkvms but that day is still far off. Basically there will be more soundness bugs in risc0. (I didn't look at the guest program, but just go on risc0 or the wrap for now).
i wouldn't say formal verification is that far off. They have already formally verified parts of the circuit, but let's assume that all zk is broken for the sake of it.
As a subspace holder, you can have a more verbose certificate that's merkle exclusion proofs from past roots and an inclusion proof of the root you're included in. That's a provenance proof of your name regardless of what happens to zk. Data availablity is just, you, the holder, keeping that proof to yourself.
The zk is swappable with a resolver update. The core protocol itself does not care about zk at all. it only lives at the resolver layer. the zk part is libveritas. Just like openssl might have a bug now or in the future same goes for libveritas.
see libveritas: https://github.com/spacesprotocol/libveritas
Let's say we discover a bug, then what you need to do is compress your verbose plain merkle proofs certificate into the new patched zk circuit then re-publish to certrelay. Still, you won't be rug pulled even if all zk is nonsense so its very different from zk cash
haven't read the full discussion but just to be clear... zk is used to compress the proofs i.e. clients can verify by downloading a small compact proof.
you can make the full proofs available (the off-chain tree itself) and verify the chain of commitments is sound without any zk. tradeoff just larger proofs. they are just merkle trees.
anyone can do this if they are paranoid about the zk circuit ...
if someone builds a bitcoin zk light client, you can't argue that bitcoin is zk and everyone will get rugged. same idea here. the zk enables lightweight verifiability.
Proving that some alien creature created us is hard enough, let alone one that is all-knowing, all-loving, and all-powerful
It depends on what you mean by "en masse." If you’re referring to the average user who doesn’t want to run their own Bitcoin full node, etc., then...
Spaces uses DNS, so you could easily leverage solutions like Fabric behind a mainstream resolver (e.g., 1.1.1.1) to benefit from its massive caching layer. Implementing this isn’t difficult, for example, by using SIP-02 (see: https://github.com/spacesprotocol/sips/blob/main/sip-0002.mediawiki).
Users don’t need to trust 1.1.1.1; they can verify the entire protocol state with a small zk-proof.
Spaces guarantees name ownership in a permissionless way, functioning somewhat like a certificate authority—but that’s where its role ends. Solutions like Fabric manage the records off-chain.
the explorer is indeed slow and we are replacing it soon. it has not been maintained for months.
the email thing was a small issue that got fixed early on.