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.