Most transactions are the size of a regular bitcoin transaction, and limited only to top-level spaces. Subspaces are handled off chain with zero knowledge proofs. So we can scale to billions of subspaces/names with little on chain footprint. The only data stored on chain is the top level space name in the transaction to open the auction. Top level spaces are limited to roughly 10 per day.
how does one find that registry? For DNS we have NS records to know what server to fetch delegated data from. What do we do in spaces to find the relevant server starting from data on the blockchain?
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.
So, for this protocol, as long as people agree on a genesis block number and a set of consensus rules, the bitcoin blockchain is just used as a timestamping system for all transactions submitted? Is there anything else besides these 3 things that glue the trust in the system together? What else could cause a chain split in the spaces protocol?
what is the online requirement of spaced? Can it go online whenever it feels like, or does it need to come online at a certain frequency like a lightning node?
it needs to view the relevant transactions in bitcoin blocks to update the state of spaces. It can come online whenever but it won't have updated data until bitcoin syncs and spaced gets the most recent bitcoin block data and transactions
whoever holds the key for the subspace is the owner - they prove/verify all updates with their key. We have created fabric for updating data for spaces, and it can probably also be used for subspaces: https://github.com/spacesprotocol/fabric
If you can delegate a subdomain in a zone file, why don't you just use DNS and DNSSEC for everything and avoid the need for subspaces in your protocol?
how can you prove off chain that you own a subspace? Seems like without going on chain, the space owner could delegate the same subspace to more than one owner?
is it really an off chain transaction then if there needs to be a zk receipt placed on chain? or, is it really that you get a benefit in that all off chain transactions can be aggregated into a single on chain?
OK, so it seems like the transaction is not really done off chain, but instead, all metadata for the transaction is just not necessarily stored on chain?
for example, in the early days of spaces protocol, there won't be tons of subspaces per space, so if a subspace wants to be delegated, they aren't going to want to wait days or weeks for the space owner to have more transactions to aggregate delegation of, so each subspace transaction is practically going to require a single on chain transaction if there is no others to aggregate with?
i guess I'm trying to understand if this has a similar paradigm as zkcoins and taproot assets?
with this syntax, is there a way to distinguish between a subspace that was delegated via the spaces protocol or inside a zonefile that has been attached to the space?
since the inception of the internet no email addresses have been defined directly on the tld so practically no collisions sip-02 also attempts to make this as painless as possible to integrate even into mainstream resolvers
bob@bitcoin,bobis a subspace of the parent spacebitcoin. What about sub-sub-spaces? What do those look like?.in it's name?