We have considered the possibility of a "key sharing" attack (node operators sharing their node's private keys with each other to sign receipts on each other's behalf.) We mitigate this in a few ways:
1) anyone with your node's private key can claim your locked funds, so it is risky to do this with someone you don't absolutely trust.
2) But let's assume it's just 2 nodes run by yourself: we frequently randomize the set of other nodes on the network your node must collect receipts from, so that it cannot just keep creating receipts from the other nodes you control. Both (or all) of your nodes must be in communication with the rest of the network to keep their participation score up and not being kicked out of the node registry.
3) A system in place allows a new block to be valid only if it has been created by one of the first X accounts of a per-block randomised list of accounts in the registry, giving the new block higher value if the first account create the block, and less value as it goes down the list. If all of the first X accounts in the list fail to create a block, each of the next accounts can only create an empty block, without publishing receipts, and lowering the score of all the accounts that missed the chance to create the block.
This requires an attacker to controls enough of the registered nodes to always publish receipts and create blocks. To theoretically create an alternative chain by only communicating between their own nodes, as the chosen chain is the one where the blocks are created by the highest account in the scrambled list, an attacker needs to have its account in the first position several times, and skip creating a blocks, to actually do so when producing a fork, and hoping that in its fork the highest accounts in the list are its own nodes. To do this without relying on luck an attacker needs to control 90% or more of the nodes in the registry.
This is ZooBC version of the "51% attack", which should be called 90% or more attack :)
