But it seems to me, that handle_private should not be applied at all. Imagine a situation, where the agent wants to work on a private chain that is shorter than the public chain. The application of handle_private to delivered messages forces the agent to adopt the longer (public) chain.
I fixed the behaviour for tailstorm (now tailstormll) in #10. All other attack spaces have this problem.
When fixing this problem, consider adopting the recent changes from tailstorm_ssz for the other protocols. I think the new match/override mechanism translates to all protocols.
Consider the prepare handler in the Ethereum attack space. https://github.com/pkel/cpr/blob/642756cd3fe778437f40dee672c6f1508edcf5b3/ocaml/protocols/ethereum_ssz.ml#L409-L417 L414 must be a bug. If anything, we should filter for private visibility.
But it seems to me, that
handle_private
should not be applied at all. Imagine a situation, where the agent wants to work on a private chain that is shorter than the public chain. The application ofhandle_private
to delivered messages forces the agent to adopt the longer (public) chain.I fixed the behaviour for tailstorm (now tailstormll) in #10. All other attack spaces have this problem.
When fixing this problem, consider adopting the recent changes from
tailstorm_ssz
for the other protocols. I think the new match/override mechanism translates to all protocols.