📅 Original date posted:2017-08-22
📝 Original message: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 <dermoth at aei.ca>
> To: Erik Aronesty <erik at q32.com>, Bitcoin Protocol Discussion
> <bitcoin-dev at lists.linuxfoundation.org>, Chris Riley
> <criley at gmail.com>
> Cc: Matthew Beton <matthew.beton at gmail.com>
> Subject: Re: [bitcoin-dev] UTXO growth scaling solution proposal
> Message-ID: <4c39bee6-f419-2e36-62a8-d38171b15558 at 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170823/8ee044f4/attachment.html>;
Rodney Morris [ARCHIVE] /
npub1y2…l9apx
2023-06-07 18:04:57
in reply to nevent1q…ukct
Author Public Key
npub1y2wcan7yptzyrg55znun2r66q8dgery6vehmyhnq0fhx09d2pndskl9apxPublished at
2023-06-07 18:04:57Event JSON
{
"id": "684973f3ae39e9d83b6b7a2f2aa0d9a94a69cab122ca9d02dec61388e9baa77e",
"pubkey": "229d8ecfc40ac441a29414f9350f5a01da8c8c9a666fb25e607a6e6795aa0cdb",
"created_at": 1686161097,
"kind": 1,
"tags": [
[
"e",
"0c6b4b39952a477652831cf44f1b98052b758ac89592ff172262f8fe76fd14d7",
"",
"root"
],
[
"e",
"dfe6021b27cb52f6616e98afd1cf30a6f26a103077302b9f85fdda6391a65b77",
"",
"reply"
],
[
"p",
"8e9ded2eb9fca290998203d61b6d50df7ac2f6dcf13d8c484cbdee405f963df7"
]
],
"content": "📅 Original date posted:2017-08-22\n📝 Original message:Thomas et.al.\n\nSo, in your minds, anyone who locked up coins using CLTV for their child to\nreceive on their 21st birthday, for the sake of argument, has effectively\nforfeit those coins after the fact? You are going to force anyone who took\ncoins offline (cryptosteel, paper, doesn't matter) to bring those coins\nback online, with the inherent security risks?\n\nIn my mind, the only sane way to even begin discussing an approach\nimplementing such a thing - where coins \"expire\" after X years - would be\nto give the entire ecosystem X*N years warning, where N \u003e 1.5. I'd also\nsuggest X would need to be closer to the life span of a human than zero.\nMind you, I'd suggest this \"feature\" would need to be coded and deployed as\na future-hard-fork X*N years ahead of time. A-la Satoshi's blog post\nregarding increasing block size limit, a good enough approximation would be\nto add a block height check to the code that approximates X*N years, based\non 10 minute blocks. The transparency around such a change would need to\nbe radical and absolute.\n\nI'd also suggest that, similar to CLTV, it only makes sense to discuss\ncreating a \"never expire\" transaction output, if such a feature were being\nseriously considered.\n\nIf you think discussions around a block size increase were difficult, then\nwe'll need a new word to describe the challenges and vitriol that would\narise in arguments that will follow this discussion should it be seriously\nproposed, IMHO.\n\nI also don't think it's reasonable to conflate the discussion herein with\ndiscussion about what to do when ECC or SHA256 is broken. The\nweakening/breaking of ECC poses a real risk to the stability of Bitcoin -\nthe possible release of Satoshi's stash being the most obvious example -\nand what to do about that will require serious consideration when the time\ncomes. Even if the end result is the same - that coins older than \"X\" will\nbe invalidated - everything else important about the scenarios are\ndifferent as far as I can see.\n\nRodney\n\n\n\n\u003e\n\u003e\n\u003e Date: Tue, 22 Aug 2017 13:24:05 -0400\n\u003e From: Thomas Guyot-Sionnest \u003cdermoth at aei.ca\u003e\n\u003e To: Erik Aronesty \u003cerik at q32.com\u003e, Bitcoin Protocol Discussion\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e, Chris Riley\n\u003e \u003ccriley at gmail.com\u003e\n\u003e Cc: Matthew Beton \u003cmatthew.beton at gmail.com\u003e\n\u003e Subject: Re: [bitcoin-dev] UTXO growth scaling solution proposal\n\u003e Message-ID: \u003c4c39bee6-f419-2e36-62a8-d38171b15558 at aei.ca\u003e\n\u003e Content-Type: text/plain; charset=\"windows-1252\"\n\u003e\n\u003e In any case when Hal Finney do not wake up from his 200years\n\u003e cryo-preservation (because unfortunately for him 200 years earlier they\n\u003e did not know how to preserve a body well enough to resurrect it) he\n\u003e would find that advance in computer technology made it trivial for\n\u003e anyone to steal his coins using the long-obsolete secp256k1 ec curve\n\u003e (which was done long before, as soon as it became profitable to crack\n\u003e down the huge stash of coins stale in the early blocks)\n\u003e\n\u003e I just don't get that argument that you can't be \"your own bank\". The\n\u003e only requirement coming from this would be to move your coins about once\n\u003e every 10 years or so, which you should be able to do if you have your\n\u003e private keys (you should!). You say it may be something to consider when\n\u003e computer breakthroughs makes old outputs vulnerable, but I say it's not\n\u003e \"if\" but \"when\" it happens, and by telling firsthand people that their\n\u003e coins requires moving every once in a long while you ensure they won't\n\u003e do stupid things or come back 50 years from now and complain their\n\u003e addresses have been scavenged.\n\u003e\n\u003e --\n\u003e Thomas\n\u003e\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170823/8ee044f4/attachment.html\u003e",
"sig": "4698e726ad0ef6113a082ee3d85b5917ef27f503e28c78e2d36ddfe2289cd3d1598756dff249369c9254bd7dc7fd056e903737287aa5282c5547d77e797f8c42"
}