What about ignoring them but not at the system level? A bit hard to imagine the details of this but at the broad conceptual level every vault keeps a local hierarchy of who they trust the most based on reliability etc, and they prioritise their incoming / outgoing gossip based on that. If a peer falls below a locally defined threshold they are deemed (locally only) as untrustworthy. The result is the vault may not forward gossip received from untrusted vaults, and may not send new gossip to untrusted vaults. The vault prefers to gossip with the most trusted peers so it should be a self-reinforcing mechanism.
This should not damage consensus so long as >2/3 vaults are locally trusted. There are no punishments, just a decline in activity to untrusted vaults. Also note this does not change who the vault considers to be elders etc, everyone still sees and agrees on the same network structure, so an untrusted elder is still considered by everyone to be an elder.
Even if the trust hierarchy for each vault is different it should work. It results in untrusted nodes becoming gradually worse laggards on the gossip graph, and if enough vaults locally distrust a vault it will become so far behind on the gossip it will be marked as misbehaving using normal verifiable ‘global’ misbehaviour rules (eg announcing a block that isn’t based on a valid history because they’re too far behind).
I shy away from the difficult logistics of announcing and enforcing punishments as a group. It would need some counterbalance to avoid constant requests for punishment, and the counterbalance is just more ‘punishment gossip’.
This does not replace enforceable punishments. If a vault signs and forwards invalid gossip it can be removed since it’s identifiable and verifiable bad behaviour. But for the types of misbehaviour which cannot be proven, I think that should only be enforced at the local level (but with eventual global consequence).
Neighbour Audit Request
How about a mechanism where if a group of vaults think their section is compromised they can request a neighbouring section to do an audit (maybe pay them in safecoin to perform it so it has to be worth the while of the requesters)? I haven’t got a good idea what the audit looks like but the idea of ‘punishing misbehaviour’ seems intimate with the idea of ‘audit’.
What does an audit look like? How is an audit initiated? Who has authority over the process? What are the inputs? What are the outputs? How are the outputs converted to pass / fail conditions? What consequences befall those who fail? Who has authority to enforce the consequences? Lots of tough questions.
I’m not sure if there can be an effective mechanism for this sort of ‘special’ audit. Audit should probably be inherent to the default network functions and be continuous.
Precedence
How does bitcoin manage misbehaviour? Mainly using the concept of banscore threshold to locally ignore misbehaving nodes (for some local definition of ‘misbehaving’).
This is a good definition / idea but it does not remove the concern that ‘passing a test now’ does not mean the vault will be trustworthy in the future. Switching trustworthiness is costless instant and secret.
My general feeling on the network attacking / testing vaults is it’s probably best not to encode it into the network layer, but try to keep it local as much as possible with ‘natural’ effects coming from that local action. A bit like the idea of ‘dumb pipes’.