Thanks @JPL! 
The main thing Iām liking about this idea is its simplicity. Itās basically using gossip to communicate and increment a global counter, but rather than a formalised gossip algorithm, itās just piggybacked on the existing message protocols.
It seems like there should be enough randomness in that existing protocol to be confident that no sections or peers will fall significantly behind others, but thatād need looking into a bit further I think. Formal gossip protocols rely on assumptions that all peers can be contacted and will be eventually. We have such a requirement within sections since thatās needed by Parsec. Since Parsec is being used to communicate details about nodes joining or leaving a single section, and we require all neighbouring sections to be informed of any such changes too, I think itās safe to say that we do have the conditions required to make this work.
Iām a bit sceptical that this could be used for validating contract signing times since weād probably want such a mechanism to work in every situation, and given the resolution or margin of error of this would vary from section to section and would also vary within a section over a given period, I doubt if it could be used reliably to accept or deny a contractās signing ātimestampā unless the acceptable margin of error is very high.
Where I see this being somewhat more useful is in adding a little more to the overall network security. If a message is received from a node which shows an obviously invalid counter, then the network will be better placed to block/ignore/punish. Just now, if a malicious node decides to replay a message it received a while back, then it should get filtered out by any nodes which already received that message, rendering the attack useless. However, the old messages only live in the filter for a few minutes. Using the global counter would be another way for receivers to know that a message is very old and should be ignored.
It could also be seen as a sort of network pulse, where if the rate increased weād know the network was busier. Iām not sure if thatās useful on its own thoughā¦ weād probably be more interested in whether itās busier because of an increase in Get requests, or because of a drop in vaults for example, and there are better ways to measure these sorts of things.
Iām sure there are more use-cases for this in terms of security, and Iād think clients would also be interested in knowing this value too. (Regarding the debate earlier about a client being tricked by a single proxy - that is indeed the case right now, but before long weāll need to ensure that such malice canāt happen, e.g. by having clients connect to multiple proxies). If it turned out the margin of error was actually small, then I could see this being especially useful to clients.
Just my own two cents of course! 