Get rid of ignored proposals.

[Bren2010]

Ignored proposals don't make sense to me. How can they possibly add value? Also, re-structured section on Commits some.

[bifurcation]

I'm afraid the flow chart might not quite be that simple. It is possible for there to be proposals that (1) don't appear in the Commit and (2) don't need to be re-sent. The simplest case is when a member sends two Update messages within an epoch. On the one hand, there's no practical need for them both to be included in the Commit, since one will overwrite the other. On the other hand, at the same time, the new member shouldn't re-send the stale Update. The idea of the ignored array was to provide a slot for these to be included in the Commit, but without the need for recipients to act on them.

[bifurcation]

On a separate note, it would be helpful if you could base your different PRs on master, to make the specific changes clearer.

[Bren2010]

In that specific example, the member is aware of all the Updates they've sent and can know to only expect one to be included.

In fact, the member can try to enforce a lot of things:

• Re-send if no Update was included.
• Re-send if the included Update isn't "recent enough."
• Re-send if the included Update isn't the most recent.

The member's own sense of what should/shouldn't be included is what matters here, not the comitter's.

[bifurcation]

I can agree that the difference between "Proposal got dropped somewhere in the ether" and "Proposal was consciously ignored by the Committer" is not really salient. I'll post to the list to see if anyone else objects.

[bifurcation]

@beurdouche raised some concerns with this on the mailing list. I proposed a compromise there, of the form:

1. Specify that if a Committer receives two Updates proposals for the same leaf in the same epoch, then it MUST commit the latest one it received.
2. State explicitly that the only Proposals that may be omitted from a Commit are:

• Invalid proposals (e.g., because of a bad signature, parsing error, reference to a non-existent leaf)
• Proposals whose effect on the tree is overwritten by another proposal, which at this point includes only:
  • Updates for a leaf prior to the latest Update received by the committer
  • Updates for a leaf for which there is a Remove in the epoch

[bifurcation]

@Bren2010 - How does that strike you?

[Bren2010]

Isn't that what's currently in the PR? The only difference is "SHOULD prefer the most recent Update" because it's not enforceable anyway