Fix pending root event emission

[QGarchery]

Fixes:

• [protocol review] Events are not reliably emitted for the pending root updates #74

Also unifies two events that were about the pending root update. Now the pending root value are always equal to the values in the last PendingRootSet event

[QGarchery]

Why was this run canceled ?

[MerlinEgalite]

I think it makes less clear when a revoke is invoked. @julien-devatom wdyt?

[julien-devatom]

I think it makes less clear when a revoke is invoked. @julien-devatom wdyt?

Yes exactly, you miss the information that the pending value is revoked. So for this reason, I'm against this refactoring.

[QGarchery]

Yes exactly, you miss the information that the pending value is revoked

This information is ambiguous though, because trigerring _setRoot effectively deletes the pending root. So, for example, if you use the number of RevokeRoots to know how many proposals of roots have been revoked you are counting it wrong. It could be that the owner revokes the roots by using the setRoot function with the same root and the same ipfsHash.

What is important is to be able to track the changes of the values of the pending root. Adding an event for the special case of the bytes32(0) just makes it more difficult (because now you have to handle another event).

Also, don't miss the fact that this PR also fixes the fact that no events was emitted for the pending root being deleted in _setRoot

[MerlinEgalite]

This information is ambiguous though, because trigerring _setRoot effectively deletes the pending root.

This is a good point actually but the opposite is true as well? How do you know when someone revoke a root or that the root has been consumed (everyone has claimed their rewards) and then reset to 0

[QGarchery]

This is a good point actually but the opposite is true as well? How do you know when someone revoke a root or that the root has been consumed (everyone has claimed their rewards) and then reset to 0

Yes it's true, you can't tell them apart. And you also can't tell if everyone has claimed their reward, because that information is not available (it's in the hash). So my point is that we should not try to add events that make it look like this information can be retrieved

[MerlinEgalite]

Should we keep that PR open @QGarchery @julien-devatom ?

[julien-devatom]

I'm closing it since this is discussed & handled in the PR #83