You are viewing a single comment's thread from:

RE: A system to pay for everything with upvotes

in #steem7 years ago

This leaves almost no time for someone to flag your upvote

That's true, but there is still the possibility that someone with a lot of SP writes a bot that always downvotes such a comment that is close to payout (even within the 12 hour limit), so the vendor is not guaranteed to receive the money, which makes it always risky for them to offer such a service.

I mean I find the idea quite nice, but in practice there are also not that many people who can pay for even simple things like a $2 coffee with an upvote. If we want to bring Steem into the "real world" of payments, I guess memos are the way to go.

Sort:  

hat's true, but there is still the possibility that someone with a lot of SP writes a bot that always downvotes such a comment that is close to payout

Yes but why would you do that ? I mean it's a huge waste of voting power. And if they start doing that it's fairly easy to migrate the system to another account, imagine if you have 10-20 accounts to handle creating comments all the time, the bot won't be able to keep up either in terms of voting power or in terms of votes per minute.

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 mean I find the idea quite nice, but in practice there are also not that many people who can pay for even simple things like a $2 coffee with an upvote.

Yes it's not a system that's for minnows, or they would have to load up the account over the course of several days to actually be able to spend money on it.

If we want to bring Steem into the "real world" of payments, I guess memos are the way to go.

I aggree that it's obvious that this system is complicated for a task that's relatively system in the cryptocurrency world aka sending money to buy things.

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 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.

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?

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.

Good question: e.g. competitors, who want to diminish the reward of a vendor or "modern day Robin Hoods"

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