Stop saying it's not possible. It's possible. There may be reasons why some want to expire old coins. Explicitly mentioned are weaknesses in the cryptography potentially leading to old coins (say Satoshi's stash) being recovered and old transactions becoming a bottle neck for nodes.
------------
The topic title shows a lack of understanding on Bitcoin. Coins are not "stocked" on a client. Transactions are stored in a ledger. The client merely holds the keys needed to manipulate those transactions. The ledger follows the rules of the Bitcoin protocol. And that protocol can (and will) be changed if the need arises. While a scenario that will lead to old unspent outputs being invalidated seems very unlikely now, a need may suddenly arise. If you own bitcoins you'd do well to keep up with news on this. There is no guarantee that you will still be able to spent an old output in the future.
Quotes, for reference:
OP's concern is valid. What if your old wallet format does not get recognized by new clients and the old clients are not able to send transactions after 2 years? (private key is relatively safe but still... see below)
In fact, in today's bitcoin design, nothing is guaranteed. A new protocol that is accepted by majority of the nodes can even spend your coins without your private key. Of course such a situation will almost never happen because of the decentralized nature of bitcoin: Existing stakeholders have many reasons to deny such kind of protocol change, since it basically ruins people's trust in bitcoin
However, if the protocol change is coming from a malicious actor or sybil attack, then old coins might still get lost in a compromised environment
The most important is to be aware that unlike gold, no rule of bitcoin is fixed by law of nature, they are just rules made by human and maintained by consensus among its participants. So you can expect that different clients have different rules, but usually you don't get enough details about these rules unless you are familiar with source code inspection and build the client by yourself each time
In fact, in today's bitcoin design, nothing is guaranteed. A new protocol that is accepted by majority of the nodes can even spend your coins without your private key. Of course such a situation will almost never happen because of the decentralized nature of bitcoin: Existing stakeholders have many reasons to deny such kind of protocol change, since it basically ruins people's trust in bitcoin
However, if the protocol change is coming from a malicious actor or sybil attack, then old coins might still get lost in a compromised environment
The most important is to be aware that unlike gold, no rule of bitcoin is fixed by law of nature, they are just rules made by human and maintained by consensus among its participants. So you can expect that different clients have different rules, but usually you don't get enough details about these rules unless you are familiar with source code inspection and build the client by yourself each time
Theoretically, if secp256k1 were broken then there would be a strong incentive to migrate to another algorithm. The migration may specify a deadline past which all old-format outputs are deemed unspendable. In this event, yes, coins stored with an old version of Bitcoin Core and not rescued in time could end up locked away forever.
Expiring very old UTXOs but not reassigning their value is acceptable, though. In fact, this can be done in a softfork. I think that doing this would be a good idea:
- If apparently-lost BTC is at risk of being recovered illegitimately due to cryptographic weaknesses. The release of so many lost coins would be a major blow to the the economy. Once it looks like ECDSA will only be secure for 5 more years or so, I think that a timer should be started to expire all ECDSA-secured UTXOs at the expected point at which they will become too insecure.
- If storing the UTXO set becomes a very major bottleneck for full nodes and there are no other good alternatives to UTXO expiration on the table. Several years of advance warning should be given before the first expiration.
