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
base: master
from

Conversation

Projects
None yet
@luke-jr
Member

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.

Expire bitcoind & bitcoin-qt 7-8 years after its last change
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

This comment has been minimized.

Show comment
Hide comment
@luke-jr

luke-jr Apr 26, 2017

Member

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

Member

luke-jr commented Apr 26, 2017

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

@wangchun

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

@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

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.

@luke-jr

luke-jr Apr 26, 2017

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?

@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

Member

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

@luke-jr

luke-jr Apr 26, 2017

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.

@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

This comment has been minimized.

Show comment
Hide comment
@gmaxwell

gmaxwell Apr 27, 2017

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Apr 27, 2017

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@luke-jr

luke-jr Apr 27, 2017

Member

@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 ?

Member

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

This comment has been minimized.

Show comment
Hide comment
@jnewbery

jnewbery Apr 28, 2017

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@MarcoFalke

MarcoFalke Apr 28, 2017

Member
Member

MarcoFalke commented Apr 28, 2017

@kallewoof

This comment has been minimized.

Show comment
Hide comment
@kallewoof

kallewoof May 1, 2017

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@TheBlueMatt

TheBlueMatt May 1, 2017

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj May 3, 2017

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@NicolasDorier

NicolasDorier May 3, 2017

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Jun 25, 2017

Member

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

Member

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