If you stack with a pool and the pool has 13M STX and the threshold moves from 130k to 140k. Now the pool has also lost 1 slot, but individual pool participants have only lost about 1% instead of 10%. So capital efficiency does actually improve dramatically with well capitalized stacking pools.
Of course for most people this discussion is academic anyway, since only a tiny number of people are willing and able to put the $60k+ to stack through the protocol. For them pools are the only option.
Yes and a 1% loss is a pretty big loss for such a large pool. For anyone who wants to stack on their own, the loss is much greater.
You and I are basically agreeing that all pool participants in a 13M stx pool can get 1% more rewards by fixing the slot size. That seems very attractive to me.
If it’s possible to do it without breaking anything else then I agree! The original post didn’t acknowledge why the system was built like it was or any tradeoffs the original design was making, but if doing this
leads to more efficient stacking cycles with no unintended side effects then that sounds great!
Yes I think we should seriously explore giving miners different recipient addresses in each block. It would open up a lot of possibilities.
I’m curious about whether or not this is possible without dramatically incentivizing bad behavior on the part of miners. The most “naive” way to implement something like this would be to pick 4 addresses from the reward set at each block (rather than the 2 currently done) using the cryptographic sortition, and then using the miner’s address as a random input to select which of the two addresses they would send to. However, miners can change their addresses, especially when incentivized to do so, and they would be in this case: they could prefer selection of certain reward addresses over others (i.e., ones they control or are paid to receive from). Other mechanisms for doing this per-miner selection may not be susceptible to this, but it’s not obvious to me that such mechanisms exist.
Moving it from 2 to 4 slots per block actually solves the issue until 1.5B stx, and moving it to 6 solves the issue until 2B stx.
Modifying the number of slots in the reward cycle as a mechanism for dynamic change could work. If the threshold is fixed at 100k, and the length of cycles is 2000, then the number of slots per block could dynamically change from 2 to 3 to 4, etc., as necessary to include every slot. However, increasing the number of slots per transaction does have a real impact on the size of the miner’s transactions, and therefore the amount of “loss” due to bitcoin fees, which directly impacts the profitability of mining. This is a real trade-off: fees would increase 20-50% depending on how many new slots there are.
In general, I would be open to bigger proposed changes than the ones currently proposed in SIP-015. However, I’m pretty wary of adding these items to SIP-015 myself: the implementation impacts of some of the things proposed in this forum thread are large, and I don’t fully understand all of the consequences of what’s proposed here. There are ways to address those concerns, but they will take time.
What I’d recommend is first trying to figure out whether or not any of these mechanisms could be compatible with SIP-015’s PoX contract-- that is, that the changes could be proposed in a subsequent SIP, and implemented as a future hard fork if there’s sufficient support without requiring a new PoX contract entirely: one of the painful parts of SIP-015 is that it requires a new PoX contract pox-2, which users and pools will need to migrate to. Having to do that another time would add a lot of pain to subsequent proposals and could jeopardize support for them (or maybe not, if there’s sufficient demand for those features). Then, if you have a specific proposal, with fleshed out details, then you should solicit feedback for that. This forum thread is hard to follow, and it’s hard to figure what is specifically being proposed. In responding to various comments, there seem to be changes suggested, and it ends up not being clear exactly what the final design would be. Some of that may just be because a forum thread isn’t a great tool for these kinds of discussions. I prefer github discussion posts for this reason: you can create threads within the thread.
Ok thanks Aaron, this all makes sense, I can take this feedback into account and draft a concrete and updated version of the proposal.
@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.
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.
That’s right @patrick we have empirical data on:
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.
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 Work section 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.
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!
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.
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.
