¿Por qué fue posible el evento de maleabilidad de transacciones de octubre de 2015 a pesar de BIP62/66?

El reciente resurgimiento de la maleabilidad de las transacciones ha sido responsable de una gran cantidad de Tx que se gastan dos veces (octubre de 2015).

/r/Bitcoin ha publicado un código C++ del que @amaclin se ha hecho responsable.

Entiendo que, según este código fuente, la "explotación" de la maleabilidad de la transacción es simplemente ajustar las firmas DER para ciertos Tx (es decir, Tx no P2SH) y retransmitir el Tx ( descargo de responsabilidad: no sé C ++, por lo que estas son conjeturas informadas ) .

BIP62 se ocupa de numerosos problemas, entre ellos está el requisito de firmas DER canónicas: tenía la impresión de que las firmas DER canónicas se implementaron en BIP66.

  1. ¿Alguien puede aclarar qué está haciendo el código de @amaclin?
  2. ¿Por qué es posible este exploit si BIP66 se implementó hace varias semanas?
@amaclin ¿Quieres comentar? :)
Lo siento. Me perdí esta publicación. Mi correo electrónico está en el perfil. no dude en ponerse en contacto conmigo

Respuestas (1)

La firma DER canónica implementada en BIP 66 soluciona el problema n.º 1 de BIP 62 (firmas ECDSA codificadas sin DER)

El código de Amacilin explota el problema n.º 5 en BIP 62 (maleabilidad de la firma ECSDA inherente), y se explica aquí: https://github.com/bitcoin/bitcoin/commit/a81cd96805ce6b65cca3a40ebbd3b2eb428abb7b

Este problema se solucionó al requerir que las firmas tengan una codificación S baja en la solicitud de extracción 6769: https://github.com/bitcoin/bitcoin/pull/6769 . Tenga en cuenta que esta solución solo evita que se transmitan las transacciones mutadas (las transacciones sin codificación low-S aún se pueden minar en bloques).

De BIP62: Inherent ECDSA signature malleability ECDSA signatures themselves are already malleable: taking the negative of the number S inside (modulo the curve order) does not invalidate it.. Vaya, eso es un gran problema .
era un problema, pero se solucionó al requerir low-s, ¿verdad?
La respuesta corta es que BIP66 ni siquiera estaba destinado a abordar la maleabilidad. Se pretendía que la red dejara de depender indirectamente de la implementación arbitraria del analizador ASN.1 de OpenSSL. Simplemente coincidió técnicamente con una parte de BIP62.