public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: vjudeu@gazeta.pl
To: James Lu <jamtlu@gmail.com>,bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Proposal: Auto-shutdown as 5-year fork window
Date: Sun, 12 Sep 2021 21:38:47 +0200	[thread overview]
Message-ID: <140815317-3f36d45615e153403b3c83e26c266773@pmq4v.m5r2.onet> (raw)
In-Reply-To: <CANQHGB2SwZGrFAWC0Rd88qACTjPa1L+hbV54LG87M9RJZni+4Q@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1198 bytes --]

You can do that kind of change in your own Bitcoin-compatible client, but you cannot be sure that other people will run that version and that it will shut down when you want. Many miners use their own custom software for mining blocks, the same for mining pools. There are many clients that are compatible with consensus, but different than Bitcoin Core.
Also you should notice that Bitcoin community make changes by using soft-forks, not hard-forks. Backward compatibility is preserved as often as possible and there is no reason to change that. Any change can be deployed in a soft-fork way, even "evil soft-forks" are possible, as described in https://petertodd.org/2016/forced-soft-forks. I think that kind of soft-fork is still better than hard-fork.
On 2021-09-12 21:16:00 user James Lu via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
If MTP-11 is greater than 5 years after the release date of the current software version, the full node should shut down automatically.
 
This would allow writing code that gives the community ~5 years to upgrade to a version that executes a new hard fork while keeping everyone in consensus, provided the change is non-controversial.

[-- Attachment #2: Type: text/html, Size: 1740 bytes --]

      reply	other threads:[~2021-09-12 19:39 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-12 15:26 [bitcoin-dev] Proposal: Auto-shutdown as 5-year fork window James Lu
2021-09-12 19:38 ` vjudeu [this message]

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=140815317-3f36d45615e153403b3c83e26c266773@pmq4v.m5r2.onet \
    --to=vjudeu@gazeta.pl \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=jamtlu@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