They would be guaranteed to be paid, as I’ve mentioned above.
Keep in mind that with my proposal, everyone’s cash flow would increase by multiple percentage points.
We could collect some UX data for sure.
Yes I know very well and I’m suggesting it be increased beyond that.
Yes it would be in my proposal.
Yes agreed, and there are a few ways to accomplish this.
For me, the simplest way is to have a very basic static minimum of 200K STX and then have 4 payout addresses per block instead of 2 payout addresses per block.
Every address would be paid at least once in every single cycle.
And every stacker would receive an APY boost that is quite significant because they’d have full utilization of funds in the cycle.
I want to stress this more ^ The APY boost for small and large stackers alike is something that everyone should be interested in.
Then you’re giving up fixed-length reward cycles.
I can’t support doing that, because it would prevent us from addressing a far more serious concern having to do with dealing with the fall-out of a PoX anchor block getting mined, but not broadcast to the network until a much later date. Namely, making reward cycles variable-length makes two conflicting histories of reward cycles incomparable, which prevents the system from assessing which reward cycle represents more work. See this issue for details: Absent PoX anchors should be "forkable" · Issue #1805 · stacks-network/stacks-blockchain · GitHub
Do we need a UX study to know that losing money is painful? I’ve heard from a friend that getting knocked out from stacking happened to him and it was all the stacks he put in expecting yield and that was obv painful. Whether you get paid every two weeks or every 4 seems far more inconsequential.
The data on how many people get knocked out from would probably be faster and more broadly useful.
My bigger concern is the conflicting chain history one Jude had mentioned.
No you’re not. Please re-read.
No one is arguing that it isn’t. What is being argued is whether or not redesigning, reimplementing, and re-auditing a substantial portion of the system (which would likely take on the order of a year) is worth an as-yet-to-be-determined gain, when options exist today for your friend that would have solved his problem. Like, did your friend consider pooling?
First, you said you wanted to give up guaranteed payments:
And then you say that
Which one is it, @shea256?
My whole point is we can determine the actual level of pain by seeing how much stacks has been knocked out of stacking whether pooling or not by just looking directly at the data.
It’s pretty simple jude.
I said that we should give up on guaranteed payments if we have to pick one but that it’s even possible to not give that one up.
I reject your trilemma exists and assert we can have all three.
All that’s needed is to raise the slot threshold to 200k and increase the # of stackers per block from 2 to 4.
Boom. Trilemma solved.
100%, great point Patrick
Normies I know who stack are dumbfounded at how ridiculous the UX is.
It’s so much easier to stake on other chains.
Not sure how this is hard to recognize or agree on.
I think this and the related SIPs are coming from a good place and addressing real problems, but I don’t think protocol-level changes are the right way to solve them.
You have to keep in mind, the purpose of mining and stacking is to secure the network by providing the right economic incentives to mostly anonymous actors. The protocol must trade off some usability in order to accomplish that goal.
But we get that usability back by building on top of the protocol. We don’t need to change its fundamental design. Making really great trustless pools are how we fix miner decentralization and stacking UX.
This just isn’t true. The protocol does not need to tradeoff usability here. This is a defeatist attitude. Other chains have designed great staking ux’es and we can too.
Further, the UX issues can’t be solved with code on top. Either way you’re going to have a lower capital efficiency when you stack 1.3M stx and the threshold moves from 130k to 140k. Now you’ve lost 1 slot and you’re around 90% capital efficiency. You can’t solve that with higher level code and you can’t solve that with mining pools.
This will (a) double the cost of the block-commit transaction fee, and (b) kick the can down the road until the total amount stacked exceeds 745M STX. So no, trilemma not solved.
You can give different miners different receipt addresses and not double the fee.
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.
Trilemma solved (for the full # of stx in existence and at the same fees).
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.