Fully anonymise timestamps in version messages when broadcasting transactions

[teor2345]

Motivation

Zebra should broadcast user-generated transactions using anonymised connections. (These transactions can be generated by lightwalletd wallets.)

Currently, Zebra's isolated connections send a truncated timestamp in their version messages. But truncated clock skew can still be used to track users, so it would be better if we just set that field to zero. (There are statistical attacks that check when truncated values change.)

But first, we need to check that zcashd accepts transactions sent with this kind of version message.

Existing Designs

This could be an improvement on the draft Stolon RFC:
https://github.com/ZcashFoundation/zebra/blob/main/book/src/dev/rfcs/drafts/xxxx-stolon.md#isolated-minimally-distinguishable-connections

Suggested Solution

Timestamp:

• Check whether zcashd does anything with the version timestamp
• Send zeroed timestamps in isolated network connections

Remote Peer Services:

• Check whether zcashd does anything with the address_recv peer services
• Send empty remote peer services in isolated network connections

[daira]

Prior to version 2.1.1-1, zcashd would by default adjust its local clock based on timestamps received from its peers. That was an insecure thing to do, and as of 2.1.1-1 that behaviour was disabled by default; in zcash/zcash#4374 the time adjustment code was removed entirely. Zcashd does warn if its peers' clocks are too different; see that PR for details.

In particular, if zebra sends a zero timestamp then zcashd will ignore it, even for the clock warning, because it is "more than 10 days away from the current local time".

For the peer services, I would recommend just fixing them at whatever current zcashd sends (assuming you support those services). It's relatively unlikely that we will use additional peer services flags except in connection with backports from Bitcoin; we tend to rely on the peer protocol version to detect node capabilities instead.

[mpguerra]

Hey team! Please add your planning poker estimate with ZenHub @conradoplg @dconnolly @jvff @oxarbitrage @teor2345 @upbqdn

[teor2345]

Our current code is probably ok for now.