rc-flood-level - default 20
This value seems too large to me. I would vote for a lower value like 3. Whenever there are 20 full blocks in mem pool, it means average users are already locked out. The default expiration pretty much everywhere is 60s. 20x3 = 60s
And because of the lack of APIs which makes it difficult (if not impossible) to track transactions that are not yet included in blocks, we can't afford to have a mempool that grows that large. In other networks like BTC your wallet will track pending transactions that are waiting in mempool to be included in a block.
But even with sufficient API support I don't think we can or we should let transactions take longer. 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.
We should probably have something in place like an optional fee multiplayer parameter on top of all this to eliminate the possibility of getting locked out.
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.
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.