pull down to refresh
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.
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
That part makes sense as to why no DA layer, I was thinking the cert was all the L2 subspace person had and why no DA layer, but if they get the provenance too (and don't lose it) then got you there.
But relying parties still transact against the drifting current root yes? which the operator controls (and which a bug lets be forged)? From what it looks like routine resolution doesn't rederive ownership from holder provenance, which would kind of defeat the whole purpose I guess if it did.
So isn't it still the same shape? soundness bug forces an emergency circuit swap, then recovery (recompress provenance into patched circuit, republish, allthat) requires the L1 space operator to anchor a new commitment that includes your binding under the new circuit?
If the operator refuses then even thouh your provenance proves you owned it historically there's no live commitment that includes you going forward? The name is over as a usable thing? Again due to the circuit swap, under the old circuit you're impersonated, so that binding can't gon on, but you can't get under the new circuit cause that requires authority you don't have? bug-forced swap hands operator a consent veto over your continued existence?
Other words you exit to an on-chain pointer you run, but then you can't take over operation of the off-chain tree unless you control or are delegated to by that persons UTXO and so you can't reallocate yourself?
Or is there some adversarial way to pull your subspace from under the UTXO without any action on the UTXO holder's part? Like pull it off altogether?
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.
Ah, much cleaner.
So is this right in terms of soundness bug impact/mitigation?
Bug means bad operator can forge rebindings of the subspaces they themselves sold, these will resolve under normal (compact) resolution until a patch.
Mitigation for subspace holder: Stop trusting compact resolution for anything high-value. Firefight past forged actions where known. Wait for the circuit patch, then the forged commitment stops validating.
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.
Sound right?
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.