Timing.

Временная шкала для иллюстрации
1) Новый блок опубликован в сети (время начинается)
2) В настоящее время все шахтеры теперь работают на устаревшем (данные бесполезных)
3) сервер Бассейн должен быть уведомлен об изменении блока (задержка от среднего блока к серверу пула, больше ссылок = лучше)
4) сервер Пул должен генерировать новый Merkle дерево
5) сервер Pool должен выдавать LP и новую работу (задержку между сервером пула & шахтер)
6) Клиент должен получать LP и изменять данные прорабатываются (время остановки)

Количество времени, потраченное на эти 6 шагов будет варьироваться в зависимости от бассейна и, таким образом, бассейны будут иметь различную величину stales.

Некоторые бассейны (например, слякоть, например) полный шаг 5 по ранжиру шахтера, чтобы обеспечить наибольшие шахтер обновляются так быстро, как это возможно. Это обеспечит эффективную мощность хеширования ближе к максам быстрее.

Хороший бассейн должен:
а) иметь тысячи подключений к сети Bitcoin, чтобы убедиться, что она быстро уведомлена все блоки, найденных
б) активно искать IP-адрес других генераторов блоков, чтобы гарантировать, что они находятся в списке известных узлов
в) имеет достаточную мощность процессора, чтобы быстро (как в долях секунды) генерирует новую работу для всех шахтеров после смены кадра
г) имеет низкую связь задержки для всех шахтеров (это частично вне контроля пула)

Stales никогда не может быть доведена до 0, но они могут быть значительно снижены. На Bitminter моей процент брака за предыдущие 30 дней составляет 0,04%. Я считаю, около 0,02% от происходит из-за сбоев оборудования (один GPU, имеет более высокую скорость, чем все другие GPU отвергают) таким образом, примерно 0,03% этого является бассейн Неэффективность который является довольно чертовски хорошо. Все, что ниже 0,1% следует считать хорошим. Все, что выше 1% ужасно плохо. Большинство шахтеров имеют от 0,1% до 1% несвежей скорости.