Make old Zebra versions eventually refuse to run

[teor2345]

Motivation

1. Nodes stuck on outdated network upgrades can be attacked using a small amount of hash power. For example, this is a security issue for users if that Zebra instance backs a lightwalletd server.

2. Include the latest checkpoints to prevent long-range attacks under both Proof of Work (this is even more important under Proof of Stake).

3. Having an end of support halt puts an upper bound on how long security issues can persist on the network.

4. If an old Zebra version launches after a network upgrade, it will keep trying each peer it gets from the DNS seeders, even if they have been upgraded, and reject its connections. This is a distributed denial of service risk, and it places extra load on the network.

Issue 4 is mitigated by:

• Security: Limit reconnection rate to each individual peer address #1848 Limit reconnection rate to each individual peer address
• Security: Running Zebra nodes should eventually stop trying to contact peers that always fail #1865 Running Zebra nodes should eventually stop trying to contact peers that always fail
  • this fix doesn't work when the node is restarted frequently, so we need to eventually make Zebra refuse to run

Solution

Zebra should refuse to run on launch, if a lot of blocks have been generated since the last release. The exact number of blocks isn't important, but it should be some fraction of the block/times between network upgrades.

Zebra should exit when it reaches the end of support block height.

Design Tasks:

• work out the average time between recent network upgrades
• decide how long Zebra should run before it requires an upgrade
• decide which time we want to use as the "last change" time, this time must be stored somewhere in Zebra's source code
  • an explicit support date constant
  • a date calculated from: a checkpoint date stored in the checkpoint files each time they are updated, and the target block time interval (this requires an update to zebra-checkpoints and the checkpoint parsing code)
• get this design reviewed by other Zebra developers

Implementation Tasks:

• make Zebra exit on launch if it's a long time since the "last change" time chosen during the design process

Testing:

• Make a test that fails if the end of support height is in the next few weeks, so we don't forget to update it

Documentation:

• Add "update the end of support halt" to the release checklist

Alternatives

This is a serious security issue, so we must do something. But it won't have a major impact until a lot of Zebra nodes are deployed and run for a long time.

Context

zcashd has a support interval of around 16 weeks between required upgrades, with new versions coming out every 6 weeks. It's important that the end of support halt is not a multiple of the release cycle.

This is similar to Zebra's 4 month peer address limit in #1865.

Here is the initial zcashd issue:

• Auto-senescence zcash/zcash#2274

[str4d]

The standard zcashd support period is actually 16 weeks, not 6. This ensures we usually have two supported releases available given our 6-week release cycle (with some slack for slippage), which gives zcashd users around 3-4 months in which to perform upgrades.

We do usually shorten the support period (if necessary) for the last release prior to supporting a NU on mainnet, to ensure that the only supported zcashd releases at NU activation will follow the NU.

[teor2345]

The standard zcashd support period is actually 16 weeks, not 6.

Thanks, I've fixed the ticket.

[teor2345]

This is a serious security issue, but it's not required before NU5 activation.

[mpguerra]

One for the ziggurat team?

[teor2345]

We don't want to do this now, it seems to cause a lot of problems.

[teor2345]

ECC devs asked us about adding an automated halt to each Zebra version, so I'm going to re-open this ticket.

Something to discuss between ECC and ZF in the future is what Zebrad is planning to do with respect to EOS halts. In zcashd, each release has a strictly limited lifetime, which is really useful for when we want to coordinate network upgrades. Is Zebrad interested in doing something similar, and if so should we consider codifying the approach as a ZIP?
str4d also mentioned zcashd's potential for using alert keys to put the network into a safe mode; what's zebrad doing there?

https://discord.com/channels/809218587167293450/809251050741170187/1037816158067363882

We might want to do this before the first stable release of Zebra, or before NU6 testnet activation.

[teor2345]

@mpguerra the ECC engineers have suggested that we make this change for security reasons. Can we please schedule it in before Zebra does its first stable release?

(If we change it after doing our first stable release, or after we pick up a lot of users, they will be very surprised.)

[oxarbitrage]

I created a pull request for this here

By default this pull request will end the support for a release at 180 days(6 months - around 12 releases) after its creation.

If we consider the last 2 network upgrades in Zcash which are Canopy and NU5, there are 1 year and a half apart, I am assuming that NU6 will not be much less than that. The number can be adjusted, i am openb to discuss it as 6 months just sounds reasonable to me but it is more or less random selection.

[dconnolly]

Could go in the existing progress task?

[teor2345]

I update this ticket based on the sync discussion today.