Isn't this the responsibility of each individual system though? They could also delegate Steem Power if they wanted to.
The systems are designed to allow users to create new accounts based on whatever the blockchain account creation fee is. If the account creation fee is not high enough to support 'normal' activity, then that is going to cause a problem.
If we are going down that path, then the solution to make it 'work' (without depending on a bunch of third party developers to know that they need to add extra / special logic) would be to force the right amount by raising the account creation fee.
I agree 100% that it is a problem that needs to be corrected. The main question though is what is the right approach to correct it :)
Personally, I am leaning towards increasing the max block size, but I am also treading down that path very carefully because I do not fully understand the implications.
If I understand the problem well enough, one possible solution, if it could be implemented without too much difficulty in a future fork, is to have a fractional reserve "pool" approach (which may be similar to what you're saying with a multiplier). Since not all users of a particular registrar (ie. steemit) will be online at the same time, users who have less than say 20SP can be extended up to 20SP towards bandwidth by "tapping into" the registrar's own SP reserve up to the designated limit set by each registrar.
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit
Interesting idea. That puts the responsibility on each registrar to ensure that pool isn't being abused by users they on-boarded to the blockchain. I could see some sane limits being needed to prevent abuse, but it does seem like an interesting approach.
It's also possible we're just seeing these issue now because of a big spike in the price of Steem combined with a lot of new users. If one or both of those were more stable, we might not have as much problems planning things out.
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit
that's what I meant with "users who have less than say 20SP can be extended up to 20SP towards bandwidth". So really, the worst "damage" any individual user could do to the registrar's total SP reserve is 20SP. And as a global variable set per registrar, they could always adjust that for all their delegated sub-accounts, or even more granularly on an individual basis if the need arises.
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit
Ah, I see. Yeah, I missed the "up to" limitation which would solve that issue nicely.
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit
I see what you mean, and I agree that keeps the solution simple for third-party developers. Maybe a good approach is recognizing a delegated Steem Power model is better for creating new accounts and under that model it's safer to introduce a multiplier to ensure the there's always plenty to go around (as it was before steemit made the change). If all onboarding systems took a similar approach, there would be less of a concern and it might end up being cheaper in the long run for those systems as they could just reclaim their SP for abandoned accounts.
If that makes the most sense to fix things quickly, I'd be ready to do it now (though I'm just a backup witness).
I also don't know the implications of changing the blocksize, but I do think it's something we should discuss with the experts before taking positions on.
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit
Yep, totally agree.
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit