Filtering like this only works if everyone is aware of the rules. If everyone is aware of the rules, so is the selfish miner. If the selfish miner is aware of the rules, he can apply them just as well.
But, to reiterate: Unless SHA256 itself is flawed, nonces are statistically random without bias. The only thing one could learn from such a data set, is what bias each respective miner implementation brings. However that doesn't help improving ones own mining performance.
Totally true.. the topic is about ML and it was about giving some touchy samples.
but the way that we conclude the results would be different from the way that an AI-Agent may does. I mean these all depend on the quality of DSS module that we provide for this part of the protocol. depend on what we saw in the example of litecoin, when the AI-Agent understands the series of incoming nonce values e.g. contain digit 78 at their right side (without any special reason or flaw in hash algorithms / just based on an accident), this opens two situation ahead:
1- our miner node could rapidly try next nonce values with digit 78 at their right side.. (to over come other miners)
2- our miner node gets suspicious that is working in a different fork.. (the protocol may save a timestamp of such security/fraud reports in a parallel blockchain and then punish the selfish nodes)
I have told some pools already do such calculations to find these patterns in nonce values, the least advantages of including such rules and an AI-Agent to the block header, may bring more fairness to the whole ecosystem..
============
P.S.:
AI in
Association rule learning talks about this ability in DSS: "Association rule learning is a rule-based machine learning method for discovering interesting relations between variables in large databases. It is intended to identify strong rules discovered in databases using some measures of interestingness."
https://en.wikipedia.org/wiki/Association_rule_learning============
UPDATE:
in my project I put all generated transactions inside a virtual ring among candidate nodes and ask them to introduce their candidate block - then other nodes could immediately see the fork(s) and wait for the result of finalizing procedure that broadcasts the confirmed block. so this bounce may just fit into that new data/proof model, not classic PoW.