user6552: I was thinking, why K parameter isn't a max cap? I mean, if a pool owner is affected by over delegation too, this could become an attack where I (as hypothetical attacker) can delegate 100M ADA through 1k wallets to a pool just to damage its rewards. I could let the other delegators to leave the targeted pool and after that I could quit the pool with all my wallets. While doing it, I will damage my rewards too, but still I could choose to do it consciously. Plus obviously it should work even if you got 63M ADA in your pool and I've got just 10M ADA or something. But however, if K would be a max cap I couldn't do that at all. There is any particular reason I'm not considering because pools can arrive to an over delegation?

user6360: Yes, it's a theoretical attack, but very expensive as noted by @zhekson. The evidence to date suggests the cost sufficiently mitigates.
In practice (other) delegators simply leave until saturation drops.

user6552: Thanks for your reply guys.
Yes indeed this kind of attack will impact your rewards and we all know it, but for me we should think in order to favourite the security and the fairness to all.
This attack is unlikely but it's still possible. I mean if you have 10-100M ADA to use for it, you could probably don't care about 1-2 months of loosing rewards.
Regarding a pool owner, if your K is attacked often your delegators can choose to change their pool to never come back, they are not forced to delegate always the same pool so I can potentially attack your K a few times and you are potentially going to loose some\many delegators forever because of it.
Regarding the delegators, now we are in a moment where many tokens are being launched through ISO ISPO RISO etc. so if you are forced to leave a pool because someone decide to attack K or simply because biggest wallets are rushing in your pool, it could be not fair at all for you.
On the other hand, to block this kind of potential attack could be quite simple to me, because even if a max cap on K could be hard to code as zhekson rightly said, we should just write in the code something like "if you are going to make the overdelegation then you will be penalized for it, but not all the others in that pool and the pool owner".
I'm not a coder so I could be wrong about that, but probably it's just about to add something in the staking code regarding the single staking addresses while they are delegating, without affecting all the other chain transactions.
In general, to be responsible for your bad actions\faults but not for the others ones, looks even more fair to everyone for me. Although we want to think that this type of attack is not possible because it is relatively expensive, or rather not profitable for the attacker in a short therm view, we can immagine situations where a pool owner or a group of pool owners would like to attack some other pool owner\groups to gain delegators or something.

user4302: In principle, you are correct - such an attack is possible. However, this is where the game-theoretic principles of a well-designed PoS system come into play:
In what scenario would an attacker possibly be so malicious as to forgo tens or hundreds of thousands of ADA rewards, just to lower everyone else's rewards? Remember: the attacker's reward flows would be hurt just as much as everyone else's, so this attack seems incredibly unlikely to happen.
Additionally, putting a hard cap on pool saturation introduces some finicky side effects. For example, if an address is delegated to a fully saturated pool, what happens when a new UTXO (containing ADA) is created at that address? Is it simply not delegated? If so, do we now have to prioritize delegating ADA in the order that it comes in, and then how do we prioritize change-type UTXOs? Compensating for this would require at least a few new workarounds to ledger mechanics, all of which may introduce their own side-effects.
Furthermore, even if this attack does happen, other delegators will be quickly incentivized to re-delegate to a different, non-oversaturated pool, until saturation is reached for the targeted pool.

6552: <p>I was thinking, why K parameter isn't a max cap? I mean, if a pool owner is affected by over delegation too, this could become an attack where I (as hypothetical attacker) can delegate 100M ADA through 1k wallets to a pool just to damage its rewards. I could let the other delegators to leave the targeted pool and after that I could quit the pool with all my wallets. While doing it, I will damage my rewards too, but still I could choose to do it consciously. Plus obviously it should work even if you got 63M ADA in your pool and I've got just 10M ADA or something. But however, if K would be a max cap I couldn't do that at all. There is any particular reason I'm not considering because pools can arrive to an over delegation?</p>
 6360: <p>Yes, it's a theoretical attack, but very expensive as noted by @zhekson. The evidence to date suggests the cost sufficiently mitigates.</p>
<p>In practice (other) delegators simply leave until saturation drops.</p>
 6552: <p>Thanks for your reply guys.
Yes indeed this kind of attack will impact your rewards and we all know it, but for me we should think in order to favourite the security and the fairness to all.</p>
<p>This attack is unlikely but it's still possible. I mean if you have 10-100M ADA to use for it, you could probably don't care about 1-2 months of loosing rewards.</p>
<p>Regarding a pool owner, if your K is attacked often your delegators can choose to change their pool to never come back, they are not forced to delegate always the same pool so I can potentially attack your K a few times and you are potentially going to loose some\many delegators forever because of it.</p>
<p>Regarding the delegators, now we are in a moment where many tokens are being launched through ISO ISPO RISO etc. so if you are forced to leave a pool because someone decide to attack K or simply because biggest wallets are rushing in your pool, it could be not fair at all for you.</p>
<p>On the other hand, to block this kind of potential attack could be quite simple to me, because even if a max cap on K could be hard to code as zhekson rightly said, we should just write in the code something like &quot;if you are going to make the overdelegation then you will be penalized for it, but not all the others in that pool and the pool owner&quot;.
I'm not a coder so I could be wrong about that, but probably it's just about to add something in the staking code regarding the single staking addresses while they are delegating, without affecting all the other chain transactions.</p>
<p>In general, to be responsible for your bad actions\faults but not for the others ones, looks even more fair to everyone for me. Although we want to think that this type of attack is not possible because it is relatively expensive, or rather not profitable for the attacker in a short therm view, we can immagine situations where a pool owner or a group of pool owners would like to attack some other pool owner\groups to gain delegators or something.</p>
 4302: <p>In principle, you are correct - such an attack is possible. However, this is where the game-theoretic principles of a well-designed PoS system come into play:</p>
<p>In what scenario would an attacker possibly be so malicious as to forgo tens or hundreds of thousands of ADA rewards, just to lower everyone else's rewards? Remember: the attacker's reward flows would be hurt just as much as everyone else's, so this attack seems incredibly unlikely to happen.</p>
<p>Additionally, putting a hard cap on pool saturation introduces some finicky side effects. For example, if an address is delegated to a fully saturated pool, what happens when a new UTXO (containing ADA) is created at that address? Is it simply <em><strong>not</strong></em> delegated? If so, do we now have to prioritize delegating ADA in the order that it comes in, and then how do we prioritize <em>change</em>-type UTXOs? Compensating for this would require at least a few new workarounds to ledger mechanics, all of which may introduce their own side-effects.</p>
<p>Furthermore, even if this attack <em>does</em> happen, other delegators will be quickly incentivized to re-delegate to a different, non-oversaturated pool, until saturation is reached for the targeted pool.</p>
