16: obligatorio-script-verify-flag-failed (firma DER no canónica) (código -26)

Intento enviar la transacción a través sendrawtransactionde la consola de bitcoind.

Siges:

30440220494800937E4ECB15319266127A0334E94D25DFD2F594E8F846A3E7B5F36C362B0220750237958D23D390E6137B251399C5A5CE335DEC850D99A0905EFECC54E320593

bitcoindla respuesta es:

16: obligatorio-script-verify-flag-failed (firma DER no canónica) (código -26)

¿Quién sabe por qué?

TX sin procesar:

0100000001 A 000000008A4730440220494800937E4ECB15319266127A0334E94D25DFD2F594E8F846A3E7B5F36C362B0220750237958D23D390E6137B251399C5A5CE335DEC850D99A090EF3CC43259E5E3014104 B FFFFFFFF01 C 1976A914 D 88AC0000000001000000

A= 32 bytes de TXhash de transacción "desde"

B= 64 bytes de mi clave pública

C= valor de 8 bytes de BTC que intento enviar

D= 20 bytes de dirección "a"

¿Le importaría publicar el hexadecimal completo de su transacción, para que pueda probarlo yo mismo?
Recibo un error -22 cuando intento eso, tanto con como sin ABCD.

Respuestas (2)

Este error significa que su firma falló en algunos controles de cordura diseñados para evitar bifurcaciones de red accidentales debido a codificaciones de firma no estándar pero aún válidas. Esta función en el intérprete de secuencias de comandos realiza la verificación real.

Sin embargo, eché un vistazo a su firma y no puedo encontrar nada malo en ella (mirándola manualmente, sin ejecutar el código). ¿Es posible que el byte anterior sea incorrecto, por lo que la firma no se inserta completamente en la pila?

EDITAR :

De hecho, ejecuté el algoritmo de comprobación de firmas en tu firma. El código que usé está aquí . La firma pasa el control DERDe hecho, no hay nada malo con la firma en sí. ¿Cómo lo generó y cómo se ve el resto de la transacción?

Eso se ve bien. ¿Intentó enviar la transacción devuelta en el hexatributo de la respuesta o intentó copiar y pegar el resultatributo en el script de firma de la transacción? El primer método funciona, mientras que el segundo producirá resultados no válidos. Además, ¿el completeatributo se estableció en verdadero en la respuesta? De lo contrario, la transacción necesita más firmas para ser válida (aunque si no hay suficientes firmas en un multisig, se producirá un error diferente a la falla de verificación de cordura de DER).
Te estoy preguntando cuál es el resto de la transacción. La respuesta corta es que la firma en sí tiene el formato correcto y pasa todas las comprobaciones. La respuesta larga es que si la transacción tiene un formato incorrecto, es posible que se haya pasado a OP_CHECKSIG algo que no sea la firma anterior y, por supuesto, algo que no sea una firma no se analizará, incluso si hay una firma válida en otro lugar dentro del transacción.
muchas gracias por tu respuesta! Pero todavía no entendía dónde se esconde el error.
También obtengo: 2019-06-14T01:16:35Z ERROR: ConnectBlock(): CheckInputs on c2de0a7014853898bde9319cb347225d4ee6cef9025dc56773b0b57010060d48 failed with non-mandatory-script-verify-flag (Script evaluated without error but finished with a false/empty top stack element) (code 64)* antes de eso, el nodo estaba progresando * después, fallas constantes 2019-06-14T01: 16: 54Z ERROR: AcceptBlockHeader: el bloque 0000000000000000000104e5800f4ea259c5ab92a18e15320d8879d6c9e09e5b está marcado como no válido

Confirmo tres veces que la firma es buena, pero su transacción no está bien codificada. Mi script da esta deserialización.

{:ins=>[{:outpoint=>{:hash=>"94f5d2df254de934037a1266923115cb4e7e9300484920024430478a00000000", :index=>"a346f8e8"}, :scriptSig=>"B5F36C362B0220750237958D23D390E6137B251399C5A5CE335DEC850D99A090EF3CC43259E5E3014104FFFFFFFF011976A91488AC0000000001000000", :sequence=>""}], :outs=> [], :version=>"00000001", :locktime=>""}

Lo cual no tiene sentido. Incluso la identificación de la transacción anterior es incorrecta. Debe ser endian pequeño. Y la versión de la transacción debe ser 1, o cuando la codifica en little endian 8 bytes 010000000.