Transactions with "provided gas" > "block's max gas" keep propagating to other peers

[pnomarev]

Although I'm not quite familiar with Rust and cannot find the exact place which cause the issue, I'm collecting transaction broadcasts from the network and receiving them every 2-4 second from the same clients.

This tx: 0xf9c7e9165d9d55c060c4d098ff818bb182169227b21b59851d73ebcedfed0bee provides 4.3 million gas, and Parity clients just sending it to each other.

Affected versions(at least):
"Parity/v1.4.5-beta-a028d04-20161126/x86_64-linux-gnu/rustc1.13.0"
"Parity/v1.4.6-beta-5feccf1-20161205/x86_64-linux-gnu/rustc1.13.0"

[tomusdrw]

Parity accepts and propagates transactions with gas_limit < 1.1 * current block gas limit. They get a low priority though. Since block gas limit is fluctuating the transactions might be valid for the next block.
Any reason to not accept such transactions?

Transaction propagation is working differently in 1.5 series, it's not sending same transactions twice to the same peers.

Relevant lines:
https://github.com/ethcore/parity/blob/master/ethcore/src/miner/transaction_queue.rs#L590

[pnomarev]

The reason to not accept transactions with gas, higher than the block's limit is to avoid possible overwhelm of the miners with a bunch of such transactions.
However, the issuer of such transactions should be responsible for resending them to other peers when the block's gas limit goes up just enough to be processed.

[tomusdrw]

Those transactions get lowest priority (when the miner figures out that they doesn't fit the block) so they will never really overwhelm the miners.

The problem also exists if the current block gas limit goes down a little bit and invalidates transactions that are already in queue, we treat them the same way.

There is an issue open to improve transaction queue #1966, we might considering treating such transactions as "future" and drop them after occupying the queue for some time to favour transactions that can be immediately executed.