Thomas Guyot-Sionnest [ARCHIVE] on Nostr: 📅 Original date posted:2017-08-22 📝 Original message:I'm just getting the ...
📅 Original date posted:2017-08-22
📝 Original message: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 <http://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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170822/8c69cf2e/attachment.html>;
📝 Original message: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 <http://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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170822/8c69cf2e/attachment.html>;