So, in your minds, anyone who locked up coins using CLTV
for their child to receive on their 21st birthday, for the
sake of argument, has effectively forfeit those coins after
the fact? You are going to force anyone who took coins
offline (cryptosteel, paper, doesn't matter) to bring those
coins back online, with the inherent security risks?
In my mind, the only sane way to even begin discussing an
approach implementing such a thing - where coins "expire"
after X years - would be to give the entire ecosystem X*N
years warning, where N > 1.5. I'd also suggest X would
need to be closer to the life span of a human than zero. Mind
you, I'd suggest this "feature" would need to be coded and
deployed as a future-hard-fork X*N years ahead of time. A-la
Satoshi's blog post regarding increasing block size limit, a
good enough approximation would be to add a block height check
to the code that approximates X*N years, based on 10 minute
blocks. The transparency around such a change would need to
be radical and absolute.
I'd also suggest that, similar to CLTV, it only makes sense
to discuss creating a "never expire" transaction output, if
such a feature were being seriously considered.
If you think discussions around a block size increase were
difficult, then we'll need a new word to describe the
challenges and vitriol that would arise in arguments that will
follow this discussion should it be seriously proposed, IMHO.
I also don't think it's reasonable to conflate the
discussion herein with discussion about what to do when ECC or
SHA256 is broken. The weakening/breaking of ECC poses a real
risk to the stability of Bitcoin - the possible release of
Satoshi's stash being the most obvious example - and what to
do about that will require serious consideration when the time
comes. Even if the end result is the same - that coins older
than "X" will be invalidated - everything else important about
the scenarios are different as far as I can see.
Rodney