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

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.

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

static const int64_t SECONDS_PER_YEAR = 31556952;

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.

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.

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

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.

Not sure why the node must shut down. Note that there is already a state "safe_mode", which can trigger automatically after the node "aged" more than X years instead of shutting down.

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.

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.

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.

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.

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