The scheduler

The scheduler decides which miner gets which fragment. It enforces two rules in the database statement that hands out work, so no code path can skip them.

Rule one: one lane per job

The first time a mining session pulls from a job, the scheduler picks the lane with the most work left and records it for that session and that job. Every later pull from the job is restricted to that lane. Because the client coloured the lanes so that neighbours differ, a session can never receive fragment n and fragment n+1 of the same document.

Block 4 must not be adjacent to block 5

The pool does not know the order; it does not need to. The colouring carries the constraint, and the scheduler only has to keep each session inside one colour.

Rule two: at most 12 per job

A session holds at most 12 fragments of one job over its lifetime, cross-checks included. A job of 400 fragments therefore needs at least 34 sessions to be embedded by others; the rest waits, or the owner's own tab mines it.

The owner's tab

A client that proves it holds the job secret may mine its own job from its own tab with no lane and no cap: it already holds the file. This is how a job finishes when no other miner is online, and the app offers it with one click. Work a client does on its own free job earns no notes.

Pulls and timeouts

• A pull returns up to 8 fragments, plus canaries, from the oldest open jobs first.
• An assigned fragment not returned within 90 seconds goes back to its lane, never to the same session.
• A job holds at most 2,000 fragments; larger corpora are sent as several jobs.
• Lanes per job: 6.

Sessions are random ids a browser asks for; nothing ties two sessions to one person, so a miner who opens many sessions can collect more fragments of a job, each capped and non-adjacent. The scrub and the decoys are the answer to that, and they are applied before the pool sees anything.