Ok thanks Aaron, this all makes sense, I can take this feedback into account and draft a concrete and updated version of the proposal.
1 Like
@shea256 Thanks for starting this thread!
Besides all the great points that have already made, I wanted to add another perspective. Perhaps stating the obvious, but IMO worth repeating. As an ecosystem, we do have a extremely scarce resource: the number of people who understand the current Stacks blockchain implementation well enough to pressure-test any proposed changes and actually implement them.
Addressing that bottleneck is critical, but out of scope for this thread. But until then, proposals inevitably will compete with other priorities for attention and resources.
Lots of great opinions here, but we’re missing meaningful data to make an evidence-based decision. As Patrick and others noted, collecting some data seems like a good, concrete next step.
Meanwhile, I can pile on my own opinion FWIW 
relative to other concerns (like healthy mining), and considering Stacking improvements already implemented, I’m not sure how much of an impact the additional Stacking improvements proposed here would make. Anecdotally, it just doesn’t seem like that big of a concern amongst stackers.
Again, not saying it isn’t important, but is it urgent enough to take resources away from other issues? Not sure.
3 Likes
Thanks Diwaker!
Yes to be clear I am not presenting this to focus on a prioritization of sips or a timeline for implementation.
First, I want us to recognize that there is a real problem. Other blockchains have better staking ux’es and that’s a fact. The more we’re on the same page here I think the more productive this conversation will be.
Second, I want us to brainstorm solutions. To me, there can be a little tension that imo is not open minded enough or giving the proposals enough light of day.
Third, if we agree on a problem and a solution, that still doesn’t mean it’ll have priority over other sips or will have a plan for implementation. I’m perfectly fine with people saying “we agree this is better but this goes in the queue and we’ll have to see when it can be implemented, nothing planned for the next release.” If additional development resources are needed then I would say we should hire more core developers and perhaps I will go ahead and hire one myself.
From what I read from Patrick he was saying there is quite a bit of data in the form of frustrated stackers. Going through the discord and searching for key terms yields ample complaints and confusion.
1 Like
That’s right @patrick we have empirical data on:
- Kick-outs for being under the slot minimum
- Partial kick-outs for being over the slot minimum but not being a whole number multiple of the slot minimum
All this data can be collected and is an empirical measure of capital lost and the frustration that comes with it.
One can even analyze how many of those addresses came back to stack and how quickly they did so.
These are metrics aside from interviewing people.
I wouldn’t say “people aren’t complaining” because they often suffer in silence with things like this and/or simply accept the UX shortcomings or the ones who are fed up leave and go to another chain. Those that leave won’t say anything.
And of course as I mentioned before the other piece of data is the complaints and confusion in the stacking channel of the discord that goes way back.
But ultimately I think the best data is the kick-out data, and reducing the kick-outs as much as possible should be a goal in my opinion.
Last, I’d caution against sunk costs of existing solutions. I don’t want to throw a wrench in anyone’s plans but we should approach these solutions with an open mind and not factor in whether one solution has already been started or not. Let’s first figure out what the best solution is and then implement it. If there are clear problems with any solution, we will ditch it and move forward.
1 Like
If these remarks were directed at my pushback, then let me assure you that if you had presented an improvement to Stacking that I believed was viable, I would not only be happy to shepherd it through the SIP process, but also I’d volunteer to implement it myself if you hadn’t already.
I agree with @diwaker that you need data to back up your claims. In general, you need to show that this is the best possible solution of all current alternatives (including doing nothing). All SIPs must do this for the problems the propose to solve, especially if the supersede prior work. I expect a much higher degree of rigor than what you have presented here.
At a minimum, I’d expect the SIP to do the following:
-
Demonstrate the severity of this problem on yield. If you claim that stacking today is not as economically efficient as it could be, then you should present data to argue your case. How much BTC would Stackers have stood to gain, had your proposal been implemented on day 1? We modeled out the current system before launching it, and verified that it produced the yields we expected given the prices of BTC and STX.
-
Demonstrate the severity of this problem on user perception. If you claim that a significant problem here is the user experience, then you should show it with experimental data. You will need to interview users, and present your interview methods, to demonstrate that your changes improve the Stacking user experience (and moreover, explain why these improvements in particular, and not the state-of-the-art alternatives, are the superior solution). “My friends don’t like it” and “Many people are saying” are not sufficient. Granted, you have a harder job here than SIP-007 (which did not conduct this study before launch), but SIP-007 has proven its mettle in production, while yours has not. STX has non-zero value, it is traded widely, and people regularly stack it. We need to see evidence that your solution will do better (or at least do no worse).
-
Demonstrate that your solution is at least as incentive-compatible with building the canonical chain as the current stacking system. Changes like this tend to have side-effects that are not obvious at first glance. You should quantify, algebraically, what the new miner and stacker strategies are with these changes, and show that miners and stackers will take actions that are no worse for the chain quality than the actions they take today. We hired PRISM to perform an economic audit of the current system, for example (and through that audit were able to quantify the perils of discount-mining). You should do something similar.
-
Enumerate state-of-the-art alternatives that also work to address this solution, and rigorously show that your solution is superior in all of the metrics that you claim to be improving (i.e. the two above). The SIP format has a
Related Worksection for this very purpose. -
Present a sample implementation – e.g. a live testnet with the change applied – so the reviewers and public commentators can try it out for themselves. The implementation will eventually need to be audited by a security firm before the SIP is ratified. We did both for SIP-007.
I’ll be happy to take another look, but only after you have the makings of an actual SIP. I unfortunately do not have time to continue brainstorming.
2 Likes
Makes way more sense at this stage to just get the data on knockouts and decide whether it’s significant enough to continue the discussion.
Btw the 3rd party costs listed above are like $100k. Lucky I get to talk to you for an hour every week for free!
1 Like
If this advances to a SIP, and if the authors feel that they need to reach out to a 3rd party auditor instead of providing the analysis themselves (either way is fine, as long as it is correct and complete), then the Stacks Foundation would be happy to review a grant proposal for doing so.
My general point here is that a proposal to supersede SIP-007 should receive at least same amount of rigorous consideration that SIP-007 did. Ideally, we’d be more rigorous this time, and expect the proposal to make significant improvements, because replacing the running implementation is both harder and riskier than starting fresh. There should be a very, very high bar to replacing something as fundamental to Stacks as stacking.
2 Likes
Hey looks like I received quite the response here so I’ll be responding in multiple parts.
First, I’ll be posting some examples of stackers who are confused or frustrated with the user experience.
Later, I’ll post a quantitative analysis of the funds lost do to the variable stacking threshold.
I can only post 5 photos at a time, so I’ll be separating my screenshots of conversations into multiple posts.
1 Like
Thank you for gathering some preliminary data. A couple observations:
-
The majority of these comments were from the first few months of the system’s lifetime, where there is bound to be confusion and frustration inherent to getting used to a new system’s way of doing things.
-
The comments from the last 8 months (i.e. since October 2021) indicate an understanding of the problem that is consistent with the solutions of providing the ability to “top off” one’s STX holdings (this is slated for 2.1), clawing back the unused STX (also slated for 2.1), and using stacking pools (available today). One of these comments indicates a profound misunderstanding of how Stacks works (i.e. Stacks has no “validators”).
1 Like
To the community:
I’ll be continuing to post data here to illustrate the severity of the problem.
I will use this thread as a place to continue collecting data and analysis and will culminate with the drafting of a formal SIP.
This thread was never meant to be a formal SIP but rather simply the posting of the initial description of the proposal so that we could facilitate a discussion.
Stay tuned everyone!
And if you have other examples of stacking frustration I encourage you to post them as well.
1 Like
A quick note:
There’s a trap with this topic that I think some can fall into which is essentially:
“Use a pool, be a whale with 10M+ STX, or pound sand.”
(The pools have low variance and so do the big whales, but anyone who wants to stack on their own with less than 10M STX will receive pretty big percent losses in Stacking rewards)
To me this is unacceptable and I hope we can approach this topic with a clear mind and see the problem for what it is, then take it seriously and solve it.
1 Like
@diwaker @aaron Loved your responses earlier. Would be great to know what you think about the issues and data presented. Will circle back and keep providing more analysis.
I’m sensing some hostility here. No one is telling anyone to “pound sand,” nor is anyone claiming that these are the only two options. I would appreciate it if you would refrain from putting words in other peoples’ mouths.
Please do not mistake my and other peoples’ requests for rigor as outright dismissal, because (in my case at least) they are not. Like @aaron, I’m totally fine with making large-scale changes to stacking if (1) doing so doesn’t cause other, worse problems, (2) doing so materially improves stacking, and (3) the community wants the changes badly enough to warrant prioritizing them over the myriad of alternative approaches (keeping in mind that blockchain engineering person-hours are a very scarce resource). All of these criteria are falsifiable, and if they can each be conclusively met, then the SIP can and should advance. It is your job as the SIP author to make sure that they are met. Moreover, SIP-007 got the same treatment as this hypothetical SIP would receive, so there’s precedent for a rigorous approach – your proposal is not being singled out here.
I am sorry if you felt like you were being dismissed, because that was not my intention. I’m merely holding your proposal to the same standard that I have held the other SIPs to. As for the meat of this proposal, I’m neither a “yes” nor a “no” on this, as there are still too many unknown-unknowns for me to have formed an opinion. Rest assured that if I was a hard-“no” on something, I’d be very up-front about it
Little update:
Some community members offered to put together comprehensive data on losses due to the current Stacking model.
Will post when we have it collated.
Stay tuned!
2 Likes