# Attack mitigation discussion ## Blowball considerations What can we do to mitigate blowball attack effects on the network in Chrysalis. - **Adaptive spamming** - to some extent - works only till a certain TPS, cannot be scaled up to higher amounts of TPS. The multiple parents proposal makes this better. - **Multiple parents** - makes it possible to for honest spam to reduce the total number of tips and reduce the effect of bad spam on CTPS better. - Can be dynamic based on the amount of tips available. - Baseline 2, up to 8 as max. Will require another byte that specifies the number of parents. GoShimmer has [parents ordered by hash ASC](https://github.com/iotaledger/goshimmer/blob/feat/tangle-proposal/docs/tangle.md#message-structure). - D(B)FS in Hornet can be rewritten to walk the parents in a specific order. - Chaininness address by current Hornet retention rules. Multiple selections of the same tips get the tip dropped from the tip pool. These rules are skipped in a high amount of tips scenario, this can also be done with multiple parents. - Hornet spammer is adaptive and can spam then you reach a scenario with a high amount of tips. Spammer already exists, it just needs to be made adaptible. ____________________________________________________________________________________________________ - **Heaviest branch selection** (Would have to be tested more with research) - having that in place of the current random tipsel would be have some negative game theoretical consequences. Has performance problems as well - exactly why we're not using it for node tipsel. This would have to be 2 random (to always remove at least one from the pool) + 1 heavy at least. Can be adaptive with 3-8, and Coo always using 8. Adaptivness can be done based on the number of tips (maybe we can use the ratio from the whitepaper with assumed network latency). - **Implement mana and node IDs** - Not implementable in Chrysalis. ## Adaptive MWM How do we prevent attacks so that they only becomes short-term bursts? TPS/PoW is too cheap, so you can quite cheaply kill off the crappy nodes in the network. - PoW can be dynamic based on an anverage XX milestones and the the value for the milestones of X+10 of mwm can be included in milestone X. So that you can already start adapting to the difficulty. Client can get the value from an API if needed. - This could adapt both ways if there's a benefit to this. - There's always going to be a delay in this to make it usable by servers/clients. By which time an attack may already be concluded. - The decay function will have to be defined. ## Actions points - To discuss the multiple parents, branch selection, & adaptive MWM proposals on the Protocol call next week. ### Update via protocol call 1. Instead of increasing parents, nodes can issue several messages and thus mimick the same behavior. 2. Finding heaviest tip may still be computationally hard for regular nodes. So we might do a heuristic 3. Darcy will do a write up for his proposal using heights.