Это недоразумение на самом деле. Вы не получаете никакой конфиденциальности для изменения, поэтому мы не говорим о том, что изменения могут быть перемешаны. Пункт в документе только уточняет, что вы можете добавить адреса изменения в список вывода сделки CoinJoin в случае, если какая-то сторона не имеет точную сумму в случайном порядке (который будет почти всегда, так же, как и для обычных операций). Насколько я понимаю, это то, что делает ваша реализация?

---

Право, это не может быть предотвращено. Причина проверки для проверки дубликатов действительно разные, и есть больше, чем просто проверка в конце.

Рассмотрим перетасовка 50 участников с ровесниками P1, ..., P50 (в таком порядке). Злоумышленник управляет двумя узлами P2 и P50. Без дубликата чека, злоумышленник может нарушить несвязываемости Р1 полностью.

Атака выглядит следующим образом:
Р2 (злоумышленник) получает одиночный шифротекст от P1 (технически, это список шифртекстов с одной записью до сих пор) и удаляет один слой шифрования, в результате чего в другом зашифрованном С1. C1 имеет еще 49 слоев шифрования и внутренний открытый текст является выходным адрес OUT1 Р1.

P2 теперь должен добавить свой зашифрованный C2 (опять 49 слоев шифрования, внутренний открытый текст его выходной адрес OUT2).
Однако Р2 просто дублирует шифротекста C1, то есть устанавливает C2 = C1. Таким образом, Р2 посылает на самом деле [С1, С1] Р3.

Затем протокол продолжает нормально работать, но выходной адрес OUT1 P1 является теперь только один, что есть в два раза. Теперь предположим, что честные участники Р3, ..., P49 не проверяют на наличие дубликатов после расшифровки. Последний участник P50 (нападающий), который удаляет внутренний слой шифрования, получит список из 50 выходных адресов. Все эти адреса будут отличаться для вывода адрес OUT1 P1, который является единственным адресом, который дважды появляется в списке, за исключением! Так P50 просто знает выходной адрес P1 в, т.е. несвязываемости полностью нарушена для P1.

Для того, чтобы гарантировать, что атака остается незамеченной, P50 корректирует список выходных адресов перед публикацией, т.е. P50 заменяет одну из записей OUT1 по адресу под контролем злоумышленника. Обратите внимание, что P2 не будет жаловаться, что его выходной адрес не находится в окончательном списке, потому что P2 управляется злоумышленником, тоже.

Таким образом, злоумышленник может полностью deanonymize P1 только два сверстниками в правильных позициях. В противоположность этому, если протокол правильно реализован, хакеру 49 пэров полностью deanonymize P1, т.е. все ожидают P1 нужно быть злыми.

Этот пример, когда злоумышленник находится во второй и последней позиции наихудшая для P1 и легко объяснить, но атака работает также, если атакующий находится в других положениях и хочет, чтобы уменьшить размер анонимности, установленную для других сверстников.

---

Я пропустил это на самом деле. Тем не менее, он по-прежнему связываемый даже с новыми парами ключами: предположит снова, что атакующий контролирует P2 и P50. Тогда P2 видит, какой ключ принадлежит P1 и P50 можно использовать эти знания определить выходной адрес P1 в.

Вы говорите, что это зафиксировано в настоящее время с использованием общего счета. Как это работает? Вы также изменить схему шифрования? Нынешняя схема требует секретного ключа, даже для шифрования. Так что я не понимаю, как это должно работать, потому что вы, очевидно, не может дать, что секретный ключ для всех.