New mining stack on the way! Secure, transparent and flexible
...
It either leads to a massive bloat in the data sent to the miner, or each miner requires access to their own bitcoin node, which will lead to lost blocks due to the fact that the pool should be configured to handle work changes way better than a miner could.
There is no reason to choose transactions, since it will always be based on ignorance, bias, prejudice, intolerance or corporate interests.
The best example of that being LukeJr putting such prejudice into the ubuntu release of bitcoin years ago.
If your pool's transactions are not already taken, unbiased, from the mempool of the best paying transactions at the time you generate the work, but instead include bias in that choice, then there is a problem with the pool and miners should mine somewhere else.
The original flaw in stratum was the fact that the work did not include the work difficulty.
Slush wouldn't change that coz he said it was too much work for him to fix his pool, thus stratum was released with that flaw.
See the original stratum discussion thread for that argument.
https://bitcointalksearch.org/topic/ann-stratum-mining-protocol-asic-ready-108533
The miner already supplies stats about itself via the API I designed and wrote, that there are many tools available to see those stats.
The pool already can determine the hash rate of the miner and when it submitted the last share.
The miner providing these API statistics to the pool is, to be blunt, completely unnecessary and thus will only lead to nefarious use of this data by the pool.
Your current firmware also includes a major well known security risk - xnsub.