Может ли злонамеренный плательщик деанонимизировать получателя в Zcash?

tl;dr Алиса может раскрыть платежи, которые она сделала Бобу. Она не может раскрыть платежи, которые другие сделали Бобу, или раскрыть, что (если вообще) Боб делает с ZEC, отправленным Алисой.

Выявление прообраза обязательства по ноте только доказывает, что Алиса знает прообраз. Это не доказывает, что Алиса отправила транзакцию, потому что доказательство можно воспроизвести: после раскрытия любой может взять случайность и записать данные и показать их кому-то другому.

Чтобы Алиса доказала кому-то, что она отправила транзакцию, она может сделать следующее:

• Напишите сообщение, содержащее:
  • Закрытый ключ esk, используемый для шифрования заметки (случайность и ценность) для Боба.
  • Платежный адрес Боба.
  • Строка вызова, выбранная человеком Алисой, убедительна.
• Подпишите сообщение, используя закрытый ключ joinSplitPrivKey, соответствующий тому joinsplitPubKey, который изначально использовался для подписи транзакции.

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

То, что вы описываете, по сути является той же проблемой, что и приложения для обмена сообщениями со сквозным шифрованием: кто-то, имеющий предполагаемый доступ к данным, может случайно или намеренно раскрыть их. Удаление этой потенциальной утечки конфиденциальности по определению означало бы, что Алиса не может видеть некоторые или все подробности о своих исходящих транзакциях, что либо является противоречием (в модели Zcash Алиса должна быть в состоянии вычислить обязательство по ее прообразу, чтобы для создания действительных транзакций), либо совершенно непригодная для использования платежная система!

Обратите внимание, однако, что хотя Алиса может доказать, что она отправила транзакцию Бобу, она не может ничего рассказать о том, что Боб делает с полученной запиской (поскольку у нее нет ключа расходования Боба, и поэтому она не может вычислить аннулятор, который будет раскрываться во время проведения). Способность Алисы раскрывать информацию ограничена информацией, которую она когда-либо могла просмотреть.

Чтобы добавить к ответу @str4d, вот ссылки на общедоступную документацию и обсуждение функции раскрытия платежа:

• Ключи выборочного раскрытия и защищенного просмотра — блог Zcash
• Раскрытие платежа (экспериментальная функция)
• Введение в раскрытие информации о платежах в Zcash — Гарет Дэвис

Обратите внимание, что если бы Боба беспокоила такая возможность, он мог бы дать Алисе уникальный адрес для оплаты ему, чтобы раскрытый платеж на этот адрес не мог быть связан с другими его адресами. Это предлагается в разделе 3.1 спецификации протокола.

В Sapling есть новая функция под названием «диверсифицированные платежные адреса», которая делает это использование более эффективным: Боб может выдавать уникальный диверсифицированный адрес каждому потенциальному плательщику и по-прежнему может сканировать цепочку блоков на наличие входящих платежей так же эффективно, как если бы он только один адрес. Мы планируем интегрировать это в Zcash, эквивалентный BIP 32 (иерархические детерминированные адреса), чтобы все секреты, связанные с кошельком, могли быть скопированы с использованием одного начального числа.