Мой вопрос был -- а если скорость нашей проверки цепочек, при этом, увеличится в 200 раз?
Для того, чтобы понять попалось нам pq или pqr, надо найти какой-нибудь множитель и проверить его и/или остаток на простоту. А для того, чтобы понять попалось ли нам простое, надо только проверить его на простоту.
Я отвечал на тот вопрос, который процитировал. А это уже другой вопрос

В прошлом году, чтобы "пощупать" этот вопрос делал такую простенькую модель:
1. У нас есть выбор: или "ловить"

, или

в каждой позиции.
2. Вероятность удачи

-

, вероятность удачи

-

. Или около того.
3. Длина цепочки (количество позиций), не помню, но длинная. Пусть 15 или 21.
4. Стоимость проверки

- один попугай.
5. Стоимость проверки

- сколько-то попугаев. (это варьировалось).
6. Порядок проверки цепочки:
а) проверяем по порядку

. После первой же неудачи - переход к следующей цепочке.
б) потом проверяем по порядку

. После первой же неудачи - переход к следующей цепочке.
и считаем сумму попугаев.
7. Вероятность найти цепочку - произведение вероятностей

и

по всем позициям.
8. Проверяем количество цепочек равное единица делить на вероятность найти цепочку. И считаем суммарное количество попугаев.
Всё это считаем так:
1. Фиксируем стоимость в попугаях проверки на

.
2. Прогоняем для разного количества

и

(но при одинаковом суммарном количестве позиций).
3. Находим оптимальное количество

для данной стоимости проверки

.
4. Повторяем 1-3 для другой стоимости проверки на

.
Там забавные эффекты выползают. Даже на такой простой модели. Модель, например, не учитывает "стоимость" перевода

, а это стОит увеличения чисел в цепочке.
-- добавлено через 3 минуты --В итоге, пока факторизация хоть как-то работает, выгоднее искать цепочки с pqr, ну или хоть pq, но не p.
Там есть нюанс. В зависимости как "звезды" сойдутся (от конкретных числовых значений для поиска конкретных цепочек) оптимальным может быть ненулевое количество (искомых) простых, но и во всех позициях цепочки. Что мы и наблюдали при поиске недавних рекордов.