Optimizing Fork Resolution through Proof of Fork

Protocol Design
#1

Forks in Nano's protocol can only be caused by malicious actors on their own account. Currently, however, the network overhead caused by fork resolution can affect normal users, as representatives may change their vote many times during an election. As such, SonderDev suggested an alternative method of resolving forks on Discord: Representatives observing a fork should drop their votes, stopping either block from being confirmed. After some discussion, my "Proof of Fork" fork resolution implementation is as follows:

Alice attempts a double spend:

  1. Alice publishes blocks A and B to the network.
  2. A and B propagate throughout different nodes in the network until nodes observe the fork.
  3. Nodes who observe the fork propagate the Proof of Fork (i.e. proof of two conflicting blocks) throughout the network.
  4. Representatives who receive a Proof of Fork always vote for "Fork Observed" over any blocks.
  5. The network reaches a consensus that Alice's account has a fork.
  6. All nodes will discard all normally valid blocks that Alice attempts to publish, effectively halting her account.

Alice wants her account unhalted:

  1. Alice publishes a "unhalt block", which would normally be discarded, but is valid while her account is in a halted state. I propose that this be a transaction with the account owner as the recepient, and with an amount of 0 raw. The work difficulty threshold can be set significantly higher for this block.
  2. Nodes propagate the "unhalt block".
  3. The "unhalt block" gains consensus, is cemented onto her chain, and her account exits the halted state.
  4. Alice resumes normal activity.

The "unhalt block" changes the hash of Alice's latest block, invalidating the previously valid blocks that caused the fork, preventing malicious nodes from using those blocks as a Proof of Fork to permanently halt Alice's account.

#2

Is this really the case?

I thought a node would vote for whatever block is being seen first with the votes of PR being accumulated and rebroadcast by others.
Are you sure you're not referring to earlier protocol versions?

I believe this is no longer how it's done.

#3

It is the case; representatives vote for the block they see first, but if they later see that a different block has a higher vote weight, they change their vote to the one with the higher vote weight. There is a possibility that this happens many times during an election due to latency.

#4

This is false. Simple bad programming or issues with broadcasting a previous block could cause this as well.

Can anyone quantify how big of issue this is? It seems introducing a new account/block state may have it's own network drawbacks. What happens if transactions from the fork account are happening quickly? Some nodes have the account "frozen" while others don't? Seems like a mess to sort out.

#5

It would require more careful programming. I don't see this as a major drawback, as waiting for a confirmation before publishing more blocks, or assuming that the block has been confirmed (if it hasn't, the new block would be invalid and not cause a fork) both avoid causing a fork.

Indeed, if it isn't actually a problem, there's no reason to change or add anything.