Limit to sidestake and possible to rotate or random selection

[47an]

Issue are on the limit and possible way to increase it then the client handle it now. It detect all sidestake for now but stuck to share on first 6 in lines. A way to handle more in
queue without user changes to inactive others lines or restart client.

From discord chat of section to this topic:
Would it be possible to increase unit of sidestake addresses on each side from 6 to 10?

Not aware of the limit in block but hard to think that that would hit limit in size. For the staker it would be split to minimum 1 GRC on CBR and possible POR in it. Would it be to low and considered as dust or a way to avoid fee?
If there would be a trouble to increase this limit it might be possible to make client to handle long list of sidestake. So let say you have put 12 addresses it would take first 6 in order then then move to other 6 in list and so on? It would work be great to expand it this without limit or abuse.

RoboticmindYesterday at 11:23 PM
Have to check but isn't the limit 8 side stakes?

CruncherYesterday at 11:24 PM
i got 6 as limit and it is shared to splitstake

RoboticmindYesterday at 11:24 PM
Oh if you're splitting that will take up one/multiple of the outputs yeah

Barton26Yesterday at 11:25 PM
there are a maximum of 8 vouts on a stake. 1 is used for paying the staker, so that leaves 7. One is generally reserved for splitting, and the other 6 are side stakes

RoboticmindYesterday at 11:25 PM
Sorry meant 8 outputs

Barton26Yesterday at 11:25 PM
increasing above 8 (7 really) would require a hard fork
@cruncher

CruncherYesterday at 11:26 PM
ok thx for info.

Barton26Yesterday at 11:27 PM
@jim Owens is your man here, for further clarification I defer to him

CruncherYesterday at 11:27 PM
But would it be a trouble then a mandatory to change it.
yea his the man for it. I would like to see possiblity to it and it would not be interupt blocks rules or be abused of any way.
As a possible way it could follow a list rule in order to cover each sidestake line client got to avoid changes to handle tx and block.
I have 12 lines to sidestake to share 10% on each and see that client is stuck on first 6 of listed.

ypsilon97Yesterday at 11:34 PM
I remember reading somewhere that the limit was deliberately low to avoid dusting the network
Another option to handle >6 sidestake lines would be to randomly select 6 of them on each stake

CruncherYesterday at 11:35 PM
yea i think of abuse to send as "dust". That way i think of limit of 10 as max to each block/stake.
so 1 GRC need to be shared as min. I got hard to think that would be called as dust.
Staker would take in own block and could be used to avoid to fee but it would be still be 1 GRC
It would add from POR if any in RR.
If there is any on block it safe to make it to follow an order in list
That would avoid change on current sidestake and follow same rules existed.
It would also open up to reduce to 3 sidestake if needed later on if abused/needed

ypsilon97Yesterday at 11:44 PM
Well, you could make it rotate through the sidestake list on each stake, but that's not really much better than random selection and might be harder to implement (you'd have to come up with a way to remember the current position in your list)

CruncherYesterday at 11:49 PM
As i do now i have a list of 12 GRCaddresses and wallet detected all but stuck on first 6. So in stake it use my own address followed by 6 sidestake to be able to use other in line to rotate it i use # infront line to inactive first 6 lines. This require a me to change and also restart wallet as "re-read config". Have no success to use rpc command to make changes on this to avoid a restart.
Wallet detect it so a change may be better to rotate on list in config might be possible.
It would/could open up to a unlimited lines if so and also avoid changes to basic rules and work to wider share on sidestake then it is now.

ypsilon97Yesterday at 11:55 PM
Agreed. But I still think random selection would be preferable to rotation.

CruncherYesterday at 11:56 PM
I bet that would hard to code a "random" selection. Nothing is really random.
And it open uneven share in short/long term of use

ypsilon97Yesterday at 11:58 PM
Haha, of course nothing is truly random. But if we have enough entropy to make private key generation random enough to be cryptographically secure, it will surely be enough to select some entries from a list 😄

CruncherYesterday at 11:59 PM
yea fair enough there are ways to use some sort of random but hard work to get that in code.

ypsilon97Today at 12:00 AM
And it open uneven share in short/long term of use
Right, but it wouldn't be better when rotating. Remember the staking intervals are heavily fluctuating.
Of course it would even out with time, but so would the random selection

CruncherToday at 12:02 AM
Stakeing are some sort of experienced of random but based on several rules and on top of end up as probabilty. Follow the line it well get on balance used.

ypsilon97Today at 12:03 AM
If you'd want to make it really fair, you could make a local "accounting table" that keeps track of how much each address is "owed" and pays the 6 addresses with the highest "debt". But that seems overkill ^^

Barton26Today at 12:05 AM
we can reach randomness you'd never notice, I can assure you
this is crypto

CruncherToday at 12:06 AM
Yea trouble is that i use a mix 3 first is service then it would follow other diffrent size of wallets. My goal would be to follow rule of 10% each even.
My share would not be much from CBR so a longer term from a mix of CBR+POR would gain good amount and would share to more then 6 highest prio target on list.

Jim OwensToday at 12:09 AM
The current output limit on the coinstake is 8. One must be empty by protocol. That leaves seven. One must be reserved for the return to the staker, that leaves a maximum of six sidestake entries. The current algorithm goes in order of the entries in the config, and ignores anything that pushes the total percentage above 100% of the reward or >6.

Barton26Today at 12:09 AM
ah my apologies for misinformation 😐

Jim OwensToday at 12:10 AM
The sidestake and stake splitting share the space, with sidestaking taking priority.

CruncherToday at 12:10 AM
From a mainet i got 1 of my own stake address followed by 6 to sidestake

Jim OwensToday at 12:10 AM
So if you do six sidestakes, you can't do stake-splitting.
(Even if you set the flag equal to 1.)
I am not adamantly opposed to raising the output limit a little in the next mandatory, but we cannot overdue it, because the outputs on the coinstake are not subject to fees... in fact the staker is getting a free ride on the network with these and also collecting the fees from the other transactions.
I am not particularly worried about "dust" per se, as the algorithm also prevents sending anything smaller than 0.01 GRC to a sidestake entry.
I am paying attention to txleveldb growth and blk0001.dat growth due to more and more UTXO's...

CruncherToday at 12:13 AM
Yea could think of that be an issue so avoid that would be possible to rotate a list as client detect all listed sidestakes?

Jim OwensToday at 12:15 AM
It is actually probably easier to do random selection than rotation, and the appropriate random selection algorithm over a large number of stakes would be equivalent to having all of the entries sidestakeable, because the probability distribution would be uniform.

CruncherToday at 12:17 AM
Getting hard hard to belive a random selection would more simple then follow a a list of lines. Would it really be better to random selection?

Jim OwensToday at 12:17 AM
The application is multithreaded and I need to protect the counter with a lock to be safe.
Although a scoped variable right at the top of the miner loop might be ok.

ypsilon97Today at 12:18 AM
There are already utility functions for random selection in the code, so it shouldn't be hard to apply them to the list of sidestaking entries, right?

Jim OwensToday at 12:19 AM
Everything in crypto is about randomness..... we have zillions of options there... a rotation loop is also pretty simple as long as only a single thread will be accessing it.
The selection algorithm is a totally leisure code issue. Upping the output limit on the coinstake requires a mandatory.
Thinking about it, the rotation method may be a bit easier, looking at miner.cpp.
Anyway.... the core devs will discuss this wrt to the coinstake output limit. It may be better to leave the limit alone and just implement the rotation scheme.
The principle problem with the rotation scheme is that it will not survive a restart.

ypsilon97Today at 12:22 AM
But wouldn't you have to store the current list position somewhere to avoid the first addresses being prioritized when restarting the wallet?

CruncherToday at 12:22 AM
ok thanks for info. It is more deep into this random and use a rotate on top would help to not get into this crypto algorithms.

Jim OwensToday at 12:22 AM
Seldom stakers will have restarts in between the stakes, and so the rotation will fall apart.

ypsilon97Today at 12:22 AM
Oh yeah, that's exactly what I was thinking...

Jim OwensToday at 12:23 AM
@ypsilon97 that requires on disk state management of the counter, and definitely makes the random approach much easier...
You don't need rotate and random. If you use a uniform random distribution then all entries will be selected an equal number of times over a large number of stakes...
If you allow up to 6 random choices at a time, you DO want to ensure that the random selection of the six does not have two selections of the same entry in the group. That is probably the only refinement you need.This is a pretty good idea. Does someone want to cut and paste the above conversation into a github issue for me?

ypsilon97Today at 12:28 AM
You could just std::random_shuffle() the list before selecting the first 6 entries, right?

Jim OwensToday at 12:29 AM
That is exactly right.
It is almost trivial.

[jamescowens]

This is actually a very good idea. I am assigning it to myself, since I wrote the original sidestaking/stakesplitting code. I believe the right way to do this is random selection if the number of sidestakes exceeds six which makes this entirely leisure, rather than increasing the number of outputs on the coinstake, which requires a mandatory. We also have to be mindful of the current vision for the design of MRC, which will also use coinstake outputs. So we will probably raise the output limit a little in Fern, but the increased limit will not be available for sidestaking.

[47an]

Thanks, shuffle would be great for this.