<p>A hard fork is defined as a relaxation of the consensus rules. (In contrast a soft fork is defined as a restriction of the consensus rules.) Changing the consensus rules to ignore checkpoints by default (assuming the reference client Bitcoin Core defines the consensus rules) would be a relaxation of the consensus rules and hence theoretically a hard fork. However, in reality the checkpoints that have been defined in Bitcoin Core are many years deep and the probability of a re-org back to these checkpoints is infinitesimally small (zero to a huge number of decimal places). So practically it wouldn't have any impact.</p>
<p>Checkpoints and assumedvalid was discussed at this London BitDevs <a href="https://btctranscripts.com/london-bitcoin-devs/2021-11-02-socratic-seminar-assumeutxo/#assumedvalid-and-checkpoints" rel="nofollow noreferrer">Socratic Seminar</a> in November 2021 on AssumeUTXO.</p>

CC BY-SA 4.0
2022-07-04T15:40:33.000Z
2022-07-04T15:49:26.277Z
2022-07-04T15:49:26.277Z
Michael Folkson
<p>Yes.</p>
<p>Adding a checkpoint to your rules is a soft fork (makes invalid certain blocks that would have been valid). Once you have added that rule, removing it is a hard fork (makes valid certain blocks that would have been invalid).</p>
<p>Any rule one deploys is &quot;clearly enforced&quot;. There is no gray area in this distinction. Think of it from the context of your own single node. If you implement a new checkpoint above your current top checkpoint, you have deployed a soft fork.</p>
<p>The likelihood of a chain split is not an aspect of this distinction.</p>

CC BY-SA 4.0
2024-11-02T02:38:53.500Z
2024-11-02T02:38:53.500Z
evoskuil
<p>The <a href="https://github.com/bitcoin/bitcoin/blob/e4e201dfd9a9dbd8e22cac688dbbde16234cd937/src/validation.h#L67" rel="nofollow noreferrer">value</a> of <code>DEFAULT_CHECKPOINTS_ENABLED</code> is <code>true</code> and changing it will allow nodes <strong>using the default settings</strong> to accept blocks that would be currently rejected during a potential reorg. Is this change considered a hard-fork, or only changes to clearly enforced consensus rules can qualify as such?</p>

CC BY-SA 4.0
2022-07-04T20:49:32.153Z
That's a bit of a stretch. Related: https://bitcoin.stackexchange.com/a/75735/5406
Murch
<blockchain-fork><consensus><checkpoints><assume-valid>
Is the removal of Bitcoin checkpoints considered a hard-fork?
Fernando N.
# Is the removal of Bitcoin checkpoints considered a hard-fork?

(Asked by: username_0 on 2022-07-04)

The [value](https://github.com/bitcoin/bitcoin/blob/e4e201dfd9a9dbd8e22cac688dbbde16234cd937/src/validation.h#L67) of `DEFAULT_CHECKPOINTS_ENABLED` is `true` and changing it will allow nodes **using the default settings** to accept blocks that would be currently rejected during a potential reorg. Is this change considered a hard-fork, or only changes to clearly enforced consensus rules can qualify as such?

**Tags:** blockchain-fork, consensus, checkpoints, assume-valid

> **Comments:**
> **username_1**: That's a bit of a stretch. Related: https://bitcoin.stackexchange.com/a/75735/5406  

---

## 2 answers

### Answer by username_2 on 2022-07-04. Score: 3

A hard fork is defined as a relaxation of the consensus rules. (In contrast a soft fork is defined as a restriction of the consensus rules.) Changing the consensus rules to ignore checkpoints by default (assuming the reference client Bitcoin Core defines the consensus rules) would be a relaxation of the consensus rules and hence theoretically a hard fork. However, in reality the checkpoints that have been defined in Bitcoin Core are many years deep and the probability of a re-org back to these checkpoints is infinitesimally small (zero to a huge number of decimal places). So practically it wouldn't have any impact.

Checkpoints and assumedvalid was discussed at this London BitDevs [Socratic Seminar](https://btctranscripts.com/london-bitcoin-devs/2021-11-02-socratic-seminar-assumeutxo/#assumedvalid-and-checkpoints) in November 2021 on AssumeUTXO.


---

### Answer by username_3 on 2024-11-02. Score: 0

Yes.

Adding a checkpoint to your rules is a soft fork (makes invalid certain blocks that would have been valid). Once you have added that rule, removing it is a hard fork (makes valid certain blocks that would have been invalid).

Any rule one deploys is "clearly enforced". There is no gray area in this distinction. Think of it from the context of your own single node. If you implement a new checkpoint above your current top checkpoint, you have deployed a soft fork.

The likelihood of a chain split is not an aspect of this distinction.


---

