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

Expire bitcoind & bitcoin-qt 7-8 years after its last change #10282

Closed
wants to merge 1 commit into from

Conversation

@luke-jr
Copy link
Member

@luke-jr luke-jr commented Apr 26, 2017

COPYRIGHT_YEAR + 8 years is used as the basis for expiration, to achieve a constantly-moving-forward expiration date.

It is assumed that within 7 years, the software will become obsolete beyond any reasonable person's continuing to use it.
If not hardforks, then at least softforks will occur during this time rendering it insecure. Not to mention an almost certainty of exploits.

Furthermore, this enables a sort of certainty of old nodes ending by a deadline, turning any hardfork into a de facto softfork provided it is planned 8 years out.

As a precaution against abuse, the expiration can be disabled or extended with a debug-visibility "softwareexpiry" configuration option.

(Thanks to Wang Chun for suggesting a similar proposal this is based on.)

Previous discussion: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013822.html

It is unclear to me if this needs a BIP.

COPYRIGHT_YEAR + 8 years is used as the basis for expiration, to achieve a constantly-moving-forward expiration date.

It is assumed that within 7 years, the software will become obsolete beyond any reasonable person's continuing to use it.
If not hardforks, then at least softforks will occur during this time rendering it insecure. Not to mention an almost certainty of exploits.

Furthermore, this enables a sort of certainty of old nodes ending by a deadline, turning any hardfork into a de facto softfork provided it is planned 8 years out.

As a precaution against abuse, the expiration can be disabled or extended with a debug-visibility "softwareexpiry" configuration option.

(Thanks to Wang Chun for suggesting a similar proposal this is based on.)
@luke-jr
Copy link
Member Author

@luke-jr luke-jr commented Apr 26, 2017

(7-8 year target can be adjusted if an earlier expiration is generally acceptable)

Copy link

@wangchun wangchun left a comment

static const int64_t SECONDS_PER_YEAR = 31556952;

@@ -28,4 +30,8 @@ enum {
LOCKTIME_MEDIAN_TIME_PAST = (1 << 1),
};

static const int64_t SECONDS_PER_YEAR = 31558060;

This comment has been minimized.

@wangchun

wangchun Apr 26, 2017

Orbital period of the Earth == mean solar year != mean tropical year; 1 Earth year = 365.242199 days, or 365.2425 days in Gregorian calendar

This comment has been minimized.

@luke-jr

luke-jr Apr 26, 2017
Author Member

For some reason, that gets ctime(47*(31556952)) => 'Sat Dec 31 09:32:24 2016'

I agree your math looks more correct, but for some reason there are more seconds to get the desired result.

This comment has been minimized.

@dcousens

dcousens Apr 26, 2017
Contributor

Maybe a block height would be better?

This comment has been minimized.

@luke-jr

luke-jr Apr 26, 2017
Author Member

Can't compare a block height to system clock, unfortunately. :p

This comment has been minimized.

@yinyunqiao

yinyunqiao Apr 27, 2017

EPOCH seconds are not calculated by years * seconds_per_year, there are time tweak gaps, leap years, historical time change reasons etc.

@gmaxwell
Copy link
Contributor

@gmaxwell gmaxwell commented Apr 27, 2017

I think something like this is fine, so long as its easily user overridden and very clear whats happening.. why use the block headers rather than system date.

Rather than debating what an acceptable time frame would be, I think it might be interesting to first conduct a sealed poll among developers, to see what people think before we influence each other too much.

@laanwj
Copy link
Member

@laanwj laanwj commented Apr 27, 2017

I don't really like planned obsolescence. But being able to plan hard forks years ahead is certainly a nice feature, it's how I always imagined long-term protocol changes would work. So as long as the expiration stays significant time ahead (the current value is good imo) I'm okay with it.

@luke-jr
Copy link
Member Author

@luke-jr luke-jr commented Apr 27, 2017

@gmaxwell So how about interested parties all hash a nonce + statement on preferred obsolescence timeframe(s), and post the hash on https://github.com/bitcoin-core/bitcoin-devwiki/wiki/PR10282-Hashes ?

@jnewbery
Copy link
Member

@jnewbery jnewbery commented Apr 28, 2017

I'd be much happier if this just alarmed and warned the user rather than shutdown the node, but even then I don't really see much benefit.

Furthermore, this enables a sort of certainty of old nodes ending by a deadline, turning any hardfork into a de facto softfork provided it is planned 8 years out.

Slicing old nodes off the network doesn't magically turn a hard fork into a soft fork. Users either have to upgrade, or run the old node and fall out of consensus. It's still a hard fork.

If this proposal is simply to protect users from running an old, insecure version, then:

  1. why does this need to automatically shut down the node rather than alarm and warn the user;
  2. why pick an arbitrary time frame like 7 years? If a soft-fork is activated 6 months after a release which makes the release insecure, then the node will stop working 6.5 years after it became insecure. Doesn't seem like much of a benefit to me.

I'm struggling to see what problem this solves.

@MarcoFalke
Copy link
Member

@MarcoFalke MarcoFalke commented Apr 28, 2017

@kallewoof
Copy link
Member

@kallewoof kallewoof commented May 1, 2017

I think shutdown with an option to forcibly keep it running has benefits. Specifically, it prevents node runners who are assuming their node is safe and sound but aren't touching it from fooling themselves. Maybe because they're scared it might break if they do anything or they're just plain lazy.

Forcing them to go in and set a parameter to keep it running is a good incentive for them to upgrade the software, as they now no doubt realize they're running a node that is too old to be recommended by the developers.

In contrast, a warning message would most likely not only be ignored, but probably never be seen by the type of node runner mentioned above. Turning safe mode off may be a great middle ground, though.

@TheBlueMatt
Copy link
Contributor

@TheBlueMatt TheBlueMatt commented May 1, 2017

As discussed on IRC extensively and at the last meeting, should probably tweak this to only fail to startup after 7 years with a clear error message noting the temporary workaround option.

@laanwj
Copy link
Member

@laanwj laanwj commented May 3, 2017

As discussed on IRC extensively and at the last meeting, should probably tweak this to only fail to startup after 7 years with a clear error message noting the temporary workaround option.

Agree. Any other solution is too controversial and divisive, we should either do that or we should forget about this completely.

@NicolasDorier
Copy link
Contributor

@NicolasDorier NicolasDorier commented May 3, 2017

I don't agree on this PR on a matter of principle: We should not be in charge to tell the user when he should update.

I disagree also because it might be a systemic risk: A non negligeable number of node will start crashing almost at the same time.

Moreover, some nodes might not need to validate soft fork rules as they are internal nodes, and their blocks are already validated by a gateway node.

In a big architecture where Bitcoin core is only one of many components, and where the original developers got away, there would be nothing more frustrating than a component crashing when no update has been done for several years to it.

@laanwj
Copy link
Member

@laanwj laanwj commented Jun 25, 2017

Closing this, seems there is no agreement to do this as part of bitcoin core.

@laanwj laanwj closed this Jun 25, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

You can’t perform that action at this time.