public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: yanmaani@cock.li
To: Kate Salazar <mercedes.catherine.salazar@gmail.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Year 2038 problem and year 2106 chain halting
Date: Mon, 18 Oct 2021 02:55:32 +0000	[thread overview]
Message-ID: <01b421b8839b396e0ccc4f3a1c5aa627@cock.li> (raw)
In-Reply-To: <CAHiDt8BY1dT=PhjudHbJS01eqm=So7Q1tvo8ft9sFLT=D33Kfg@mail.gmail.com>

Well, it's the right word. If you're going to do a hardfork by changing 
the timestamp definition, you're already doing a hardfork. At that 
point, you've already crossed the Rubicon and might as well put in any 
other necessary changes (e.g. to transaction locking), because it will 
be as much of a hardfork either way.

The important bit here is "as long as it doesn't change anything now" - 
this is indeed a hardfork, but it's a timestamp-activated hardfork that 
triggers in 2106. Until that point, it has absolutely no bearing on 
consensus rules (as opposed to the other proposals, which are at least a 
soft-fork today).

I understand that there's some problems in getting consensus for forks, 
but surely we can agree that everyone will update their Bitcoin at least 
once in the next 85 years? (If they don't, they're doomed anyway.)

On 2021-10-17 15:46, Kate Salazar wrote:
> Hi yanmaani
> 
...
>> 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.
> 
> "Anything" is quite a word.
> Ideally, hard fork requires upgrading every node that can be upgraded,
> 
> or at least have the node operator's consent to lose the node (for
> every
> node that can't be upgraded).
> 
...
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


  reply	other threads:[~2021-10-18  2:55 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-13 19:16 [bitcoin-dev] Year 2038 problem and year 2106 chain halting 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 [this message]
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=01b421b8839b396e0ccc4f3a1c5aa627@cock.li \
    --to=yanmaani@cock.li \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=mercedes.catherine.salazar@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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