Lock time transactions have been valid for over a year now I believe. In any case we can't scan the block chain for usage patterns in UTXOs because P2SH puts the script in the signature on spend.
> On Aug 22, 2017, at 4:29 PM, Thomas Guyot-Sionnest via bitcoin-dev > <[email protected]> wrote: > > I'm just getting the proposal out... if we decide to go forward (pretty huge > "if" right now) whenever it kicks in after 15, 50 or 100 years should be > decided as early as possible. > > Are CheckLockTimeVerify transactions accepted yet? I thought most special > transactions were only accepted on Testnet... In any case we should be able > to scan the blockchain and look for any such transaction. And I hate to make > this more complex, but maybe re-issuing the tx from coinbase could be an > option? > > -- > Thomas > >> On 22/08/17 06:58 PM, Rodney Morris via bitcoin-dev wrote: >> Thomas et.al. >> >> 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 >> > > _______________________________________________ > bitcoin-dev mailing list > [email protected] > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________ bitcoin-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
