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 > > > Date: Tue, 22 Aug 2017 13:24:05 -0400 > From: Thomas Guyot-Sionnest <derm...@aei.ca> > To: Erik Aronesty <e...@q32.com>, Bitcoin Protocol Discussion > <bitcoin-dev@lists.linuxfoundation.org>, Chris Riley > <cri...@gmail.com> > Cc: Matthew Beton <matthew.be...@gmail.com> > Subject: Re: [bitcoin-dev] UTXO growth scaling solution proposal > Message-ID: <4c39bee6-f419-2e36-62a8-d38171b15...@aei.ca> > Content-Type: text/plain; charset="windows-1252" > > In any case when Hal Finney do not wake up from his 200years > cryo-preservation (because unfortunately for him 200 years earlier they > did not know how to preserve a body well enough to resurrect it) he > would find that advance in computer technology made it trivial for > anyone to steal his coins using the long-obsolete secp256k1 ec curve > (which was done long before, as soon as it became profitable to crack > down the huge stash of coins stale in the early blocks) > > I just don't get that argument that you can't be "your own bank". The > only requirement coming from this would be to move your coins about once > every 10 years or so, which you should be able to do if you have your > private keys (you should!). You say it may be something to consider when > computer breakthroughs makes old outputs vulnerable, but I say it's not > "if" but "when" it happens, and by telling firsthand people that their > coins requires moving every once in a long while you ensure they won't > do stupid things or come back 50 years from now and complain their > addresses have been scavenged. > > -- > Thomas > > >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
