Implement a new revision-counter algorithm
If we decide the answer to #1166 (closed) is that we should indeed continue including the next TP in the secondary ring, then this discussion will need to be addressed.
@nickm suggests
Okay. What's the right way for us to avoid that? I see a few options:
Just don't upload before the start of the time period.
Adjust our zero so that it is the start of the previous time period (or something like that), and increment the other values accordingly. We might need to increase the maximum on our OPE.
Kludge our OPE so that we can encrypt -N through 0 and usually get results in the same area as our C code.
Option 1 would presumably make us less reliable. (How far in advance do we upload, though? And are we right to do so?)
Option 2 would make our OPE less compatible with the C OPE. I think that's okay, though.
Option 3 would take some design, but I think I could figure something out.