¿Por qué aumenta la privacidad para usar los servicios de torre de vigilancia con identificaciones de tx de compromiso impredecibles?

En el open channelmensaje en BOLT 02 se escribe la siguiente declaración sobre los diversos puntos base.

Los diversos campos _basepoint se utilizan para derivar claves únicas como se describe en BOLT #3 para cada transacción de compromiso. La variación de estas claves garantiza que el ID de transacción de cada transacción de compromiso sea impredecible para un observador externo, incluso si se ve una transacción de compromiso; esta propiedad es muy útil para preservar la privacidad cuando se externalizan transacciones de sanción a terceros.

Me pregunto sobre la última oración. ¿Por qué esto en particular ayuda con la privacidad de dichos servicios? Pensé que aumentaba la privacidad al usar varios servicios de observación de terceros y no solo uno. En caso de que use uno, sabrán todo el historial de estado de mi canal de todos modos.

Una cosa que supuse fue que una vez que conozco un tx de compromiso, puedo calcular todos los txid para todos los estados de canal posibles. Pero pensé que las firmas dependen de la cantidad de salidas y el txid depende de las firmas.

¿Tengo un concepto erróneo o el motivo del aumento de la privacidad es otro que no veo?

Respuestas (1)

En realidad, el BOLT ha sido diseñado con propiedades de privacidad muy fuertes con respecto a las torres de vigilancia. Puede dar todas sus primeras mitades de identificación de tx de compromiso a una torre de vigilancia y todavía no aprende nada sobre las segundas mitades, otros txs o cualquier otra cosa sobre el estado del canal (o qué canal está viendo), siempre y cuando ya que el tx de compromiso completo no aparece en la cadena de bloques. Una vez que lo hace, todavía no puede aprender nada más allá de este estado de compromiso. Para eso se hace esto y es bastante notable en mi humilde opinión.

lo siento no lo entiendo Veo que puedo dar una parte del id de tx de compromiso a un servicio de torre de vigilancia y que podrían identificar el tx si aparece en la cadena de bloques. Sin embargo, una vez que lo haga, se supone que Watchtower reclamará los fondos en mi nombre liberando mi tx de reparación de incumplimiento. Si no tiene ese (que revelaría el estado del canal), el servicio de visualización me parece bastante inútil. Supongo que me estoy perdiendo algo. Sería genial si pudieras elaborar
El tx de remedio que le da a la torre de vigilancia está encriptado con la segunda mitad de la identificación del tx de compromiso, por lo que la torre de vigilancia no puede leerlo a menos que encuentre primero el tx de compromiso en la cadena de bloques.
ok, esa era la pieza que faltaba en el rompecabezas y, de hecho, es un enfoque muy interesante. Lo que todavía no entiendo es por qué su enfoque no funcionaría si todos los txs de compromiso hubieran usado el mismo punto base para la clave privada. Quiero decir que las identificaciones de tx aún serían diferentes debido a las diferentes cantidades o me estoy perdiendo algo.
Todos usan los mismos puntos base, pero diferentes puntos por_compromiso. El razonamiento se describe con más detalle aquí: github.com/lightningnetwork/lightning-rfc/blob/master/… La idea general es que las torres de vigilancia o cualquier otra persona no debe aprender más sobre el canal de lo absolutamente necesario, mientras que al mismo tiempo lo ideal es almacenarlo como la menor cantidad de datos posible. Parece que la segunda parte no funciona tan bien en la práctica hasta ahora. Eltoo mejoraría eso.
¡Asegúrese de incluir respuestas de seguimiento en su publicación de respuesta! :) Los comentarios están destinados a ser transitorios.
¿En realidad? ¿Cómo? ¿Intentar integrar todo el ida y vuelta en una respuesta artificial? ¿Eliminar los comentarios? Falsificar la historia? Suena duro y peligroso para mí.
¿Por qué aumenta la privacidad para usar los servicios de torre de vigilancia con identificaciones de tx de compromiso impredecibles?
RespuestasAquíPolítica de privacidad1y, 0v