¿Puede el pagador malicioso desanonimizar al beneficiario en Zcash?

tl; dr Alice puede revelar los pagos que le hizo a Bob. No puede revelar los pagos que otros le hicieron a Bob, ni revelar qué (si es que hace algo) Bob con el ZEC que envió Alice.

Revelar la preimagen del compromiso de la nota solo prueba que Alice conoce la preimagen. No prueba que Alice envió la transacción, porque la prueba se puede reproducir: una vez revelada, cualquiera puede tomar la aleatoriedad y anotar los datos y mostrárselos a otra persona.

Para que Alice le demuestre a alguien que envió la transacción, puede hacer lo siguiente:

• Escribe un mensaje que contenga:
  • La clave privada eskutilizada para cifrar la nota (aleatoriedad y valor) a Bob.
  • Dirección de pago de Bob.
  • Una cadena de desafío elegida por la persona a la que Alice está convenciendo.
• Firme el mensaje utilizando la clave privada joinSplitPrivKeycorrespondiente a la joinsplitPubKeyque se utilizó originalmente para firmar la transacción.

El mensaje firmado es una prueba de que Alice tiene acceso actualmente joinSplitPrivKey(porque la cadena de desafío es nueva). Suponiendo que joinSplitPrivKeynunca se revele, Alice es indistinguible de la persona que creó la transacción (es decir, ella o alguien con sus claves de gasto realizó el pago). Esto es lo que llamamos una divulgación de pago y es cómo, por ejemplo, demostraría a un intercambio (o un servicio de resolución de disputas de terceros) que efectivamente les pagó.

Lo que está describiendo es fundamentalmente el mismo problema que tienen las aplicaciones de mensajería con el cifrado de extremo a extremo: alguien con acceso previsto a los datos puede revelarlos accidental o intencionalmente. Eliminar esta posible fuga de privacidad significaría, por definición, que Alice no puede ver algunos o todos los detalles sobre sus propias transacciones salientes, lo cual es una contradicción (en el modelo Zcash, Alice necesita poder calcular un compromiso a partir de su imagen previa para para crear transacciones válidas), o un sistema de pago completamente inutilizable.

Sin embargo, tenga en cuenta que aunque Alice puede probar que envió una transacción a Bob, no puede revelar nada sobre lo que Bob hace con la nota que recibió (porque no tiene la clave de gastos de Bob y, por lo tanto, no puede calcular el anulador que lo haría). ser revelado en pasar el tiempo). La capacidad de Alice para revelar información se limita a la información que alguna vez pudo ver.

Para agregar a la respuesta de @ str4d, aquí hay enlaces a la documentación pública y la discusión de la función de divulgación de pagos:

• Divulgación selectiva y claves de visualización protegidas - Zcash blog
• Divulgación de pago (característica experimental)
• Una introducción a la divulgación de pagos en Zcash - Gareth Davies

Tenga en cuenta que si a Bob le preocupara esta posibilidad, podría haberle dado a Alice una dirección única para pagarle, de modo que un pago revelado a esa dirección no pudiera vincularse con sus otras direcciones. Esto se sugiere en la sección 3.1 de la especificación del protocolo.

En Sapling, hay una nueva función llamada "direcciones de pago diversificadas" que hace que este uso sea más eficiente: Bob puede proporcionar una dirección diversificada única a cada posible pagador y aún puede escanear la cadena de bloques en busca de pagos entrantes tan eficientemente como si hubiera solo una dirección. Estamos planeando que esto se integre en el equivalente de Zcash de BIP 32 (Direcciones deterministas jerárquicas), de modo que todos los secretos asociados con una billetera se puedan respaldar usando una sola semilla.