История изменений

тогда сервер должен

В истинной p2p нет никаких серверов.

хранить целиком файл у себя (а зачем тогда участники?)

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

хранить какой-то кусок и долбить только в него (тогда хитрый клиент может хранить только один кусок файла)

Узел, который хранит и отчитывается, не может заранее знать, какой фрагмент будет проверять Узел-«хозяин» файла. Каждая проверка верифицирует случайный фрагмент со случайной солью.

заранее нагенерировать себе индексов кусков, солей

Невозможно заранее нагенерировать все комбинации «солей» и «кусков». При длине соли 256 байт и файле размером более 256 байт, нет физического носителя, который бы смог бы сохранить все комбинации. И даже если найти такой носитель, то это будет в миллионы раз сложнее, чем хранить сам файл - при этом теряется смысл имитации хранения (так как легче хранить сам файл).

тогда сервер должен

В истинной p2p нет никаких серверов.

хранить целиком файл у себя (а зачем тогда участники?)

Не должен. Я тебе привел упрощенный пример.[br] В реальности узел может запрашивать у другого узла хэш фрагмента куска файла, если файл хранится по кускам (а не целиком).

хранить какой-то кусок и долбить только в него (тогда хитрый клиент может хранить только один кусок файла)

Узел, который хранит и отчитывается, не может заранее знать, какой фрагмент будет проверять Узел-«хозяин» файла.

заранее нагенерировать себе индексов кусков, солей

Невозможно заранее нагенерировать все комбинации «солей» и «кусков». При длине соли 256 байт и файле размером более 256 байт, нет физического носителя, который бы смог бы сохранить все комбинации. И даже если найти такой носитель, то это будет в миллионы раз сложнее, чем хранить сам файл - при этом теряется смысл имитации хранения (так как легче хранить сам файл).