Just trying to be honest. Would love for someone to scrutinize it from a technical perspective. See https://github.com/AndySchroder/bitcoin-submittx/blob/efa47eb1ac436cbb4fccbff64567ea1c52fe6352/bitcoin-submittx#L152-L156 for where I try to enable TOR stream isolation. A link is referenced that suggests that is how I should do it.

Not sure that docker is really needed to resolve this.

The way to test stream isolation would be to have several nodes that you control as test nodes, then use this tool with the --nodes option and explicitly connect to them, then monitor their logs and see where they saw connections from and make sure they don't come from the same IP. The problem is that bitcoin-submittx makes such short lived connections it will be a bit trickier to test.

I have not setup this test case yet, so maybe a better comment would have been that I haven't tested it, rather than I don't know how to.

what do you do for a sub sub space? user.subsubspace.subspace@space? the syntax just seems weird.

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?

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?

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?

can they delegate it back to the space owner without waiting for expiration?

so is there a genesis block hash or something in the start of the spaces chain?

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?

once they go on chain, can they go back off chain?

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?

who controls the launch of block 871222 ? Why can't I launch spaced on mainnet right now?

but a subspace owner can go on chain whenever they want, or do subspace delegations always stay off chain?

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?

I agree this is an issue, but I don't know that I like the syntax you've chosen. Not sure what a good solution is though.

can a space have a . in it's name?

what enforces this? is there a set of consensus rules in spacesd that all users must agree on?

where is the data stored then?

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?

OK, so if I register my space, then I can go offline indefinitely? will it ever expire?