Rejecting recently rejected

[SurfingNerd]

Rejecting recently rejected transaction are not leaving the network.
even for reasons like "InsufficientBalance".
If the Transaction can't get executed anyway - this transaction should just get thrown away ??
Otherwise it is easy to just spam a network with bullshit transactions.
Anyone else made such observations ?
It is theoretical possible that we messed something up in the code in our HBBFT implementation, but we did not touch this parts of the code.
maybe it is also just a setting ??

[SurfingNerd]

could be reproduced with a network of 1 rpc, 1 validator, 5 full nodes.
the transaction in question was addPool.

2023-08-08 22:09:27 Worker Client3 DEBUG txqueue [0x8b7fd00cc17afaee9fbc63223ce94c6876cd580bf4b1db0585dfbdc83f499709] priority: Regular
2023-08-08 22:09:27 Worker Client3 DEBUG txqueue importing pool status: LightStatus { mem_usage: 0, transaction_count: 0, senders: 0 }
2023-08-08 22:09:27 Worker Client3 DEBUG txqueue [0x8b7fd00cc17afaee9fbc63223ce94c6876cd580bf4b1db0585dfbdc83f499709] Added to the pool.
2023-08-08 22:09:27 Worker Client3 DEBUG txqueue [0x8b7fd00cc17afaee9fbc63223ce94c6876cd580bf4b1db0585dfbdc83f499709] Sender: 0xbffd…2a45, nonce: 0, gasPrice: 1000000000, gas: 2100000, value: 10000000000000000000000, dataLen: 196))

The transaction got removed from the pool:
2023-08-08 22:09:57 Worker Client3 DEBUG txqueue [0x8b7fd00cc17afaee9fbc63223ce94c6876cd580bf4b1db0585dfbdc83f499709] Culled or mined.
2023-08-08 22:09:57 Worker Client3 DEBUG txqueue Removed 1 stalled transactions. Pool: 0/100000 (0 senders; 0/1024000 kB) [minGasPrice: 1000 Mwei, maxGas: 1000000000]

The problem was that it came from the RPC node that is behind with the sync. (detail: It failed importing a block because of stage 5 verification)
From the RPCs point of view, the transaction is valid.

Draft for a solution:

While it is has positive takes to keep the communication to nodes that could not sync, it is not helpful for the network that Nodes that are within a syncing process take part in the transaction gossiping.

The problem with it is that a node can never know the truth about the network state without syncing to the end.

Example:
A (Node RPC) Node is at block 100.
Another Node (Node Faulty) is telling that it has blocks until block 300.
The Node RPC can only tell that is really the truth once it tries to sync to that problem.

So therefore a Block difference based mechanism can not be implemented that easy.