Vote/Unvote Pairs

In the comments thread of @remlaps recent post I started thinking about the idea of handing off signed-but-unposted transactions that could be posted later as an alternative to coordinated activity, and I'm wondering if there might be a more general application of this idea. We often think of posting things to the chain as very immediate actions, especially because Steem has such short block times that things get onto to the chain within a few seconds, but it's implemented as a multi-step procedure where you first compose and cryptographically sign a transaction and then it gets posted to the chain. Usually there's a timeout on transactions such that they are only valid for a short time if they don't get posted (for example if you were trying to send some Steem to someone but there was a network outage you probably wouldn't want it to go through when the network gets back up hours or days later, you might have changed your mind about doing the transaction by then). But that's more of a concern with some actions than others, it's more of a problem if a resource-using unposted transaction is floating around than one that is more neutral.

This got me thinking in terms thing/anti-thing pairs, such as the virtual particles in quantum physics where you can sometimes think of interactions in terms of particles and anti-particles which "balance out" to zero, or forces and reaction-forces in Newtonian mechanics, or in the world if finance we have the credits and debits of double-entry bookkeeping. The idea I'm pondering is that if somebody wanted to create a "softer" vote they could do it by creating a vote/unvote pair -- they create and post their vote operation to the blockchain like normal and also create a long-timeout transaction that removes that vote but instead of posting it to the chain they send the signed transaction to a third party (either via off-chain communication or via encryption on-chain). Then that third party has the option of posting that unvote later to remove the effects of the vote.

Why would anyone do this?

I think there could be a few interesting applications. One example could be a "dead man's switch" for witness voting -- we have a well-known governance problem that stale witness votes could potentially keep bad witnesses around if a large stakeholder stops actively monitoring what the witnesses they supported are doing. But if the stakeholder banked a corresponding witness-unvote for each of their witness votes then a service that monitors account activity could deploy those unvotes if they see that the stakeholder hasn't been active, taking them to the safer, neutral "not voting" state than perpetually supporting the witnesses they supported before they left.

And, although I'm not fond of the voting-bot economy, this might be a way to make it less of a problem. Right now people are very uncomfortable using downvotes to police "overvalued posts" because a downvote doesn't just say "that vote was too big" to a voting bot, it's also interpreted as a "you suck!" message to the person whose post is being voted on, and most people don't want to do things that feel that aggressive. But if a voting bot handed off the paired unvote to third-party auditors then those auditors would have the power to deploy the unvote for low-quality, spammy, or abusive posts without the harshness (and need for Steem Power) of downvoting. If the voting service customers only use the service to make sure their high-quality posts are getting rewarded they would have nothing to fear from that, right?

Another application could be DAO proposals. Right now large stakeholders have an incentive to keep the return proposal very highly supported to keep malicious users from gaining access to DAO funds. But those big stakeholders likely don't want to spend a lot of time and energy considering new proposals and monitoring them on an ongoing basis, and may not want to be seen as "playing favorites" by picking and choosing which new proposals are allowed to have support. As a result most people are unlikely to even consider creating a new proposal since they would need to convince the big stakeholders to support it. But if the big stakeholders' primary concern was just preventing egregious proposals they could do vote/unvote pairs and send a supporting vote to every new proposal that comes in and the corresponding unvote to people in the community who can be trusted to deploy it for any harmful proposals. If the large stakeholder supports both the return proposal and every non-malicious new proposal then it's like being neutral among the non-malicious proposals, which can compete for votes among smaller, more active users.

Thoughts?

I think this is more a conceptual thing about usage models people could use than a specific, concrete technical proposal (I only know the broad outlines of the composing-signing-posting sequence of getting things onto the chain, let me know if I've overlooked any technical details that would make this idea unworkable). But maybe it's a usage model that might help address some of the issues in the ecosystem? What do people think?