Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement automatic shutdown of deprecated Zcash versions #2297

Merged
merged 2 commits into from
May 15, 2017

Conversation

str4d
Copy link
Contributor

@str4d str4d commented Apr 25, 2017

Closes #2274.

@str4d str4d added D-bitcoin-divergence Design issue: Divergence from Bitcoin (upstream code and/or architecture). network upgrade management Z-NU0 wishlist I-SECURITY Problems and improvements related to security. labels Apr 25, 2017
@str4d str4d added this to the 1.0.9 milestone Apr 25, 2017
@str4d
Copy link
Contributor Author

str4d commented Apr 25, 2017

Started after warning threshold, deprecation threshold reached:
2274-deprecation-running-noflag

Started after deprecation, -disabledeprecation=1.0.8 (assertion is I think related to issue #2214):
2274-deprecated-init-noflag

Started after deprecation, -disabledeprecation=1.0.8-1:
2274-deprecated-init-flag

@daira
Copy link
Contributor

daira commented Apr 25, 2017

Can the messages be wrapped using FormatParagraph, please?

@daira
Copy link
Contributor

daira commented Apr 25, 2017

Also, "deprecation" to me means that the use of something is discouraged but it still works. We need a different word.

@daira daira added this to In Progress in Security and Stability Apr 26, 2017
@daira daira added this to Work Queue in Network Upgrade 0 Apr 26, 2017
@daira daira moved this from Work Queue to Awaiting Review in Network Upgrade 0 Apr 26, 2017
@str4d
Copy link
Contributor Author

str4d commented May 11, 2017

With wrapping:
2274-deprecation-running-noflag-wrapped

@ebfull
Copy link
Contributor

ebfull commented May 11, 2017

@daira In a sense it still works because you can bypass the shutdown, you just have to acknowledge the deprecation and explicitly ignore it. Like selectively disabling a compiler warning. (With warnings set to error. 😄)

src/init.cpp Outdated
@@ -344,6 +344,7 @@ std::string HelpMessage(HelpMessageMode mode)
#endif
}
strUsage += HelpMessageOpt("-datadir=<dir>", _("Specify data directory"));
strUsage += HelpMessageOpt("-disabledeprecation=<version>", _("Disable block-height node deprecation"));
Copy link
Contributor

@arielgabizon arielgabizon May 11, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's hard to understand what exactly <version> is here

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll add documentation for <version> in the help string.

@str4d
Copy link
Contributor Author

str4d commented May 11, 2017

@daira @ebfull I went with -disabledeprecation because the automatic shutdown arises from the deprecation policy, and it is the deprecation policy for that version we are disabling. That is, because we call the policy deprecation, I figured the flag should be -disabledeprecation (so the two are clearly associated in the user's mind). But perhaps that isn't necessary. Or maybe we can add clarification of the effects of -disabledeprecation to the help string?

Copy link
Contributor

@nathan-at-least nathan-at-least left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NACK: There's no automated test coverage of this EnforceNodeDeprecation.


// Deprecation policy is 4th third-Tuesday after a release
static const int APPROX_RELEASE_HEIGHT = 115000;
static const int WEEKS_UNTIL_DEPRECATION = 18;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add a comment like: // We use 18 weeks to ensure auto-deprecation is *always* > 4 months, barring block time skew issues.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See above; this value is to be updated during the release process such that it is the correct number of weeks for that release.

#define ZCASH_DEPRECATION_H

// Deprecation policy is 4th third-Tuesday after a release
static const int APPROX_RELEASE_HEIGHT = 115000;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's important to me that this has a very high chance of occuring after the release day. Add a comment with release date and back-of-the-envelope calculations showing some grace period.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you review the whole PR? I updated the release process to require that these values are updated, so it will always be the case that this value occurs after the release day.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did read the whole PR. My rationale was someone reading this code who doesn't know our release process would know how we calculated the number. It's not important enough to block the PR, and the comment on the preceding line should make it clear enough.

@str4d
Copy link
Contributor Author

str4d commented May 12, 2017

Force-pushed to squash the following changes in:

  • Clarify help text, add example.
  • Expand notes in release process doc
  • Add unit tests.

Copy link
Contributor

@nathan-at-least nathan-at-least left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Excellent unit tests of the boundary conditions, shutdown, logging, and disabling behaviors!

#define ZCASH_DEPRECATION_H

// Deprecation policy is 4th third-Tuesday after a release
static const int APPROX_RELEASE_HEIGHT = 115000;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did read the whole PR. My rationale was someone reading this code who doesn't know our release process would know how we calculated the number. It's not important enough to block the PR, and the comment on the preceding line should make it clear enough.

@arielgabizon
Copy link
Contributor

I'm not sure I understand the point of the version parameter.
From what I understood in the code, you're supposed to give as this parameter the version you are currently running.
But if that's the case, then why not just interpret --disabledeprecation as
"Whatever version I'm running, even if I don't remember my version number, I don't want to deprecate right now"
and not require this parameter?

You could still remind the user what version he is running in the message here
5b3bc97#diff-f8d7df41b8550c564a6295b0952fa1c3R49

@str4d
Copy link
Contributor Author

str4d commented May 12, 2017

I'm not sure I understand the point of the version parameter.
From what I understood in the code, you're supposed to give as this parameter the version you are currently running.
But if that's the case, then why not just interpret --disabledeprecation as
"Whatever version I'm running, even if I don't remember my version number, I don't want to deprecate right now"
and not require this parameter?

The reasoning IMHO is that we don't want that parameter to be "whatever version I'm running, even if I don't remember my version number", because that is exactly equivalent to "ignore deprecation always", and that is a much easier flag to have added in third-party default configs and then be forgotten about, which removes the benefit of this feature almost entirely (because it is effectively no longer by default). If the current version is necessary, then either the user is required to think about that flag on every upgrade (which is additional friction as @bitcartel noted here), or the third party wallet etc. is required to consider it when designing their UI. Either case is I think much closer to the desired goals of this feature. Of course, this assumes we do go for this feature (auto-senescence) instead of one of the other approaches being discussed in #2274.

@arielgabizon
Copy link
Contributor

OK that makes sense

Copy link
Contributor

@daira daira left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ut(ACK+cov), modulo one nonblocking comment.

DEPRECATION_HEIGHT) + " " +
_("You should upgrade to the latest version of Zcash.") + " " +
strprintf(_("To disable deprecation for this version, set %s%s."),
"-disabledeprecation=", CLIENT_VERSION_STR);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should say "To disable deprecation shutdown..." and (less important) that the option name should be "-disabledeprecationshutdown=".

@nathan-at-least
Copy link
Contributor

@zkbot r+

@zkbot
Copy link
Contributor

zkbot commented May 14, 2017

📌 Commit b4f861d has been approved by nathan-at-least

@zkbot
Copy link
Contributor

zkbot commented May 14, 2017

⌛ Testing commit b4f861d with merge 301db3a0a548d2e6900564aecf284117d6efc8d8...

@zkbot
Copy link
Contributor

zkbot commented May 14, 2017

💔 Test failed - pr-merge

@nathan-at-least
Copy link
Contributor

@zkbot retry

@zkbot
Copy link
Contributor

zkbot commented May 15, 2017

⌛ Testing commit b4f861d with merge 3a98e3b...

zkbot added a commit that referenced this pull request May 15, 2017
Implement automatic shutdown of deprecated Zcash versions

Closes #2274.
@bitcartel
Copy link
Contributor

Will this merge close ticket #2274 partially or fully? I was under the impression we were still discussing this PR, based on what @str4d wrote above:

Of course, this assumes we do go for this feature (auto-senescence) instead of one of the other approaches being discussed in #2274.

I just posted a comment yesterday on the ticket: #2274 (comment)

I was hoping we would have more discussion about how this feature might be deployed as in its current form its a big change for end users.

@zkbot
Copy link
Contributor

zkbot commented May 15, 2017

☀️ Test successful - pr-merge
Approved by: nathan-at-least
Pushing 3a98e3b to master...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
D-bitcoin-divergence Design issue: Divergence from Bitcoin (upstream code and/or architecture). I-SECURITY Problems and improvements related to security. network upgrade management
Projects
No open projects
Network Upgrade 0
  
Complete
Development

Successfully merging this pull request may close these issues.

None yet

7 participants