Если такой пакет уже проходил через любой произвольный узел, он НЕ должен передаваться дальше. Никаких дублей пакетов быть не должно.

Как раз с копиями пакетов других участников нет никаких проблем.

Да, это сгенерирует нагрузку на получателя, но после нескольких таких фиктивных пакетов отправителя можно смело банить.

Достаточно легко представить ботнет устанавливающий "жертвам" клиента сети модифицированного таким образом чтобы маскироваться под честные узлы и в то же время проводить управляемые атаки целевых субъектов. Такой узел никому ничего не должен. И достоверно определить его не получится.

Если копия одна, то проблемы конечно нет. И если их десяток. А если миллион и приходящий с миллиона же узлов?

Прежде чем банить пробуем ответить на "вопросы к залу". Кого будем банить?

Каким образом определять что пакет "фиктивный"? Транзитным узлам тоже делать проверку на принадлежность подписывающего к субъекту?

Да. Проблемы возникнут только при использовании серверов авторизации. Впрочем проще тогда уж задосить сам сервер авторизации.

Против вирусов и термального криптоанализа мы ничего сделать не можем.

Такой пакет дойдет только до первого хопа, грубо говоря. Хоп посмотрит - опа, "такой пакет уже был" и ничего дальше отправлять не будет.

Вероятно, пакеты по определенным признакам.

Ну, даже сама проверка на принадлежность к субъекту может быть относительно ресурсоемкой и, следовательно, способствующей DoS. Надо что-то придумать что-бы у посторонних узлов не было необходимости делать такую проверку.

Как минимум возможности вирусовы надо ограничивать. Это объективная реальность виндопользователей. И процентов 90 пользователей это не волнует если вирус им не лочит комп и провайдер их не блокирует за рассылку спама.

Банить можно транспортный узел имея доказательство нарушения им установленных правил игры.

Ну, даже сама проверка на принадлежность к субъекту может быть относительно ресурсоемкой и, следовательно, способствующей DoS. Надо что-то придумать что-бы у посторонних узлов не было необходимости делать такую проверку.

Т.е. тогда получаем просто две подписи - "транспортную" и последнего "участнику субъекта". В общем-то, я лично НЕ против такого варианта.

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

Нужны кому? Мне не нужны. Шлешь каку - я с тобой не играю.

Нужно сделать это "дешевой" операцией.

Неправильная постановка вопроса. Один узел редко может генерировать нагрузку c которой не справиться другой. А вот сотня тысяч узлов в лёгкую положит тысячу другую. И c этим нам необходимо что-то делать.

В аналогии из реального мира транспортные узлы это курьеры международной службы доставки. Не хочешь играть? Ну так вези сам пакет из Москвы в Лос-Анджелес. Страшно первому отдать пакет с "голосом против" бородатому дядьке с большим автоматом. Но придётся, ведь с курьерами мы не играем?
А курьеру что надо? Правильно, опечатанный пакет на котором стоит твоя подпись о том что за внутренности пакета отвечаешь ты, если пакет доставлен в целостности. Лёгкий способ проверки целостности пакета. И пара подписей от тех от кого получен пакет и кому передан. Правила отработаны веками. Пакет вскрыт, то ты его не берёшь. Вскрытый пакет могут взять, а могут и нет. Но за вскрытие пакета отвечает конкретный курьер получивший пакет целым.

А не получится. Если сторонний узел получает пакет, то он должен проверить как минимум существование субъекта сделав запрос. Что автоматом выводит стоимость проверки за разумные пределы.

Я не представляю как мой узел смогут положить сотня тысяч злых ботов и вообще зачем им это надо.

Ужасная аналогия из которой ничего не понятно. Вот мой пример: ваш узел прислал мне пакет с подписью участника который не принадлежит субъекту голосования, я вас добавляю в черный список и никогда больше не принимаю пакеты от вас. В данном примере 1 узел сможет сгенерировать 1 пакет нагрузки. Можно сделать порог "n пакетов, в течении t".

Зависит от организации хранения данных - этот вопрос все еще открыт.