RE: I opened a protocol PR: scale DHF payouts when HBD printing is suppressed
You are viewing a single comment's thread:
I don't think there's a crossed wire about the proposal mechanism itself. It was obvious in the original proposal that it was a mechanism to cut DHF spending. It's the justification that was used that made no sense, IMO.
The post suggests that the hbd_print_rate was made to reduce spending, but that a backdoor (or loophole) was left that caused it not to reduce spending for the DHF. But this is strictly not true: the hbd_print_rate does not reduce spending, nor was it intended to do so. It just switches payments for posts from HBD to Hive (the posts continue to receive the same value).
And I completely disagree with the concept of cutting pay in the manner suggested. It cuts across all proposals without differentiating between the different things being funded.
For example, it would equally cut across a single person who was primarily doing the work out of idealism but can afford to take a pay cut, a group of programmers who are paid by such a person (who will not willing take such a pay cut, but will simply find other work), and a proposal like the HBD stabilizer which generally speaking earns money for the DHF
The only way to adjust for this arbitrary cut in pay would then be to create and vote on more proposals to make reasonable adjustments. But this shows the basic uselessness of the proposed change: the same effect of the proposal can be done already simply by unfunding current proposals and voting in ones that pay more or less.
The only time the proposal is uniquely effective is when the rate is dropping down to near zero, at which point it becomes impossible to pay for anything, no matter what stakeholders want to do (short of yet another hardfork to eliminate or workaround it). But hardforks are one of the most costly and risky means of making adjustments and they are also more time-consuming to enact.
That is the circuit breaker you have.
I am proposing a circuit breaker that kicks in before zero and is programatically predictable.
You propose people to buy HIVE and unite to defund proposals, that creates social chaos because it generates disagreements. Having a programatic features to defund makes it predictable and no one has to argue and fight against projects they use and love but know they can't afford.
I wrote a lot here and deleted. I am tired, boss.
Your point on
hbd_print_rateis technically true. Not worth going over again why economically it is nonse due to the DHF, which BTW has value, it is just unnafordable in current market conditions in any token it could pay.Side point: I don't think there's any need for people to buy Hive to defund proposals. I just pointed that is the primary mechanism we have now: stakeholders vote, and the more they hold, the more their vote counts. In other words, there is a clear mechanism for anyone who wants to have more influence in votes (this point was made to address your two-class argument).
But right now most of the DHF proposals are already getting defunded. Certainly faster than we could get a hardfork through that programatically prevents spending. The biggest proposal by far still getting funded is the HBD stabilizer, and it would be complete idiocy to programmatically defund that, IMO, since it actually earns money for Hive.
And if it turns out stakeholders then change their mind and decide they do want to spend, they would be stuck waiting for yet another hardfork to be able to spend again.
The whole proposed mechanism is a bad idea, IMO.
Ok, I read through various posts and it seemed like some threads were interpreting the change in a different way and responding in ways that weren't really relevant.
My take is that, regardless of the intended purpose of the hbd_print_rate param, the idea being presented is to reduce spending from the DHF under 'stressful' circumstances for the economy.
So, yes, the intended idea adds a new use to this param (but I appreciate that Igor's words made it sound like something else) - I'm just going by the code. It may be that the proposed mechanism is poor compared to more deeply considered alternatives.
I am somewhat neutral on the proposal because I think the DHF will continue to be largely dysfunctional unless it is replaced/upgraded by a system that is more aligned with the way corporations handle works tasks - tenders and accountability. Everything else is likely going to just be a bandaid on a leaky sieve.