Reajustar la dirección taproot de otra persona o la mía propia

Supongamos que obtengo una clave pública taproot address=schnorr de un intercambio que no está modificado con mast merkle root y deseo modificar esa clave pública.

Esto producirá una clave pública potencialmente diferente.

  1. ¿Puedo hacer esto?
  2. Si hago esto, ¿el intercambio seguirá reconociendo mi depósito?
  3. En general, ¿puedo modificar a voluntad las claves públicas ya modificadas?

Gracias.

para explicar mi motivación con mayor profundidad, sería genial si los usuarios pudieran incorporar datos adicionales en la cadena en los ajustes, de forma similar a como lo hacen ahora con OP_RETURN solo en privado
Suena como un problema XY . Debería considerar hacer otra pregunta, pero directamente sobre el problema que desea resolver en lugar de un enfoque que está considerando. :)
no realmente. todavía sería genial porque 1 MB de claves públicas + 1 MB de datos en ajustes> 1 MB de claves públicas no modificadas
Parece que puede estar buscando firma de contrato: blog.eternitywall.com/2018/04/13/sign-to-contract . Ese es un esquema que permite que una firma se comprometa con datos arbitrarios, sin aumentar su tamaño. Esto tiene la ventaja de que las claves públicas no se modifican y, por lo tanto, es un problema puramente del lado del firmante.

Respuestas (2)

No, esto probablemente conduciría a una pérdida de fondos. Los ajustes de clave son creados por un destinatario que modifica una clave antes de compartir la clave pública modificada resultante en forma de dirección de destino.

Si modifica una clave externa, el destinatario original no tendría forma de reconocer de forma independiente que su clave está asociada con la nueva dirección, y muy probablemente no podría gastar los fondos incluso cuando se le informa sobre la modificación.

¿Estás seguro de que hay una pérdida de fondos? ¿Incluso si revelo el tweak + la clave de publicación original + la nueva clave de publicación en el intercambio?
Sí. ¿Qué sucede si, por ejemplo, el destinatario utiliza un Módulo de seguridad de hardware que solo puede firmar para las direcciones que generó? El destinatario especifica en qué circunstancias reconoce un pago. El remitente no tiene por qué hacer suposiciones sobre cómo pueden modificar eso. Si el propietario le dice que espera que le paguen con un cheque por correo, no entierra una bolsa de monedas de veinticinco centavos en su patio delantero ni le dice dónde cavar. , ¿Tú?
O peor aún, no les digas dónde cavar y luego actúes confundido y sorprendido cuando te pregunten por el dinero.

BIP341 recomienda ajustar incluso las claves públicas que no tienen una ruta de script prevista, con un ajuste ficticio. Esto previene ciertos ataques (aunque ninguno relevante en su escenario).

  1. Puede modificar una clave pública existente, sí, pero la dirección tendrá otro significado.

  2. Absolutamente no. Solo el software del receptor determina en qué dirección acepta monedas. Si paga a cualquier otra cosa, debe asumir que las monedas se envían al vacío. Es posible que, digamos, un intercambio aún pueda acceder a las monedas con sus claves si les informa sobre la modificación, pero no se puede confiar en esto. Las claves privadas pueden estar en un módulo de seguridad de hardware más o menos, que no tiene medios para firmar nada más que la dirección deseada.

  3. En cierto modo sí, pero eso lo convierte en otra dirección, con otra semántica.

En teoría , si alguien tiene la capacidad de firmar por un punto público P , puede firmar por una versión modificada de P , suponiendo que conoce la modificación. El ajuste no se puede inferir del punto ajustado; tiene que ser transportado por separado. Esto también funciona de forma recursiva, porque si puede firmar para obtener una versión modificada, también puede firmar para obtener una modificación de eso. Una vez más, sin embargo, esto es teoría y no se puede confiar en ella en la práctica. Solo el receptor determina qué dirección acepta.

Reajustar la dirección taproot de otra persona o la mía propia
RespuestasAquíPolítica de privacidad1y, 0v