This is a tracking issue for orphan proofs in Cryptarchia.
FYI, orphan proofs are introduced to avoid leaking information about a coin value when it wins an election in a fork. Such a coin, while still valid in another branch, shouldn't be used for leadership, as an adversary could see that the same nullifier was used twice and thus infer some information about the value of said coin.
However, it's not straightforward to use orphan proofs in a way to does not leak this information somewhere else. To start with, you can't just import your proofs, as that would signal again how many slots a certain coin has won.
A first solution to that is to import all proofs you know of. The problem with this is that a malicious leader could use this mechanism for something like a tagging attack, where it creates a fork and only send it to you. By looking at whether the orphan proof is imported in the next block, it can learn whether you were the leader or not for that slot. This is more complicated than the tagging attack and requires more resources (as you need to be a leader and forfeit your leader reward) but it's something we need to look into for a complete analysis
We should have a detailed analysis on the information leaked in all cases to be able to decide how to go forward
The current implementation will validate imported orphan proofs if present but will not produce any, and it will reuse a coin if the leadership proof end in a fork
This is a tracking issue for orphan proofs in Cryptarchia.
FYI, orphan proofs are introduced to avoid leaking information about a coin value when it wins an election in a fork. Such a coin, while still valid in another branch, shouldn't be used for leadership, as an adversary could see that the same nullifier was used twice and thus infer some information about the value of said coin.
However, it's not straightforward to use orphan proofs in a way to does not leak this information somewhere else. To start with, you can't just import your proofs, as that would signal again how many slots a certain coin has won. A first solution to that is to import all proofs you know of. The problem with this is that a malicious leader could use this mechanism for something like a tagging attack, where it creates a fork and only send it to you. By looking at whether the orphan proof is imported in the next block, it can learn whether you were the leader or not for that slot. This is more complicated than the tagging attack and requires more resources (as you need to be a leader and forfeit your leader reward) but it's something we need to look into for a complete analysis
We should have a detailed analysis on the information leaked in all cases to be able to decide how to go forward The current implementation will validate imported orphan proofs if present but will not produce any, and it will reuse a coin if the leadership proof end in a fork