From: yanmaani@cock•li
To: vjudeu@gazeta•pl
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Year 2038 problem and year 2106 chain halting
Date: Sun, 17 Oct 2021 15:14:41 +0000 [thread overview]
Message-ID: <0d0b22a297d112939e11c86aa1f6d736@cock.li> (raw)
In-Reply-To: <143289360-eb35e705fded3eb4175a6f8d7669b3a0@pmq5v.m5r2.onet>
What, no. The `k` value is calculated implicitly, because there's only
one value of it that could ever be valid - if `k` is 1 too small, we're
70 years too far back, and then the block will violate median of last
11. If `k` is 1 too large, we're 70 years too far in the future, then
the block will violate 2 hour rule. Nothing is added to coinbase or
anywhere else.
It's possible that you'd need some extra logic for locktime, yes, but it
would only be a problem in very special cases. Worst-case, you'll have
to use block time locking in the years around the switch, or softfork in
64-bit locking.
But unless I'm missing something, 32-bit would be enough, you just
wouldn't be able to locktime something past the timestamp for the
switch. After the switchover, everything would be back to normal.
This is a hardfork, yes, but it's a hardfork that kicks in way into the
future. And because it's a hardfork, you might as well do anything, as
long as it doesn't change anything now.
On 2021-10-15 22:22, vjudeu@gazeta•pl wrote:
> Your solution seems to solve the problem of chain halting, but there
> are more issues. For example: if you have some time modulo 2^32, then
> you no longer know if timestamp zero is related to 1970 or 2106 or
> some higher year. Your "k" value representing in fact the most
> significant 32 bits of 64-bit timestamp has to be stored in all cases
> where time is used. If there is no "k", then zero should be used for
> backward compatibility. Skipping "k" could cause problems related to
> OP_CHECKLOCKTIMEVERIFY or nLockTime, because if some transaction was
> timestamped to 0xbadc0ded, then that transaction will be valid in
> 0x00000000badc0ded, invalid in 0x0000000100000000, and valid again in
> 0x00000001badc0ded, the same for timelocked outputs.
>
> So, I think your "k" value should be added to the coinbase
> transaction, then you can combine two 32-bit values, the lower bits
> from the block header and the higher bits from the coinbase
> transaction. Also, adding your "k" value transaction nLockTime field
> is needed (maybe in a similar way as transaction witness was added in
> Segwit), because in other case after reaching 0x0000000100000000 all
> off-chain transactions with timelocks around 0x00000000ffffffff will
> be additionally timelocked for the next N years. The same is needed
> for each OP_CHECKLOCKTIMEVERIFY, maybe pushing high 32 bits before the
> currently used value will solve that (and assuming zero if there is
> only some 32-bit value).
next prev parent reply other threads:[~2021-10-17 15:14 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-13 19:16 vjudeu
2021-10-15 15:27 ` James Lu
2021-10-17 8:19 ` Kate Salazar
2021-10-17 22:38 ` damian
2021-10-15 15:44 ` yanmaani
2021-10-15 22:22 ` vjudeu
2021-10-17 15:14 ` yanmaani [this message]
2021-10-17 15:46 ` Kate Salazar
2021-10-18 2:55 ` yanmaani
2021-10-15 23:01 ` ZmnSCPxj
2021-10-16 9:06 ` vjudeu
2021-10-16 20:37 ` David Bakin
2021-10-16 21:34 ` Kate Salazar
2021-10-16 23:23 ` ZmnSCPxj
2021-10-17 7:24 vjudeu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0d0b22a297d112939e11c86aa1f6d736@cock.li \
--to=yanmaani@cock$(echo .)li \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=vjudeu@gazeta$(echo .)pl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox