From: vjudeu@gazeta•pl
To: ZmnSCPxj <ZmnSCPxj@protonmail•com>,
"yanmaani@cock•li" <yanmaani@cock•li>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Year 2038 problem and year 2106 chain halting
Date: Sat, 16 Oct 2021 11:06:17 +0200 [thread overview]
Message-ID: <143903239-0c7634127ba6ddee7e69b14740b993cd@pmq3v.m5r2.onet> (raw)
In-Reply-To: <nSiUl71p9JyISxvRJ3Jq71zNahe-rpanbFFv1MSHSk7rUKjq36yD7vmrJQ5Pnh5oUdDAFflgSzbCE5KK7RacFRepvjqFc9xp9qT7hU-twXA=@protonmail.com>
> What happens if a series of blocks has a timestamp of 0xFFFFFFFF at the appropriate time?
The chain will halt for all old clients, because there is no 32-bit value greater than 0xffffffff.
> 1. Is not violated, since "not lower than" means "greater than or equal to"
No, because it has to be strictly "greater than" in the Bitcoin Core source code, it is rejected when it is "lower or equal to", see: https://github.com/bitcoin/bitcoin/blob/6f0cbc75be7644c276650fd98bfdb6358b827399/src/validation.cpp#L3089-L3094
> 2. Is not violated, since it would be a past actual real time.
If the current time is 0x0000000100000000, then the lowest 32 bits will point to some time around 1970, so for old clients two rules are violated at the same time.
> 3. Is not violated since 0xFFFFFFFF < 0x100000000.
This is hard to change, because 32-bit timestamps are included in block headers, so using any wider data type here will make it hardware-incompatible and will cause a hard-fork. That's why I think new timestamps should be placed in the coinbase transaction. But that still does not solve chain halting problem.
To test chain halting, all that is needed is starting regtest and producing one block with 0xffffffff timestamp, just after the Genesis Block. Then, median time is equal to 0xffffffff and adding any new blocks is no longer possible. The only soft-fork solution I can see require overwriting that block.
Example from https://bitcointalk.org/index.php?topic=5365359.0
submitblock 0100000006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910f3663c0de115e2239e05df4df9c4bfa01b8e843aaf5dae590cac1d9bac0d44c0fffffffffffff7f200100000001020000000001010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0200f2052a010000001976a91462e907b15cbf27d5425399ebf6f0fb50ebb88f1888ac0000000000000000266a24aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf90120000000000000000000000000000000000000000000000000000000000000000000000000
null
generatetoaddress 1 mpXwg4jMtRhuSpVq4xS3HFHmCmWp9NyGKt
CreateNewBlock: TestBlockValidity failed: time-too-old, block's timestamp is too early (code -1)
I don't know any timestamp that can be used in any next block and accepted by old nodes.
On 2021-10-16 01:01:54 user ZmnSCPxj <ZmnSCPxj@protonmail•com> wrote:
> Good morning yanmaani,
> It's well-known. Nobody really cares, because it's so far off. Not
> possible to do by softfork, no.
I think it is possible by softfork if we try hard enough?
> 1. The block timestamp may not be lower than the median of the last 11
> blocks'
>
> 2. The block timestamp may not be greater than the current time plus two
> hours
>
> 3. The block timestamp may not be greater than 2^32 (Sun, 07 Feb 2106
> 06:28:16 +0000)
What happens if a series of blocks has a timestamp of 0xFFFFFFFF at the appropriate time?
In that case:
1. Is not violated, since "not lower than" means "greater than or equal to", and after a while the median becomes 0xFFFFFFFF and 0xFFFFFFFF == 0xFFFFFFFF
2. Is not violated, since it would be a past actual real time.
3. Is not violated since 0xFFFFFFFF < 0x100000000.
In that case, we could then add an additional rule, which is that a 64-bit (or 128-bit, or 256-bit) timestamp has to be present in the coinbase transaction, with similar rules except translated to 64-bit/128-bit/256-bit.
Possibly a similar scheme could be used for `nLockTime`; we could put a 64-bit `nLockTime64` in that additional signed block in Taproot SegWit v1 if the legacy v`nLockTime` is at the maximum seconds-timelock possible.
Regards,
ZmnSCPxj
next prev parent reply other threads:[~2021-10-16 9:06 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
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 [this message]
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=143903239-0c7634127ba6ddee7e69b14740b993cd@pmq3v.m5r2.onet \
--to=vjudeu@gazeta$(echo .)pl \
--cc=ZmnSCPxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=yanmaani@cock$(echo .)li \
/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