You are viewing a single comment's thread from:

RE: Proposal to Change $HIVE at the Blockchain Level

in #proposal3 months ago

I think there is no need to modify the Hive at the blockchain level as there is max_accepted_payout. This parameter can be set between 0 and 1000000 HBD.

For short-form content, this parameter could be set to 1-5 HBD and the post payout will not exceed this. Everything above this threshold will be returned to the reward pool.

You can see here how it looks when the parameter set to 1 HBD:
https://peakd.com/hive-174578/@abitcoinskeptic/experimenting-with-max-accepted-payout

When auto voters are checking this parameter, it can be used to mark a post as short-form content.

Sort:  

@nathansenn just informed me of a major flaw in the max_payout route @holdger08.

Users would be able to post to our Community & DAPP from 3rd party front-ends like Hive.Blog and @peakd with those Posts (Buzz's) being exempted from the max_payout code that we hardcode into our DAPP.

Users would then be incentivised to post to our DAPP from 3rd party front-ends and our real users would be punished by being restricted by in-house rules that are not applied to Buzz's posted from 3rd party front-ends.

Please review the proposal above and the issue more in-depth and comment accordingly @holger08.

3rd party front-ends as @peakd and hive.blog could be easily updated so that they allow setting of may_payout during posting.

E.g. @peakd could add a new option here to allow D.BUZZ content:
image.png

Hive.blog could also be updated and a new option for D.BUZZ content could be added here:
image.png

@peakd and hive.blog are already using max_accepted_payout, just an option to set a value higher than 0 HBD needs to be added.

edit: For implementation at @peakd and hive.blog, there should be an agreement about the value of max_accepted_payout for D.BUZZ, so that only a new option in the drop-down menu is needed.

That would be a temporary fix, and would require politics since new Dapps could arise that would launch without that "fix".

Then there would have to be a call to action by the community each time a new DAPP launches to pressure the newly launched DAPP to also instate that "fix".

Even if we solve this with temporary front-end fixes, don't you think we should also solve it at the blockchain level, once and for all?

Assuming a D.BUZZ post needs to have max_accepted_payout=1 HBD. This would mean:

  • all posts that have max_accepted_payout set to 1 HBD are D.BUZZ posts, no matter on which frond-end the post was written
  • all posts that do not have max_accepted_payout` equal to 1 HBD are not a D.BUZZ post.

My proposed changes are not temporary frond-end fixes. Agreement if a post is a D.BUZZ post is already defined at blockchain level. There is no way to cheat, either a post has the correct value for max_accepted_payout or not.

all posts that have max_accepted_payout set to 1 HBD are D.BUZZ posts, no matter on which frond-end the post was written

all posts that do not have max_accepted_payout` equal to 1 HBD are not a D.BUZZ post.

If you or someone else that is more connected in the HIVE community can get Hive.Blog and @peakd to implement this change, of setting the max payout for posts published to the DBuzz Community to $1, please make it happen.

It would still be a temporary and somewhat messy fix since DAPPs could still launch, even tiny ones that are bootstrapped as simple services to game the system.

I believe if you were us or another DAPP wanting to offer a reliable service without interruption from rogue actors, you'd be interested in code that made it impossible to game the max_accepted_payout as opposed to relying on verbal agreements with others, and the belief that everyone else in the future would agree to those agreements too.

My proposed changes are not temporary frond-end fixes. Agreement if a post is a D.BUZZ post is already defined at blockchain level. There is no way to cheat, either a post has the correct value for max_accepted_payout or not.

There is a way to cheat..

  1. Fork Hive.Blog and publish to our community without the max_accepted_payout code included in our community of the forked front-end.

All of the posts published in our D.Buzz Community reflect onto our site so the posts published to that forked front-end would not be constrained to $1.00 payouts and would therefore trend higher than our real users who posted from D.Buzz.

Not sure you are really understanding how the blockchain works though. The frontend doesnt matter. Holger is saying that you should check the max_accepted_payout before considering the post as a valid DBuzz post. You also don't need to use Hive.blog or any other frontend to post to a community.

So if your website shows all posts in your community, that literally just means it is showing all posts with the category hive-xxxxx where xxxxx is your community number.

Not sure you are really understanding how the blockchain works though. The frontend doesnt matter. Holger is saying that you should check the max_accepted_payout before considering the post as a valid DBuzz post.

  1. Ah.. checking to ensure that the max_accepted_payout was $1.00 would block any rogue actors from posting to our DAPP since we would filter those out by checking.

  2. It sounds like the only issue now is how to get Hive.Blog and @peakd to set the max payouts in our D.Buzz Community to $1.00, right?

You also don't need to use Hive.blog or any other frontend to post to a community.

People won't need to use Hive.Blog or @peakd to post to our community but we want them to be able to use both to post to our community so that our users will have more options.

I assume you mean there could arise a new service that allows posts without setting max_accepted_payout ? That problem will be solved with SMT (smart media token), there is no need to ask now for a different solution at blockchain level.

Until our venture produces a sizable profit for a long length of time, we won't even consider issuing an SMT.

It wouldn't be in the interest of the people who'd buy our token, nor would it be in our interest to issue a token as a small business.


Some DAPPs like ours are / will be interested in building a HIVE based DAPP without the commitment of issuing their own token / SMT.

For ventures like us, SMTs won't help since we want to focus on using the $HIVE token.

I also think you are under estimating how fast a rogue act could and might launch a bootstrapped service to publish posts in our DBuzz Community without the $1.00 max_accepted_payout measure.

Communities allow moderation what's the concern?
Check the post see if it has a max_payout if it doesn't ... mute it.

There is a major flaw in trying to use the max_payout to solve this problem.

Users would be able to post to our Community & DAPP from 3rd party front-ends like Hive.Blog and @peakd with those Posts (Buzz's) being exempted from the max_payout code that we hardcode into our DAPP.

Users would then be incentivised to post to our DAPP from 3rd party front-ends and our real users would be punished by being restricted by in-house rules that are not applied to Buzz's posted from 3rd party front-ends.

Please review the proposal above and the issue more in-depth and comment accordingly @holger08.

This sounds excellent.

As it turns out, the max_accepted_payout route would not work, here's why:

@nathansenn just informed me of a major flaw in the max_payout route @holdger08.

Users would be able to post to our Community & DAPP from 3rd party front-ends like Hive.Blog and @peakd with those Posts (Buzz's) being exempted from the max_payout code that we hardcode into our DAPP.

Users would then be incentivised to post to our DAPP from 3rd party front-ends and our real users would be punished by being restricted by in-house rules that are not applied to Buzz's posted from 3rd party front-ends.

Please help us bring attention to this proposal.. I think it's the only fix and a much needed one at that. Otherwise Dapps like us would also be forced to get involved in politics and in vain when the solution really lies in solving this at the blockchain level @brianoflondon.

This is what I was about to type in when I read the proposal.

It seems like the max_payout would work, but it wouldn't and here's why:

Users would be able to post to our Community & DAPP from 3rd party front-ends like Hive.Blog and @peakd with those Posts (Buzz's) being exempted from the max_payout code that we hardcode into our DAPP.

Users would then be incentivised to post to our DAPP from 3rd party front-ends and our real users would be punished by being restricted by in-house rules that are not applied to Buzz's posted from 3rd party front-ends.

Please consider the above scenario and comment / share accordingly.

Thank you for also sharing, and for being in favor of using the max_payout feature to prevent abuse.

Your feedback helps!