You can set your node to 3, but let's first see how small the 64kB blocks really are. Only like 230 average sized transactions can fit in such block, which means to reach 3 blocks worth of transactions in mempool all it takes is less than 1000 bots reacting on the same event, like new daily quest from Splinterlands, or new comments on hbd.funder or a certain price threshold reached on internal market. I wouldn't be surprised if we already have such occurrences every day. At least with 20 blocks before declaring flood the node will already be in the upper limits of what it can reapply in 200ms window. Currently the reapplication window can fit 2k to 5k transactions, but I'm soon going to work on issue #678 which I expect to make reapplications faster (see also comment from original issue). I've also thought about increasing the window to 300ms, since it was not touched despite massive optimizations that were made already, which freed a lot of time between blocks. With those changes we should have default flood level increased even more.
Users are not locked out just because they choose to use small expiration time. If their transaction fails due to flood causing expiration, some of them might choose to wait for the problem to fix itself, which is also a way to lower the traffic. Those that need can still transact with longer expiration.
And what's wrong with transaction_status_api? It is precisely the thing for tracking transactions in mempool. Granted they need to be applied (postponed transactions are invisible to the node), but that's another indicator - if your transaction first appeared as pending, but then vanished, it might mean the API node is flooded.
I don't know about BTC, but I'd imagine the wallet doesn't actually ask any node about transactions in mempool, it just stores locally all transactions it sent out and waits until they reach some block. Since BTC has no TaPoS, no expiration or any other mechanism to force transaction out of mempool (replace-by-fee or spending particular UTxO will force drop the transaction, but that's not really an equivalent to actual expiration), when wallet sends out transaction, it has to assume some mining node might have it in mempool (or even not a miner, anyone can pick up transaction, store it, and resend whenever they want). Of course miners will have mempools and they might offer API to ask for their contents, but they won't be holding all not executed transactions forever, especially not when mempool is increasing in size or the fee on transaction is not attractive enough.
Specially because we operate on a FIFO system and we don't have the option to pay more fees to make a transaction have more priority.
And that's a good thing we don't have it. Not like it would make things any different in current level of traffic, but if conditions changed it would be the fastest way to price out the weakest accounts. Now they can transact even in high traffic, just not as frequently as other accounts.
Average user doesn't choose an expiration and the reality is we can't have too much lag in our interfaces specially the social media side. My argument was that we should increase the RC costs before it gets too late and adds too much delay. If RC costs become too high then we can consider increasing the block size. This won't add any delay.
IMHO the downside of added delay is more than the weak accounts not being able to transact for a period of time. The added delay affects every single user equally regardless of their HP and I think that is a bad design.
I think RC in fact should create friction but not too much and not too little.
transaction_status_api requires you to have the transaction id saved somewhere and that limits it to only the wallet broadcasting the said transaction. I think BTC wallets show the incoming transfers as well that are not included in a block yet. AFAIK they don't need to have the trx_id. I think the ideal system would let you see the pending transactions related to any account on their account history page.
During flood attack the network is in survival mode. Nukes are flying and we need to take shelter and survive long enough for the attackers to run out of ammo. We should certainly not be concerned about not being able to walk the dog in that time. As long as network does not break and there is as little fallout as possible, the attack should be considered a failure. But yes, during attack users need to adapt to be able to still transact if they absolutely need to.
Surcharge mechanism will be triggered as early as first block from the start of flood attack even on default setting (depends mainly on size of transactions), but it won't trigger in normal burst-of-activity situations. Even with the mechanism activating, it will take time for the attackers to be affected - their RC levels need to drop significantly before they start to be locked out, or the mempool needs to bloat to scale up the surcharge. In the latter case everyone weaker than the attackers will be locked out. Even when attackers start to be affected, the mechanism just lowers the intensity of the attack, so it is easier to survive.
It makes no sense to ever implement something like that in Hive. Outside of deliberate attacks, short lived burst-of-activity or network congestion all transactions are included in the nearest block and they even become final before you could refresh history page.
Looking at your concerns I came up with a harassment type of attack that could probably be performed by a single whale :o) It wouldn't affect the network safety, but could negatively impact user experience. Unfortunately to test it (and also potential countermeasure) I'd need to make a lot of changes to the tools I have and I'm busy with other things.