> For the complete documentation index, see [llms.txt](https://solvency.gitbook.io/picoin/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://solvency.gitbook.io/picoin/mining/difficulty-adjustment-and-segment-length.md).

# Difficulty Adjustment and Segment Length

### Difficulty Adjustment

Picoin difficulty regulates computational workload, not token issuance.

The base reward remains fixed at the protocol level and is distributed according to the active reward allocation. Difficulty only changes how much Proof of Pi work is required for future tasks.

The current difficulty model is based on three protocol parameters:

* segment size;
* sample count;
* maximum Pi position range.

The effective difficulty is calculated as:

```
difficulty =
  (segment_size / 64)
  * (sample_count / 8)
  * (log10(max_pi_position) / log10(10000))
```

Where:

* `segment_size` measures the number of hexadecimal Pi positions assigned to the miner;
* `sample_count` measures the number of validation samples requested during reveal;
* `max_pi_position` defines the search space for pseudo-random range assignment.

This makes difficulty simple, auditable, and deterministic.

Picoin stores the active protocol parameters in the local protocol state. Each accepted block records the difficulty and reward rules used at the time of acceptance. Tasks and blocks also reference the active protocol parameter version so that later retargets do not retroactively change already-assigned work.

#### Automatic Retargeting

Picoin adjusts difficulty by epochs.

Current retarget configuration:

```
epoch_blocks = 10
target_block_ms = 60000
tolerance = 20%
max_adjustment_factor = 1.25
```

After enough accepted blocks close an epoch, the protocol measures average task duration using recorded block timing data.

If the average accepted block time is significantly faster than the 60-second target, the next epoch increases work.

If the average accepted block time is significantly slower than the target, the next epoch decreases work.

The adjustment is intentionally conservative. A single retarget cannot change difficulty by more than `1.25x` in either direction.

Conceptually:

```
observed_avg_ms = average(total_task_ms over epoch)
ratio = target_block_ms / observed_avg_ms
adjustment = clamp(ratio, 1 / max_adjustment_factor, max_adjustment_factor)
new_difficulty = old_difficulty * adjustment
```

The protocol then derives future task parameters from the new difficulty profile.

This protects the network from sudden jumps caused by short-term variance, fast miners, slow machines, or temporary performance spikes.

### Segment Length

A segment is the finite hexadecimal range of Pi assigned to a miner for a Proof of Pi task.

For example, a task may assign:

```
positions 3667..3746
segment_length = 80
algorithm = bbp_hex_v1
```

The miner must compute that finite range, commit to the result hash and Merkle root, and later reveal validation samples.

Segment length is one of the main levers used by Picoin to scale computational work.

Shorter segments make mining easier and faster.

Longer segments increase compute requirements and make each accepted block represent more useful work.

In the current protocol, the initial segment size may start at 64 hexadecimal positions and increase through retargeting when blocks are produced too quickly.

Segment length interacts with validation as follows:

* larger segments increase miner workload;
* sample count increases validator workload;
* audit samples increase retroactive security;
* max position range increases assignment entropy.

The protocol intentionally separates these parameters so the network can tune mining cost, validation cost, and audit cost independently.

#### Why Segment Length Matters

Segment length directly affects:

* miner compute time;
* task difficulty;
* Merkle tree size;
* validation sample distribution;
* audit coverage;
* future scalability.

A segment is not stored entirely on-chain.

Picoin stores only:

* result hash;
* Merkle root;
* samples;
* proofs;
* validator approvals;
* block metadata.

This allows the protocol to scale Proof of Pi work without storing all computed digits.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://solvency.gitbook.io/picoin/mining/difficulty-adjustment-and-segment-length.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.