Yesterday I ran into this post by @bid.bot, a new bid bot that has some intriguing features dedigned to allow minnows to downvote crap content without the risk of retaliation.

The retaliation culture is really bad on steemit, and while I make no secret of the fact that I believe bid-bots and other types of self-upvote by proxy constructs that skew the value of real curation to the platform are hurting the intrinsic value of the platform and will eventually end up hurting the value of STEEM, the intent that @bid.bot shows in wanting to provide services that actually improve the curational properties of the platform is now making me rethink my position on bid bots.

A while back I ran an experiment with an away-bot that was aimed at the self-upvote usage of bots. Aimed at attenuating the upvotes by payed for bots by doing a small downvote. An away bot is a simple private bot that will wake up only when you are away and are not doing any curation yourself. Given that I'm no fan of automated fake curation through upvotes, the idea of automated anti-anti curation seemed like a solid concept to me. So if I, or any other person running his or her instance of this personal bot would be away, the bot would wait untill its owner's voring strength came above 99%, and would than start looking for upvotes that could be linked to transfer of funds in the other direction. All cool and dandy as an idea, but then I ran a test. I intentionally used low powered downvotes for testing purposes,and I used a low powered account as well. So a downvote didn't actually even register in the payout. Have a look here to see how much negativity the test alone provoked. There is a huge sense of entitlement amongst many of these bid-bot users. They think just because they paid for an upvote, they are entitled to escape curation and if someone does a downvote against their bought upvote, they perceive it as if that someone just stabbed the tire of the brand new car they bought. With that line of reasoning, the idea of retaliating a downvote with a downvote or a flag with a flag seems quite reasonable, right?

Downvotes and Flags are NOT created equal

There is a huge problem with retaliation of bigger fish against smaller fish, and that problem is that the reputation system is wired up in such a way with the downvoting system that downvotes and flags are actually not the same thing, though technically at first glance they appear to be. The two are linked together by being a single operation for the person casting it, but at a fundamental level, their effects are quite distinct.

Downvote: If a small 70 SP account does a 100% downvote of a post projected to make $1.00, that downvote will have the effect that the post payout will go from $1.00 to $0.99. If a 600 SP account would do the same, the post payout would go to maybe $0.90, and a 6,000 SP account might be able to get the payout down all the way down to zero. The effect of the downvote though has one effect and one effect only: The attenuation of an existing upvote.

Flag: Now if the 100% downvote were to be casted by a 10,000 SP account, still at 100%. What would happen? Well, as soon as the voting strength needed to downvote the post to $0.00, in this case about 60% of the caster's voting strength, the remaining 40% VS will go to a different effect. The effect of cutting into the reputation of the person who created the downvoted post. Done by our 10,000 SP account, the 100% downvote would end up being 60% downvote versus 40% flag. For a 100,000 SP account it would end up being 6% downvote and 94% flag, and so on.

Don't retaliate downvotes with flags

The big problem with retaliation isn't so much the retaliation itself. The problem is retaliating mere downvotes with flags. The 100,000 SP account retaliating against the $0.01 downvote by a 60 SP account WILL destroy the reputation of the later. The problem the problem though is, with them being the exact same operation, technically, can we really blame the 10,000 SP account for meeting a 100% DV with a 100% DV?

Well, this is where my feature proposal comes in. We need a top-off flag. A flag that distinguishes a (potentially) flagging downvote from a downvote never meant to hurt the reputation of the poster of the post being downvoted. This top-off flagg is essential both for the platform, but also for bots like @bid.bot, so unintended destruction of reputation.

Non flagging downvotes

To elaborate what I mean with a top-off flag, let me explain how it could be implemented in a bid bot such as @bid.bot, how I think bidbots should implement (anonymous) downvotes.

It is all about RSHARES. The unit of voting used in STEEM. A bot like @bid.bot should aim for two things:

1. Never allow a downvote to let the total number of RSHARES go below zero.
2. Downvote as close to the amount of RSHARES the user paid for without violating #1

So how would we do this if the user paid for a $2,- downvote of a two day old post projected to pay out $1.20 ? Well, we wait. We wait until the post is six days and a number of hours old. By then the post might have gone up to $1.85 in payout. An amount we could match perfectly in RSHARES all the way down to zero BUT NOT FURTHER. Then we have 15 cents worth of RSHARES left that we may need to somehow credit back to the user. Guess bot owners will be able to figure that last bit out for themselves.

As STEEM blockchain feature?

If we look at the bot solution, we see there are some caveats. Someone with two accounts could abuse the bot and make it do flags by letting the bot match an upvote he himself made and than retracting it just after the bot dit its downvote. The best solution and a solution that would help retaliation accidents from happening would be to make flag an optional attribute to downvoting. Without the flag-flag (pun intended), the downvote would then never cut into the receiver's reputation. This would not take away from the idea that anonymous downvoting is desireable, but it would make it less needed against the more moral of big fish while at the same time it should make it easyer for anonymous downvoting bots to implement without the risk of the abuse I just mentioned.