RE: Wanna help test RC delegations ? Here's all you need to know

[howo]

It's because you can only have a finite amount of inbound delegations (for performance reasons). So if there was no whitelist someone could send 1 rc to everyone and completely block you from getting any other delegation.

There was other ideas like being able to "undelegate" as a user but ultimately that was the decision that was done in the original design so I didn't change it since they probably had good reasons. maybe we'll revisit it in a future hard fork if slots prove to be too cumbersome.

Comments

[yabapmatt]

That makes sense, thanks for the response!

[asgarth]

I'm trying to catch up on this discussion and this thread caught my attention :)
Having the user to 'open' the slot before the delegation will work from my point of view, but maybe worth considering also the following options:

1. each user can have max 3 delegations at a time
2. every time a new RC delegation is done we check if there is an empty slot for the receiver
   2a. if an empty slot is available just use it
   2b. if all slots are full the delegation with the lower amount is removed and the new one is accepted

[howo]

it's tricky to do 2b because you can overdelegate so it's hard to tell if an incoming delegation is "better" than the existing ones. For instance I could delegate 1m rc to you but my pool is empty so your existing slot gets replaced even though the new one is not better.

[asgarth]

Fair point. We just need to be sure that when an account ran out of RC (or most of it) there is still enough to cast the set_slot_delegator trx. Hopefully that trx will cost almost nothing

[howo]

Yeah it costs very little, but also this is where other accounts can set your slot for you, the account creator can change your slot 1 and your recovery partner can change your slot 2.