diff options
| author | yanmaani <yanmaani@cock.li> | 2021-10-17 15:14:41 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2021-10-17 15:14:51 +0000 |
| commit | 268c17dfe2efb22db818824273404f252b778c7c (patch) | |
| tree | fbe9af23291795858c73b5a241beb4007a907fdd | |
| parent | e215d36df03ef962b7a032035a4269f07fb5f04c (diff) | |
| download | pi-bitcoindev-268c17dfe2efb22db818824273404f252b778c7c.tar.gz pi-bitcoindev-268c17dfe2efb22db818824273404f252b778c7c.zip | |
Re: [bitcoin-dev] Year 2038 problem and year 2106 chain halting
| -rw-r--r-- | d4/83cee4e4fd88a1c0fc9a1f88d0eb03912b760e | 112 |
1 files changed, 112 insertions, 0 deletions
diff --git a/d4/83cee4e4fd88a1c0fc9a1f88d0eb03912b760e b/d4/83cee4e4fd88a1c0fc9a1f88d0eb03912b760e new file mode 100644 index 000000000..2f115cd99 --- /dev/null +++ b/d4/83cee4e4fd88a1c0fc9a1f88d0eb03912b760e @@ -0,0 +1,112 @@ +Return-Path: <yanmaani@cock.li> +Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 9423AC000D + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 17 Oct 2021 15:14:51 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp1.osuosl.org (Postfix) with ESMTP id 7B6C881ABB + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 17 Oct 2021 15:14:51 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -2.1 +X-Spam-Level: +X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 + tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, + DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, + RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] + autolearn=ham autolearn_force=no +Authentication-Results: smtp1.osuosl.org (amavisd-new); + dkim=pass (2048-bit key) header.d=cock.li +Received: from smtp1.osuosl.org ([127.0.0.1]) + by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id 8yKAJZj6nS8t + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 17 Oct 2021 15:14:50 +0000 (UTC) +X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 +Received: from mail.cock.li (mail.cock.li [37.120.193.124]) + by smtp1.osuosl.org (Postfix) with ESMTPS id 310AA81AAD + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 17 Oct 2021 15:14:50 +0000 (UTC) +MIME-Version: 1.0 +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cock.li; s=mail; + t=1634483681; bh=3aW7VTEmUtplctMXTXo8knR3MkGhvWo/ZCSt33qOohA=; + h=Date:From:To:Cc:Subject:In-Reply-To:References:From; + b=eooonMJoqaaLGKWdV6Y1tIriqRoWzs6Brg/gK/RIAPKHniQSTeZRrP8ZPs8iX0G7k + iEq5LT8sdc03/oVwsU+wTRQ+1bYSvVHm0U3FbkKNcFHmej3iXq50KID4E2lxoMkr9c + /C260SBhBjk3D0r3ygT12DhhUg+x4wKv+8ncn6l2YR6nkv9fhGVC0sAIwsUd4VrcGf + wm9+TkVLWRgF0JMeR0ePWdpEa4mqPLy0BDQexr4RQJt1pVcilIlGqbajcZlAQwhPlg + +aiebJNV1h7SDef86oPIZqfk1evD+5Z2fk0wSw5Y7+PKuWaLUxGQ9DNMDwFLdWXIry + i/58qtXnnXHEw== +Content-Type: text/plain; charset=US-ASCII; + format=flowed +Content-Transfer-Encoding: 7bit +Date: Sun, 17 Oct 2021 15:14:41 +0000 +From: yanmaani@cock.li +To: vjudeu@gazeta.pl +In-Reply-To: <143289360-eb35e705fded3eb4175a6f8d7669b3a0@pmq5v.m5r2.onet> +References: <143289360-eb35e705fded3eb4175a6f8d7669b3a0@pmq5v.m5r2.onet> +Message-ID: <0d0b22a297d112939e11c86aa1f6d736@cock.li> +X-Sender: yanmaani@cock.li +User-Agent: Roundcube Webmail/1.3.16 +X-Mailman-Approved-At: Sun, 17 Oct 2021 15:28:28 +0000 +Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Subject: Re: [bitcoin-dev] Year 2038 problem and year 2106 chain halting +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.15 +Precedence: list +List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Sun, 17 Oct 2021 15:14:51 -0000 + +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). + |