Aitor
428f67c132
Uno: la señal A y la señal E eran la misma condición escrita dos veces, así que un solo hecho llegaba al umbral de dos señales. Un pago corriente de bech32 a taproot salía como cambio identificable con certeza PROBABLE, y el informe mostraba las dos señales contradiciéndose entre sí. Dos: sin señal fuerte, el índice caía en la salida menor. Pagando poco desde una moneda grande el cambio es la mayor, así que la app señalaba el pago. El detalle llegaba a decir 'el output redondo es el pago' y a continuación lo marcaba como cambio. El peritaje usa ese índice, de modo que podía presentar la dirección del destinatario como rastro del actor. Ahora cada señal apunta a un output o admite que no puede, y si ninguna apunta el índice queda vacío. tests/test5.js deja los dos casos como regresión.
Pruebas de la criptografía
Verifican la derivación watch-only (BIP32, secp256k1, RIPEMD-160, bech32) contra los vectores oficiales de los estándares, no contra resultados propios. Si un cambio rompe algo, estas pruebas lo dicen.
Cómo ejecutarlas
Extraer el bloque criptográfico de dashboard.html a crypto.js (las líneas
que van desde const B32 = { hasta el final de deriveAddresses), añadir al
principio const { webcrypto } = require("crypto"); const crypto = webcrypto;
y al final la exportación:
module.exports = { B32, SECP, deriveChildPubkey, ripemd160, hash160, toBech32, deriveAddresses };
Después:
node test1.js # RIPEMD-160 y aritmética de curva
node test2.js # BIP32 y bech32 contra vectores oficiales
node test3.js # búsqueda de casos borde (diagnóstico)
node test4.js # regresión de los fallos ya corregidos
Qué cubren
- test1 — RIPEMD-160 con los seis vectores del estándar (incluido el de un millón de caracteres), generador de secp256k1, múltiplos conocidos, y que comprimir y descomprimir un punto sea reversible.
- test2 — BIP32: clave pública y chain code de la raíz, y derivación no
endurecida
m/0, contra los vectores 1 y 2 del propio BIP32. bech32: la dirección P2WPKH del generador, en mainnet y testnet (BIP173). - test3 — sondeo de casos borde. Fue el que encontró los cuatro fallos de validación corregidos el 2026-07-27.
- test4 — comprueba que esos cuatro siguen cerrados: checksum rota, xpub
truncado, índice endurecido, índice negativo. Y que un
tpubgenera direcciones de testnet, no de mainnet.
Lo que estas pruebas NO cubren
La matemática es correcta, pero eso no es una auditoría. No cubren análisis formal ni una revisión independiente: quien las escribió conoce la implementación y comparte sus supuestos, que es justo el sesgo que rompe un revisor externo. Siguen haciendo falta ojos de fuera antes de difundir el proyecto ampliamente.
Tampoco aplican aquí los ataques de canal lateral: todo esto maneja solo claves públicas. No hay secreto que filtrar; lo único que importa es que el resultado sea correcto, y eso es lo que se comprueba.