The vendor is not guaranteed to recieve the money but they add money to the account only once they get the payout, if the money fluctuate/gets flagged then the end user simply receives less money onto his account. There is 0 risks for the vendor.
I have to ask for a clarification here: does the user upvote using his own account or is he delegating SP to an account of the vendor, which then does the upvote?
In both cases you are right, an attack on the systems is a waste of voting power. But in the first case if someone wants to disturb the whole process, he just deploys a bot that only targets comments that have a high payout (since the comment closest to the payout can be upvoted by many people) or creates an army of bot dedicated to downvoting comments with high payouts.
In the second case the attacker would have to flag comments, that have been recently upvoted and adjust the downvote to the amount of money he wants to deny the vendor.
I know that in both cases the attacker has to invest quite some money first respectively hold a lot of SP.
Yes but why would you do that ?
Good question: e.g. competitors, who want to diminish the reward of a vendor or "modern day Robin Hoods" [1]. My point here is that if something is possible in principle there will always be people that find a reason to (ab)use this system.
But here the idea is to pay with your voting power instead of steem/sbd which is an unique feature of steem so I thought of how we would be able to do this without resorting to self voting and then waiting a week to send the resulting sbd to buy what we want.
The idea of using this unique feature of Steem is indeed a very good one, but since it is not that straight-forward it opens up new attack vectors to mess with the system.
[1] As far as I understood the money from flagging goes back into the reward pool and is so available for everyone, a "modern day Robin Hood" could do this in order to steal from the rich to give it to the poor. If my notion of this is wrong, please correct me.
the user upvote using his own account
As for the attack, we upvote comments that are seconds from being in the "no more vote" zone, so if we manage this correctly, we can probably cast a vote within three seconds of the zone, which leaves no time at all for the attacker because he has to wait for the next block (3 seconds) to see that you upvoted the comment, and by that time, it's already too late. It's a bit tricky for a human, but a bot can definitely do it.
Which means that they have to flag the comments before they are voted on. So they have to flag it while being "blind" aka they don't know how much flag percent they must use to negate the deposit. Which means that if starbucks has 100 accounts, they have to flag all of these accounts all the time to make sure that they hurt deposits.
Them being blind also means that the system can see those flags and make the user vote on flag-free comments. So the vendor can easily scale the commenting system for little cost by adding accounts while the flagger needs a tremendous amount of voting power to be able to cover them all with flags that actually hurt the reward.
Right now with more or less 2500 sp I can do 10 downvotes at 1$ per day. (downvotes actually cost more in steem power than an upvote but for simplicity's sake we'll suppose they cost the same)
So that's 250 sp per 1$ flag per day.
there are 86400 seconds in a day, so 86400/20 = 4320 comments per day.
If there is just one account and you wanted to downvote all the comments, by 1$ you'd need 1 080 000 sp. Which is more than 5.5M USD. And this is just removing 1$ from deposits. So you have to invest 5.5M to take away 4320 $ of deposits per day. Nothing that a big vendor can't cover.
But this is where this attack will get impractical, creating an account "costs" 3 steem (it is not destroyed, just powered up on the new account, so effectively it's free). Which means that for 300 steem, about 1500 bucks, you get a system that requires an attacker to have half a billion worth of steem.
Thus rendering this attack unscalable.
Well yes, your [1] is correct but in this instance they steal from the poor to prevent them to give to the rich :p
So you could call this "security by cost-effectiveness considerations" :D
Thanks for the detailed explanation.
You're very welcome ! Thank you for challenging the system, it helped me find and fix some flaws :p