I’ve now edited the proposal to incorporate the new solution and attempt to aggregate everyone’s analysis. There are still outstanding arguments for/against different solutions, but we’re at the stage now where we should poll the DAO’s voters to get a more tangible measure of their preferences.
The vote will start tomorrow morning 8am EST and last for 7 days.
https://gov.pokt.network/#/pokt-network/proposal/QmVx236YebmQzJm3JYbtEojRKRhhf2Jgr8PSFpmLAqvAF3
This proposal passed with 6 Approvals and 0 Rejections, so I’ll now close the topic.
https://gov.pokt.network/#/pokt-network/proposal/QmVx236YebmQzJm3JYbtEojRKRhhf2Jgr8PSFpmLAqvAF3
I’ve opened up this proposal for discussion again, although the proposal has passed per my above message, to allow for more discussion to take place in the same thread.
If someone wants to propose a new parameter change (e.g. to adopt a different strategy or revert this decision), they should publish it separately in the PUP category and link to this thread.
Hello there,
What are the exact parameters that were voted by the proposal ? Is it the parameters that were initially described by @Andrew ?
I’m struggling to synthesize the complete thread. Would it be possible to clarify that so we could communicate on it clearly to our clients and community ?
Thanks 
No. I edited the original proposal with the new parameters as well as synthesizing the complete thread so that you don’t have to.
Here is the comment where I announced that I was doing this
And here is where I left a note that the original proposal had been edited with Andrew’s consent
Your single source of truth is the latest version of the proposal at the top of this thread. It defines the parameters that were approved by the DAO for modification and synthesizes all of the arguments for/against the proposal.
I think we should discuss delaying and/or modifying the actions approved by this proposal.
TLDR:
1.) Shift the curve out by 1,000 (so that reductions begin at 4,000 not 3,000) and…
2.) Modify the MaxValidators param to 4,000 rather than 5000 ( so that nodes become service nodes sooner rather than later.
Reasons why we should consider this change:
1.) Recent changes in the P2P configurations associated with the RC-0.6.0 release have already caused a very noticeable improvement in block propagation and achievement of consensus. In fact, blocks are actually arriving early in many cases rather than late.
2.) The split between validator and service nodes (after 0.6.0 activation block) will -in itself- reduce the overhead associated with additional nodes.
3.) By my estimation based on conversations with persons who have coins that unlock on 5/15. We can reasonably expect 1,000+ nodes to attempt to join the network on or shortly after that date. As things stand right now… we could be in for a really ugly PR issue if 1 or 2 thousand nodes join at approximately the same time that the rewards go to near zero.
Agree with the fact that we should reevaluate this proposal with a new one. We’re currently drafting a position on the subject and will take part in the discussion shortly.
Thanks @BenVan for the initiative!
@BenVan, thanks for opening the debate on updating PUP4
Is it what you had in mind?
@JackALaing, what doesn’t seem clear to me is when and according to which criteria the PUP4 voted will be implemented by the DAO?
@Laszlo_Szabo I’m saying shift the curve in the top post out by 1,000 so that the “wall” is at 6,000 not 5,000 .
At that point … yes… there would be 4,000 validators and 2,000 service nodes running.
Hopefully, prior to that point we will have good data on how the growth from current to 5,000 has effected the network and what effect service nodes are having on overall operations. We may be able to abandon or further postpone this process if we are still good @5,000
We are inside the activation window and the Foundation has already been authorized/instructed to act.
If I am the only one here that wishes to stop this process, that is fine, I will shut up. But I’d like to know that other people besides myself have actually read this and understand what is about to happen.
My vote was not active in time to vote on PUP-4 but I agree. I would’ve voted against it.
I don’t believe it will dissuade any node runners from coming online in the short term. If they purchased and are waiting on vested pocket, I believe they will spin up the nodes regardless of PUP-4.
Peering towers, the split of validators and service nodes, and other improvements have likely made PUP-4 unnecessary
At the extreme ends of the curve, this proposal will unreasonably penalize node runners that have supported the network with good service since it’s inception
If you wrote a counter proposal to negate PUP-4, you would have my support.
Given the newfound P2P stability through config changes and community level peering efforts (like towers and sentries), it seems that the reward decrease schedule can be (at the very least) pushed later. I worry about unintended consequences of these param changes if it’s not mission critical (the latest observations at 3.5K Validators seem to suggest little P2P stress at this time).
If the three of you are in favor of negating this proposal, or at least swapping it for a less extreme solution, then I’m also in favor.
@BenVan to officially negate this proposal, we should publish a separate PUP and vote on that. If you’re happy to take the lead on authoring that proposal, I’d be happy to help you with any formatting questions you have.
Thanks Jack. Yes. Let’s move this to a vote. I’ll write a pup.
Thank you @BenVan for moving the conversation forward, we will contribute to the discussion following your proposal.
Thanks, @BenVan, for this explanation.
Ben, we will support you on this new proposal and vote to pass it to the DAO.@jack, thanks for this information! If I understood it well you are afraid of node providers launching as many nodes as they can, while giving a public date announcing when PUP4 will be effective right? Then why not giving a node number hard cap where PUP4 will be effective?
Sorry guys for the late answer, the last few days have been hectic.
