pikaro
9e7fec873a
El denominador de la nota incluía dos pesos que nunca restan (rbf, peeling) y excluía uno que sí (input_linkage, hasta 30), así que las deducciones podían superarlo en 17 puntos y dar negativo. Corregido en ambas direcciones, con los cortes de banda recalibrados a 79/54 para que ninguna transacción cambie de banda por el arreglo. 'Redondo' equivalía a 'múltiplo de 0,001 BTC' por dos condiciones redundantes, y se le escapaban pagos de 10.000 o 50.000 sats. Ahora se mide por ceros finales y la señal se gradúa. Dos checks nuevos. El de polvo avisaba de una vinculación futura y nunca miraba si estaba ocurriendo delante: ahora la detecta cuando el polvo se gasta junto a monedas normales. Y la consolidación pura (N entradas, 1 salida) no disparaba el check de inputs innecesarios; ahora se nombra, sin cobrarla dos veces porque input_linkage ya la penaliza. tests/test6.js cubre lo nuevo y la coherencia de la nota.
3.7 KiB
Pruebas
Dos familias. Las de criptografía (test1–test4) verifican la derivación watch-only —BIP32, secp256k1, RIPEMD-160, bech32— contra los vectores oficiales de los estándares, no contra resultados propios. Las de heurísticas (test5–test6) comprueban el analizador de privacidad contra transacciones donde la respuesta se conoce de antemano.
Si un cambio rompe algo, estas pruebas lo dicen.
Cómo ejecutarlas
Las de heurísticas se ejecutan directamente — se extraen solas del
dashboard.html, así que no se desactualizan:
node tests/test5.js
node tests/test6.js
Las de criptografía necesitan una preparación manual (pendiente de automatizar igual que las otras dos):
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. - test5 — detección del output de cambio. Transacciones donde se sabe de antemano cuál es el pago y cuál el cambio, más los niveles de "redondez" de una cifra. Nació de dos fallos de la v1.15.0: una señal que se contaba dos veces y un índice que podía señalar el pago como si fuera el cambio.
- test6 — el analizador completo. Coherencia de la nota (que ninguna transacción pueda puntuar negativo antes del clamp), los dos checks nuevos —polvo gastado junto a otras monedas y consolidación pura— y que la guardia de CoinJoin desactive las heurísticas que no aplican dentro de una mezcla.
Las cuatro primeras prueban criptografía; las dos últimas, heurísticas. Se
ejecutan igual: node tests/testN.js.
Lo que estas pruebas NO cubren
Las heurísticas (test5, test6) se comprueban contra transacciones construidas a mano, no contra la cadena real. Eso demuestra que la lógica hace lo que dice —y ha bastado para encontrar fallos reales— pero no dice nada sobre cuántas veces acierta ahí fuera. Medir eso exigiría un conjunto de transacciones reales con la respuesta conocida de antemano, que es un trabajo distinto y pendiente.
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.