# Counter-Measures, aggressive maneuvers vs attackers

**URL:** <https://talk.harmony.one/t/counter-measures-aggressive-maneuvers-vs-attackers/1525>\
**Category:** Web3\
**Created:** [June 11, 2021, 12:57am UTC](https://talk.harmony.one/t/counter-measures-aggressive-maneuvers-vs-attackers/1525 "2021-06-11T00:57:46Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Loud-Cloud-Dragon](https://yyz1.discourse-cdn.com/flex035/user_avatar/talk.harmony.one/loud-cloud-dragon/32/703_2.png) [@Loud-Cloud-Dragon](https://talk.harmony.one/u/Loud-Cloud-Dragon)\
**Post date:** [June 11, 2021, 12:57am UTC](https://talk.harmony.one/t/counter-measures-aggressive-maneuvers-vs-attackers/1525/1 "2021-06-11T00:57:46Z")

</div>

Hi all,

Not sure where to put this topic so I figured I would start with the “tip of the sword”, “big brains”, “tech wizards”, aka you all, the Devs.  
In regards to the Arb Spammer bots that are currently causing a nuisance;  
I wonder if there is a way to implement an ever-increasing transaction cost to target attackers (be on the _offense_ rather than just the defense once an attack is _identified_). For instance, if the TX payload is **bare and repetitive** , meaning, a _shell of a transaction_, _nonsense_, _spam_; then a mechanism could note the wallet address, time, GEO, etc, If the behavior continues and trips a barrier limit, “click” [notice to transactor = **transaction cost is tripled to $\*.** or you must wait X amount of seconds before attempting an identical TX.\*\*]…

Not sure how much of this would take place on a separate infrastructure (i.e Azure Functions and Logic Apps, AZ Automate, etc). _Just food for thought._

Have a WONEderful day!

---

<div class="post-metadata">

**Author:** ![rongjian](https://yyz1.discourse-cdn.com/flex035/user_avatar/talk.harmony.one/rongjian/32/43_2.png) [@rongjian](https://talk.harmony.one/u/rongjian)\
**Post date:** [June 11, 2021, 6:17pm UTC](https://talk.harmony.one/t/counter-measures-aggressive-maneuvers-vs-attackers/1525/2 "2021-06-11T18:17:51Z")

</div>

That could be implemented as a txn selection strategy on a per validator basis, meaning it’s the block proposer’s own judgement. But it will be a bit hard to do while not touching the border of txn censorship. The best solution is still have a good txn pricing model to make the cost of attack higher than economically sensible in a long run.

---

<div class="post-metadata">

**Author:** ![doran](https://avatars.discourse-cdn.com/v4/letter/d/db5fbb/32.png) [@doran](https://talk.harmony.one/u/doran)\
**Post date:** [June 11, 2021, 11:42pm UTC](https://talk.harmony.one/t/counter-measures-aggressive-maneuvers-vs-attackers/1525/3 "2021-06-11T23:42:59Z")

</div>

I think we need to come up with a more innovative approach than just increasing txs cost. What about this attack is any different than the countless before it on any low fee chain? Why was the Harmony team caught off guard here? Honestly, a solution to this type of attack, that doesn’t require increasing tx costs, should have been part of the white paper. We need to innovate not emulate solutions to age old problems.

---

<div class="post-metadata">

**Author:** ![Loud-Cloud-Dragon](https://yyz1.discourse-cdn.com/flex035/user_avatar/talk.harmony.one/loud-cloud-dragon/32/703_2.png) [@Loud-Cloud-Dragon](https://talk.harmony.one/u/Loud-Cloud-Dragon)\
**Post date:** [June 15, 2021, 8:14am UTC](https://talk.harmony.one/t/counter-measures-aggressive-maneuvers-vs-attackers/1525/4 "2021-06-15T08:14:29Z")

</div>

> [@doran](#):
>
> What about this attack is any different than the countless before it on any low fee chain?

That I can not answer. I’ll look and see what I can find but it is a few notches above my head.

> [@doran](#):
>
> We need to innovate not emulate solutions to age old problems

Any ideas?