Th testnet TxID 8d897ca91774a7fafa086a3275e679248d6bffee015d3b2efefd5dab00df152d tiene el siguiente scriptPubKey :
scriptPubKey: "OP_DUP OP_HASH160 5f1426c2ce4a8e1abaa9dbe819b6303eb8a25a26 OP_EQUALVERIFY OP_CHECKSIGVERIFY OP_IF OP_DUP OP_HASH160 6c7ceafe76c56843c9d2868f616fdc9370355eb9 OP_EQUALVERIFY OP_CHECKSIG OP_ELSE OP_HASH256 644d79d87e0907833e888e272e5d7b925deb261a8499a65cbc0bf26797a15e8e OP_EQUAL OP_ENDIF"
Mirando el script del Tx redentor ( TxID: 2d0daa01da8294a54178f8111eb2a02010c425fd15957d8baee8717edcfbe105 ) vemos:
7e 10 3ceb50edd0282cd99dc59351f513dcdf 00 der sig
Entonces puedo ver esencialmente que porque sha256(sha256(3ceb50edd0282cd99dc59351f513dcdf))= 644d79d87e0907833e888e272e5d7b925deb261a8499a65cbc0bf26797a15e8eel script se valida como Verdadero.
Estoy tratando de entender cómo funciona esto, pero recibo constantemente un código de error 26 (falla OP_EQUALVERIFY) para este intento de sendrawtransaction:
01000000013261e80001cbcc53101036792dcc8edc6802940b81a06e6e38f34765a4a5e4e5000000008b483045022100fe3890cfe091789b8300e563bbad402421a8dc07096ba04bcaaa4dd3537e7ce302204a1d7d1d33b6101599385f74164d95fdd8c00f62062a339e6d4907334b17df5f0141042daa93315eebbe2cb9b5c3505df4c6fb6caca8b756786098567550d4820c09db988fe9997d049d687292f815ccd6e7fb5c1b1a91137999818d17c73d0f80aef9ffffffff0220402c00000000001976a914dd6cce9f255a8cc17bda8ba0373df8e861cb866e88ac20402c00000000005876a914e900510876cb689f1db6fa982376c301362b740c88ad6376a914dd6cce9f255a8cc17bda8ba0373df8e861cb866e88ac67aa20644d79d87e0907833e888e272e5d7b925deb261a8499a65cbc0bf26797a15e8e876800000000
¿Dónde exactamente está ocurriendo este problema?
Además, en general , si uno necesita insertar datos en la pila antes de la firma , ¿cómo se hace? ¿Se agregan los datos al campo scriptSig y luego se firman, o se firman y luego se agregan a scriptSig? (Tengo problemas para visualizar la pila incluso con este escenario interactivo en webbtc )
La primera transacción de canje tiene un scriptSig en la forma:
<value to be double hashed> 0 <signature> <public key>
Eso 7ees una pista falsa: es del tamaño de scriptSig. Del mismo modo, 10es el tamaño de los datos que se van a codificar.
La segunda transacción parece estar intentando gastar una producción estándar . Parece estar tratando de gastar esto usando una clave que no genera el valor correcto.
Puede ver esto pegando el siguiente script en el IDE de Bitcoin Script :
042daa93315eebbe2cb9b5c3505df4c6fb6caca8b756786098567550d4820c09db988fe9997d049d687292f815ccd6e7fb5c1b1a91137999818d17c73d0f80aef9 OP_DUP OP_HASH160 e900510876cb689f1db6fa982376c301362b740c OP_EQUALVERIFY OP_CHECKSIG
mago de ozzie
mago de ozzie
Nick ODell