pull down to refresh
People will definitely long for real human interaction as ai is everywhere.
The problem with just writing as myself is I'm still learning a lot myself and ai tools help me understand both sides of the argument.
I do however edit the responses and go back and forth with the ai to shape my responses.
If I was to speak as myself on this topic. I would say, How the F are Bitcoiners trusting NIP-05 when we have much better tools like Spaces Protocol. Yet most people shoot it down on it's surface, so I must go into technical debates and for that, for the time being, I need ai tools.
For the OP's simple reason that for human-readable names everyone has to agree on the same protocol.
It's rarely about technical backbone. Every backbone has issues. Is whatever zk that makes this spaces thing work trustworthy? Is there a zcash-type soundness bug lurking that would make every one of the names invalid one fine morning? If names can be forged there's gonna be no clean way to say these forged names are invalid and these real ones aren't. Unless the whole thing is formally verified in lean4 or something it's almost guaranteed there's a soundness bug lurking somewhere in the circuit design that when triggered will mean a loss of uniqueness guarantees for all.
What's the recovery plan for that? You can't turnstile something like this so everyone just accepts the soundness bug means nobody's spaces domans are valid anymore and everyone just starts again?
Has trail of bits seen the circuit code? can you show me the soundness audit? Being open source doesn't help here at all, zcash soundness bug was in the open source for 4 years.
You see where this goes, tech arguments cut both ways. It's much more about agreement. we have to all agree, and we already agree on DNS, and we need these things to work now, for everyone.
Of course every system needs adoption, that's true for everything.
Most people are skeptical of new systems at first and rightfully so, but if we always did things the same way and never improved, we'd never have all the amazing inventions we have today. Cars, Internet, Bitcoin, etc.
This logic argues- Why do we need Bitcoin, we have dollars?
We all know- decentralization, sovereignty, censorship resistance, etc. Bitcoin is better.
Spaces brings those same advantages to naming.
The trail of bits thing, idk, maybe that's something worth looking into, but like you said that's technical. The social adoption applies to everything, it doesn't mean we shouldn't build new tools and improve things. If we did that, we wouldn't have anything.
It's more than technical, it's everything. I had claude give me the heads up from the repo, here is where it lands for these zk subspaces.
Say one morning a security researcher discovers a critical soundness bug in the guest program circuit. Now what?
When someone asks "what's the pubkey?" for me@bitcoin the answer comes from a cert that proves the binding against an on-chain root. So okay.But the soundness bug means the attacker can produce a valid cert binding me@bitcoin to their pubkey. Resolvers can't tell which cert is legit. So future lookups of me@bitcoin become meaningless
It's unknowable if this bug has been exploited and if so how long this has been going on? If these attacker pubkeys signed important stuff that was processd based on subspace resolution, are those actions all in question now? Do we have to do a pubkey review? And if so what determines the true pubkey? If the holder rotated after the attacker minted theirs now the attacker's is older. These binding have never touched bitcoin for most subspace people. Bitcoin just knows a root that contains them, but Bitcoin can't tell you anything about who they arefor without the ZK layer working right,
This can't go on obviously.
So who presses the emergency button here? It's max decentralized by the looks of the repo and docs. so the answer is nobody presses the button because there is no button. And even if there is one what does the button do? Force everyone including these supspace level 2 domain holders to do the equivalent of exit to the L1 (have a wallet on bitcoin and an indexer and all that) so the whole thing can be replayed from day 1 and only if you can prove your ownership of the supspace on bitcoin and spend some bitcoin do you get to re-claim the subspace names you already had? By this time all trust in the system is gone anyway, and what happens if there's another soundness bug next month?
Point is for a new ZK project like this (and in this age of mythos) you have to assume there are soundness bugs in the initial circuit and that will be found over years. To assume there are none is not an option these days. But as far as I can tell this has been designed on the hope none will be found.
And that's application-level soundness bugs. This is all a guest application in Risc0 (only Risc0 as far as I can tell, not multi-prover) which itself had serious bugs last year. If risc0 buts like that happens in 2027 say, upgrading the spaces circuit doesn'tfix it,the new circuit just refuses to accept new subspace signing forgeries going forward. But old forgies are unknowable. like zcash. You need a fork-style recovery with checkpoint selection, state reconstruction, ecosystem coordination all the rest. The tooling for this isn't built in to spaces, the governance for it doesn't exist, again as far as I can tell, could be wrong but no mention claude found.
Bitcoiners tend not to be aware of how fragile ZK is because they're used to ossified code stability. But wiht this you can't even really sell subnames for the first few years because it's such high probability a soundess bug will force a restart. Unless the whole thing moves to lean4, but that woud take years of bleeding edge coding. Don't mean to dump on it, but if this is something you are really passionate about take it with a huge grain of salt and know it'll be years from now at least before you can start to feel like a subspace might be something you can trust and that won't just have its value disappear one morning.
This is awesome, more eyes on the project and more critiques make it stronger.
Yes I'm passionate about Spaces. I want to increase Bitcoin adoption and I think Spaces is an excellent way to do it. We need a way to easily convert hard to read data like Bitcoin and Nostr pub keys into human readable without middle men. Spaces is by far the best I've seen.
So, if we 'have to assume there are soundness bugs in the initial circuit and that will be found over years' - what in your opinion can/should be done?
We definitely wouldn't stop trying to create better tools because of risks, there's always risks. How to mitigate?
Maybe a solution is to run Spaces in parallel with NIP-05.
Same as with every ZK project, either formal verification or anticipate soundness bugs and have some way to mitigate them. And people who buy/sell/use these supspaces (are they even live?) have to go into it with the mindset that they will one day get rugged.
Or just get rid of these subspaces altogether.
But then you're left with the on-chain ones only, and there really isn't anything special about a bunch of clients agreeing on deterministic derivation from auction history.
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.
It's a cool concept. I'm just going by the repo here, so if there is stuff not published fair enough. But the repo does raise concerns.
Let's say there's a risc0 soudnness bug, or something in the groth16 wrap.
my take is there are a number of these waiting to be found in risc0. Zcash are pretty cracked and 4 years went by with that soundness bug in their main pool. A risc0 zkVM plus a Groth16 wrap is a much larger and younger attack surface than a single payment circuit like Zcash. 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).
So play it out. One is found.
I terms of this L2 subsapce signing, anyone can then impersonate anyone, against the verifiers who didn't keep the full data or who don't verify each time against it. Far as I can tell these L1 space operators are responsible for the data, since I don't see any sort of master DA layer or anything. In a system like this the data can't be counted on so have to assume the data is corrupt or gone. People just lose stuff, and trying to get normies to understand why zk data is important not to lose is a non-starter.
Or maybe a savvy l1 space giver-outer person deleted it themselves because they're the one that wants to exploit the risc0 bug by impersonating some of the subspaces under it that the already sold.
This is different to zcash becauase all coins are the same, i can't impersonate your coins. yes it sucks in terms of potential supply inflation, but there is no impersonation risk. Here there is.
Also this on-chain pointer thing defeats a malicious operator. minting NumId::from_spk is pure bitcoin, so that's independent of the ZK layer. But it does not defeat a circuit bug since the leg of the exit that attributes your pointer to the name is the cert. And the cert verifies against a root which is what the bug lets the attacker forge a competitor for. So under such a soundness bug you and the impersonator both hold cert-backed claims and then it collapses back onto data, and as above we have to assume the data will be missing. classic zk data issue.
Remedies seem to only protect going forward. And that's not helpful with these l2 subspace names imo, since things you've signed are atomic and everywhere.
Could be a misread on my part here or there but looks that way from the repos, happy to be corrected.
Just write as yourself, don't run everything through an AI, the average person here has a pretty finely-tuned slop detecter.