# Longer Difficulty Adjustment Period

**URL:** <https://discourse.ironfish.network/t/longer-difficulty-adjustment-period/90>\
**Category:** Consensus\
**Created:** [January 30, 2024, 8:00pm UTC](https://discourse.ironfish.network/t/longer-difficulty-adjustment-period/90 "2024-01-30T20:00:06Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![danielfish](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.ironfish.network/danielfish/32/9_2.png) [@danielfish](https://discourse.ironfish.network/u/danielfish)\
**Post date:** [January 30, 2024, 8:00pm UTC](https://discourse.ironfish.network/t/longer-difficulty-adjustment-period/90/1 "2024-01-30T20:00:07Z")

</div>

## Background

Currently, when mining, a block’s difficulty can only be adjusted for 99 buckets, or 16.5 minutes. This results in a maximum adjustment per block of around 5% (4.834%). (You can play with the numbers in this fiddle: [Edit fiddle - JSFiddle - Code Playground](https://jsfiddle.net/jspafford/mejhn90a/345/)).

The issues here are 2 fold:

- The blockchain is susceptible to a Denial Of Service attack where someone temporarily bumps the difficulty very high, then turns off their miners. This results in the blockchain not moving for a potentially very long time time. While this is not trivial to do on mainnet, it is a possibility. It has happened on testnet several times and requires manual intervention to bring down the difficulty. If it happened on mainnet, it’s possible that it would require a hardfork to fix as the amount of hashpower required to fix could be too much to gather.
- We are getting ready to adjust the hashing algorithm which is substantially slower than the current Blake3 implementation. This would lead to significant interruption to the blockchain during the transition.

## Goals

- Allow a smoother transition to the new hashing algorithm
- Mitigate the DoS vulnerability

## Difficulty Difference

Lollidieb mentioned that from his machines he’s seeing change from 10,000 Mh (blake3) → 40 Mh (FishHash). About a 250x difference

## Implementation

Adjust the max number of buckets from 99 to 999?

- The exact number can be tweaked, but the idea is the same regardless.
- The exact number should probably be determined after we have an idea of how big of hashpower adjustment we will have during the hashing algorithm switch

## Open Questions

- How does this affect overall spikiness of difficulty, and what ramifications does this have on normal operation
  - 109 blocks (out of 375k) have a difference of greater than 990 seconds, meaning these blocks may have had a larger difficulty swing under this new change. However, a vast majority of them are close to the limit so the difference would’ve been minimal.
  - It’s also worth noting that a substantial number of these blocks occurred in a short period of time - around blocks 315-375k.

---

<div class="post-metadata">

**Author:** ![mat](https://avatars.discourse-cdn.com/v4/letter/m/e9c0ed/32.png) [@mat](https://discourse.ironfish.network/u/mat)\
**Post date:** [February 9, 2024, 9:28pm UTC](https://discourse.ironfish.network/t/longer-difficulty-adjustment-period/90/2 "2024-02-09T21:28:06Z")

</div>

Per some number crunching and discussions, we’re looking at implementing the bucket change from 99 buckets to 200 buckets. This results in a maximum per-block difficulty change downward from about 4.8% over ~17 minutes to 9.7% over ~34 minutes.

Further, we’re looking at implementing a one-time difficulty adjustment of `difficulty / 100` at the sequence which activates FishHash, so that the transition doesn’t result in days of several-hour-blocktimes.
