¿Por qué no agregar sal al script de tap en Taproot?

Se debe proporcionar la prueba de Merkle correspondiente al desbloquear UTXO usando MAST, donde se incluirá el hash de un script no utilizado. Para la observación, parece posible adivinar el script no utilizado a partir del hash. Por ejemplo, podría obtener algunas claves públicas del script que se está ejecutando y luego combinar una de ellas con algunos bloqueos de tiempo para intentar hacer colisiones de hash.

Agregar sal al script parecería prevenir esto fácilmente, entonces, ¿por qué Taproot no ha hecho esto? ¿Esto se debe a que la colisión hash descrita anteriormente es básicamente inviable y agregar sal ocupa espacio adicional para los testigos?

Respuestas (2)

En general, esto no debería ser una preocupación, ya que es casi seguro que cada script contiene al menos una clave pública, y puede usar claves públicas nuevas en cada rama.

Si aún le preocupa la privacidad del script revelado, puede modificar las claves públicas manualmente con algún secreto compartido entre todos los participantes (por ejemplo, el hash de concatenación de todos los scripts antes de modificar). O incluso puede agregar datos adicionales a uno usando un código de operación push y OP_DROP.

Las sales se usan para cosas como el almacenamiento de contraseñas donde varios usuarios pueden estar usando la misma contraseña. Al usar una sal, se ofusca a un observador de la base de datos qué usuarios están usando la misma contraseña debido a diferentes sales. La única motivación para usar salt en los scripts de Taproot sería si los usuarios estuvieran usando los mismos scripts de Taproot. Pero, como mínimo, las claves públicas de los usuarios serán diferentes (a menos que estén usando la misma clave privada) y, por lo tanto, ningún script Taproot será igual a menos que estén controlados por el mismo usuario.

Para decir lo obvio, los usuarios no deberían usar la misma contraseña (pésima higiene de la contraseña) para los servicios que no son de Bitcoin, pero es aún más serio para Bitcoin. Si los usuarios no generan una clave privada de Bitcoin con suficiente entropía, es probable que sus Bitcoin sean robados.

Para la observación, es posible adivinar el script no utilizado a partir del hash.

Adivinar la preimagen de una función hash segura es inviable. Solo se puede hacer a través de la fuerza bruta (probando muchas preimágenes posibles), pero hay tantas preimágenes posibles que es como buscar una aguja en un pajar.

Sí, sería muy difícil encontrar colisiones de hash, pero ¿sería más fácil si hubiera algunas calificaciones? Por ejemplo, las tres condiciones de desbloqueo en un MAST son 1. sig de A && sig B && timelock 10 Blocks 2. sig de A && timelock 100 Blocks 3. sig de B && timelock 200 Blocks Luego eventualmente se desbloquearon con la condición 1. El el observador luego intenta que la clave pública de A + el bloqueo de tiempo colisionen. Sé que este es un ejemplo raro, pero aún funciona, ¿verdad? ¿Y si agrega sal al guión, parece detenerlo?
Solo comprobando que entiendo tu pregunta. En su escenario, se revela un script y un observador de blockchain usa los detalles de ese script para tratar de resolver a través de la fuerza bruta (informada) los otros scripts en el árbol Taproot (MAST) que no se revelaron y se usaron para gastar? ¿O usa los detalles de esa secuencia de comandos para tratar de resolver las otras secuencias de comandos en otros árboles Taproot? Porque, obviamente, el observador/atacante no conoce la(s) clave(s) privada(s) y, por lo tanto, no puede robar los fondos incluso si tiene éxito en la fuerza bruta de un script en particular a partir de un hash.
No, no quiero discutir aquí si un atacante podría gastar este UTXO, sino solo si esto conduciría a una fuga de scripts no utilizados, ya que esto parece anular el propósito original de Taproot. Y al agregar sal a la secuencia de comandos, para un observador, incluso si conoce alguna información, no puede conocer la secuencia de comandos correspondiente al hash (debido a la presencia de la sal).
Creo que la respuesta a su pregunta es que los hashes etiquetados se usan en todo Taproot y esto desempeña un papel similar al de una sal. github.com/bitcoinops/taroot-workshop/blob/…
Tagged Hash parece evitar que un nodo de rama pueda interpretarse como un nodo de hoja. Y todas las etiquetas para los nodos hoja cuando leí BIP 341 eran Tapleaf . Así que supongo que todavía es diferente de lo que significa la sal.
Si cada nodo de hoja tiene una etiqueta diferente, entonces esa sería mi respuesta, pero no veo que sean diferentes en este momento (corríjame si me equivoco). Y, muchas gracias por tu respuesta!
@MichaelFolkson Como el hash etiquetado es predecible, no puede funcionar como una sal. Evita que los datos que se codifican coincidan accidentalmente con un hash utilizado en un contexto diferente, pero no puede proporcionar privacidad ya que la etiqueta no es secreta.
¿Por qué no agregar sal al script de tap en Taproot?
RespuestasAquíPolítica de privacidad1y, 0v