You could consider it a burn yeah, I understand that it's not good for your use case where you'd want to delegate rc to every user that logs onto peakd and then undelegate after a time, it's important to not give rc back because it opens up a lot of edge cases where an user can trick the system into having more rc than before (the rc system is not that stable, and a rogue witness not having the rc plugin enabled could leverage that, while working on this feature I found a bug that would allow someone to get a lot of rc for free). Additionally giving the rc back opens up an attack where someone can delegate rc to an user, wait for him to have less rc than the delegation and then undelegate, which means it would drain all of the receiver rc (rc is fungible so there isn't a way to tell if rc given is delegated or not).
In regards to it being better or worse than a cooldown, it's better than a cooldown because your rc starts to regenerate immediately as opposed to hive power delegations where you can't do anything with the hive power that you undelegated until the end of the cooldown
Trying to think how we'll phrase it to users who use our site to delegate RC to others
First draft hopefully we can make it much shorter
cc @asgarth
Can you delegate RC that is delegated to you?
No
Also something interesting is that delegating RC requires only posting auth, so I envision a service where you can "lend" your RC, you give give posting auth to that service and it would do rc delegations on your behalf. I know I would be more than happy to lend my rc to help newcomers/dapps like peakd. Realistically a few dolphins or a whale could probably power tens of thousand of users
I have one more question. There is a need for "undelegation" at all?
I mean ..the delegator will start regenerating RC right away, so why "undelegation" is required?
Why cannot we consider the RC as "sent" instead of delegated? At least this will make the whole thing easier to think about.
It's because the RC is not "sent", when you delegate you give max RC and current RC.
Current rc is the rc you use (the actual unit). Max rc is what is used to define up to how much rc you can have and at what rate you regenerate those.
So if I delegate 100 rc to you, you can use those 100 rc (current rc) and then they will also regenerate on your account for as long as you have the delegation on you.
So the delegator won't in fact start regenerating the delegated RC until he undelegates. I don't know if I'm making sense, if not tell me I'll add more examples :)
Make sense. Probably would have been easier to understand (or at least seems easier to me) if the only thing involved was the 'current' one. So you 'gift' RC and soon after that you start regenerating it.
Basically regeneration would only happen on the RC owner account. Never on the account that receive it. Seems easier to understand because no 'undelegate' is required.
Just to confirm what you said. If you delegate 100 RC to me and you undelegate right away (let's say in the next block) will I still be able to use the 100 RC? And you will start regenerating?
No you won't be able to use the 100 RC, because his rc would go from 0 -> 100 -> 0
Basically I think you're thinking of this backward as a "I want to give 100 rc to everyone who logs in" as a short term thing, when feature is more ment for longer term delegations where you send rc to an user and he can use it, regenerate it, re-use it etc.
Got it, thanks 👍