txoko-dashboard/CHANGELOG.md

# Changelog

Todos los cambios notables de Txoko Node Dashboard se documentan aquí.

El formato sigue [Keep a Changelog](https://keepachangelog.com/es-ES/1.0.0/)
y el versionado sigue [Versionado Semántico](https://semver.org/lang/es/):
`MAYOR.MENOR.PARCHE`.

- **MAYOR** — cambios grandes que cambian cómo se usa la herramienta
- **MENOR** — características nuevas que no rompen lo anterior
- **PARCHE** — arreglos de errores

---
## [1.18.2] — 2026-08-08
### Corregido
- **`instalar-fuentes.sh` daba por fallidas descargas que habían ido bien, en
  macOS.** Comprobaba el tamaño con `stat -c%s`, que es sintaxis GNU. macOS
  trae la versión BSD de `stat`, que usa `-f%z`, así que el comando fallaba,
  caía en el `|| echo 0` y el script informaba **«FALLÓ (HTTP 200, 0 bytes)»**.
  El `HTTP 200` decía que la descarga había funcionado; lo roto era la
  comprobación.
  - El mensaje además engañaba: se lee como un problema de red o del servidor
    de fuentes, y era una incompatibilidad de shell entre dos sistemas.
  - Ahora usa `wc -c`, que se comporta igual en Linux y en macOS, y comprueba
    antes que el archivo exista.
  - La cabecera del script decía «Ejecutar EN EL NODO». Ya no: si el dashboard
    puede vivir en una carpeta cualquiera, su instalador de fuentes tiene que
    funcionar ahí también.

---
## [1.18.1] — 2026-08-08
### Corregido
- **El aviso del xpub decía una media verdad.** El panel de wallet watch-only
  decía «Txoko deriva tus direcciones en local — el xpub no sale del
  navegador». Es cierto, y por eso mismo engaña: el xpub no sale, pero **las
  direcciones derivadas sí**, una consulta a la API del nodo por cada una. Quien
  opere ese nodo puede ver en sus registros el monedero completo que estás
  analizando: cuántas direcciones tienes, cuáles, su historial y tu saldo.
  - Con el nodo propio no hay problema, es tu información en tu máquina. Con el
    nodo de otra persona —aunque sea de confianza— le estás enseñando tus
    finanzas enteras.
  - El aviso lo dice ahora, y distingue los dos casos. En una herramienta que
    existe para no afirmar de más, ese era el peor sitio posible para tener una
    frase técnicamente cierta que se lee como una garantía que no es.

### Añadido
- `PRUEBALA.md` — guía para quien recibe la aplicación para probarla: el aviso
  del xpub por delante de todo, qué merece la pena intentar romper, qué no
  hacer con el peritaje, y qué tipo de fallo interesa que reporte.

---
## [1.18.0] — 2026-08-08
### Añadido
- **La comisión como huella.** El sat/vB que eliges dice algo del software y de
  quien lo maneja, y el dato estaba en cada transacción sin que nadie lo
  mirase. Se detectan dos firmas: una comisión **absoluta** redonda (10.000
  sats clavados — un estimador nunca da eso, calcula tarifa por tamaño y
  devuelve números feos) y una **tarifa** prácticamente entera (20,00 sat/vB,
  que sale de teclear un número redondo en la casilla).
  - Informativo y sin penalización, por el mismo motivo que se decidió con RBF:
    la señal es débil, y bajar la nota por ella empujaría a elegir comisiones
    peores solo para disimular. Mal negocio.
- **El cambio ya se identifica en transacciones de más de dos salidas, cuando
  el caso es inequívoco.** Antes la detección se plantaba en seco por encima de
  dos salidas. Estaba bien argumentado, pero se tiraba información sólida: si
  de N salidas **exactamente una** comparte tipo de script con las entradas, no
  hay nada que adivinar — y con más salidas la coincidencia por azar es aún más
  improbable que con dos. También cuenta el caso de una salida que vuelve a una
  dirección ya gastada. Se marca POSIBLE y no PROBABLE: es una sola señal, y
  hay monederos que devuelven el cambio a un tipo distinto del que gastan.
- **Aviso de autoenvíos que ataron direcciones**, en el informe de wallet. Es
  una comprobación que solo cabe ahí: para saber que *todas* las salidas son
  tuyas hace falta conocer tu wallet entero, cosa que el analizador de una
  transacción suelta no puede saber.
  - Detecta las transacciones donde entradas y salidas son todas tuyas, y avisa
    solo cuando hubo daño real: más de una dirección de entrada. Mover una
    dirección a otra no vincula nada nuevo y no merece alarma.
  - Es un gesto que suele hacerse creyendo que despista y hace lo contrario: no
    hubo ningún pago, pero al firmar varias direcciones a la vez quedaron
    enlazadas en público. Se paga una comisión por empeorar la propia
    privacidad.

Con esto quedan cerradas las cinco heurísticas que el repaso del 2026-08-08
señaló como ausentes.

---
## [1.17.0] — 2026-08-08
### Cambiado
- **La nota de privacidad ya solo mide lo que dependía de ti.** Hasta ahora
  mezclaba dos cosas distintas en un número: los errores propios (reutilizar
  direcciones, consolidar, dejar el cambio a la vista) y la exposición que
  provoca un tercero (que te paguen desde un lote, recibir polvo, que la otra
  parte use un tipo de dirección distinto). La consecuencia era absurda:
  **alguien impecable que cobró de un exchange sacaba peor nota que un
  descuidado que cobró de un particular**, y no había nada que pudiera hacer
  para mejorarla. Recibir de un lote costaba 23 puntos y estaba marcado, con
  razón, como "no corregible".
  - La nota se calcula ahora solo con los checks sobre los que tienes decisión.
    Denominador 142.
  - Lo demás pasa a un bloque propio, **«lo que hicieron otros»**, con su
    propio nivel de exposición (ninguna / moderada / alta). Se informa, se
    explica, y no baja una nota que no podrías subir.
  - Una nota que no puedes mejorar no es una evaluación, es un reproche. Y una
    herramienta que reprocha lo que no elegiste enseña a ignorarla.
- **Un fallo grave impide la banda ALTA aunque el número dé de sobra.** Con la
  nota restringida a lo propio, una transacción con el cambio identificable
  —una fuga real y concreta— sacaba 93 sobre 100 y la etiqueta "privacidad
  aceptable". Ahora cualquier check propio que falle con peso ≥10 impide la
  banda alta. Un promedio bueno no borra un fallo concreto.
- **OP_RETURN deja de forzar banda BAJA por decreto.** Sigue penalizando, pero
  el tope duro condenaba por igual a una inscripción y a un sello de tiempo de
  OpenTimestamps, que es privacidad neutra. Como además OP_RETURN suele venir
  del protocolo que usaste y no de tu descuido, vive ahora en la exposición
  heredada.
- Los cortes de banda pasan a 85 y 55: con la nota midiendo solo lo propio, el
  listón puede ser más exigente porque ya no hay dentro nada que no puedas
  arreglar.
- La exportación en Markdown y en JSON incluyen ambos bloques por separado.

---
## [1.16.0] — 2026-08-08
### Corregido
- **El denominador de la nota de privacidad no cuadraba con los pesos.** La
  nota se calcula como `100 - (deducciones / maxPossible) * 100`, donde
  `maxPossible` es la suma del objeto `weights`. Ese objeto tenía dos
  desajustes, en direcciones opuestas y ninguno intencionado:
  - Incluía `rbf` (5) y `peeling` (8), que son informativos y **nunca restan**.
    Trece puntos de denominador imposibles de alcanzar, que inflaban
    sistemáticamente todas las notas.
  - **No** incluía `input_linkage`, que resta hasta 30 desde una variable
    suelta. Las deducciones podían superar al denominador en 17 puntos y dar
    una nota negativa, tapada solo por el `Math.max(0, …)`.
  - Ahora todo lo que puede restar está en `weights` y nada más lo está. Los
    cortes de banda pasan de 75/45 a 79/54, que son los valores que hacen que
    una transacción reciba **exactamente la misma banda que antes** con el
    denominador corregido. Queda anotado en el código que normalizar por la
    suma de los pesos obliga a recalibrar cada vez que se añade un check —
    porque cada check nuevo hace parecer menos graves a los anteriores.
  - El texto explicativo bajo la nota derivaba la banda por su cuenta con los
    cortes antiguos escritos a mano. Ahora usa la banda ya calculada.
- **"Cifra redonda" estaba mal definido.** La condición era
  `v % 1000000 === 0 || v % 100000 === 0 || v % 10000000 === 0`, donde la
  primera y la tercera sobran: todo múltiplo de un millón lo es de cien mil.
  Equivalía a "múltiplo de 0,001 BTC", así que pagos tan redondos como 10.000
  o 50.000 sats —de lo más común con las comisiones de hoy— no se veían. La
  heurística estaba infrautilizada, no equivocada.
  - Ahora se mide por ceros finales y la señal se gradúa: pagar 0,5 BTC
    clavados delata más que pagar 0,0123, y la penalización lo refleja.
  - El didáctico dice ahora el punto ciego: si pagas una cantidad redonda **en
    euros**, en BTC sale un número con todos sus decimales y esta heurística no
    ve nada.

### Añadido
- **Nuevo aviso: se gasta polvo junto a otras monedas.** El check de polvo
  advertía de que una salida diminuta "quedará vinculada con las demás si se
  gasta junto a ellas" — y la aplicación nunca miraba si eso estaba ocurriendo
  delante de ella, pese a tener el dato en la mano. Ahora lo mira: si entre las
  entradas hay una moneda de tamaño polvo gastada junto a otras de importe
  normal, el ataque ya no es una hipótesis, se acaba de consumar, y se dice con
  CERTEZA. No aplica en CoinJoin ni cuando solo se gasta polvo, que no revela
  vinculación nueva.
- **La consolidación pura ya no pasa desapercibida.** Una transacción de N
  entradas a **una sola salida** —el acto que más privacidad destruye de una
  vez— no disparaba el check de inputs innecesarios: su condición exige que una
  entrada cubra el pago *y sobre*, y en una consolidación la salida vale casi
  lo mismo que la suma de entradas. Comprobado con 20 entradas a 1 salida.
  Ahora se nombra como lo que es, con certeza. No suma penalización propia a
  propósito: la vinculación ya la cobra `input_linkage`, y cobrarla dos veces
  sería repetir el error que este mismo repaso acaba de corregir.
- `tests/test6.js` — el analizador completo contra transacciones construidas a
  mano: coherencia de la nota, los dos checks nuevos y la guardia de CoinJoin.
- `tests/test5.js` gana la comprobación de los niveles de redondez.
- `tests/README.md` explica ahora las dos familias de prueba y deja escrito que
  las heurísticas se comprueban contra transacciones fabricadas, no contra la
  cadena real: eso demuestra que la lógica hace lo que dice, pero no cuántas
  veces acierta ahí fuera.

---
## [1.15.0] — 2026-08-08
### Corregido
- **La detección del cambio contaba una misma señal dos veces.** La "señal A"
  (solo una salida comparte tipo de script con las entradas) y la "señal E"
  (el tipo de output difiere del de las entradas) eran la misma condición
  escrita dos veces —el mismo `filter`, la misma comparación, el mismo `=== 1`—
  y cada una incrementaba el contador. Como el umbral para declarar el cambio
  identificable es de dos señales, **ese único hecho bastaba por sí solo**.
  - Consecuencia práctica: pagar desde una dirección bech32 a una taproot —de
    lo más común que hay— salía marcado como "cambio identificable" con certeza
    PROBABLE, sin ninguna otra evidencia.
  - Y el informe mostraba las dos señales juntas, que se contradicen entre sí:
    "tipo de script idéntico a inputs" y "tipo de output distinto al de inputs".
    El mismo hecho descrito con palabras opuestas.
  - Ahora es una sola señal. Esa transacción pasa a una señal y a **no
    identificable**, que es lo correcto. Cuando queda una sola señal el check
    lo dice en vez de callarse: existe, no basta, y conviene que se sepa que
    otro analista menos escrupuloso la daría por buena ella sola.
- **Se podía señalar el pago como si fuera el cambio.** Cuando ninguna señal
  fuerte apuntaba a un output concreto, el índice caía en `indexOf(smaller)`:
  se asumía que el cambio es siempre la salida menor. Es falso en el caso más
  común de todos —pagar poco desde una moneda grande—, donde el cambio es la
  salida *mayor*.
  - Comprobado con un pago de 0,001 BTC desde 1 BTC: la app decía en el detalle
    "el output redondo es el pago" y acto seguido señalaba ese mismo output
    como cambio. La información para acertar estaba delante y se descartaba.
  - Esto no se quedaba en el analizador: el motor de peritaje usa ese índice
    para detectar cadenas de peeling y para redactar el informe. Un cambio mal
    identificado significa presentar como rastro del actor **la dirección del
    destinatario del pago**, una persona ajena.
  - Ahora cada señal apunta a un output o reconoce que no puede. El orden de
    resolución es: reutilización de dirección de entrada → tipo de script →
    la salida NO redonda → posición. Si ninguna apunta, el índice queda vacío
    y se dice que hay señales pero no cuál — preferible a señalar mal.

### Añadido
- `tests/test5.js` — seis casos de detección de cambio con el pago y el cambio
  conocidos de antemano, incluidos los dos fallos anteriores como regresión.

---
## [1.14.0] — 2026-08-08
### Añadido
- **Mempool y Bloques se fusionan en una sola pestaña, «Cadena».** Eran el
  mismo eje partido por la mitad: los "bloques proyectados" vivían en Mempool y
  los confirmados en Bloques, cuando es una línea temporal con el ahora en el
  corte. Ahora se lee de arriba abajo: comisiones, lo que está por minar, un
  separador **AHORA**, y los bloques ya minados.
  - Nuevo: **«si pagas X sat/vB, ¿cuándo entra?»**. Ni la vista de mempool ni la
    de bloques respondían la pregunta que de verdad se hace quien mira las
    comisiones — daban los datos por separado y dejaban el cálculo al ojo.
    Escribes una tarifa y te dice en qué bloque proyectado caería, marcándolo
    en la lista. Con dos avisos escritos en la propia interfaz: el cálculo se
    hace sobre la mempool de este momento, y diez minutos es la media entre
    bloques, no una promesa.
  - El detalle de un bloque se abría al final de la lista, a quince filas del
    bloque pulsado, así que parecía que el clic no hacía nada. Ahora la vista
    se desplaza hasta él.
- **Aviso de polvo recibido** en el informe de wallet. El analizador ya sabía
  reconocer el patrón al mirar una transacción suelta, pero eso no sirve si no
  te avisa cuando te pasa a ti. Recorre las salidas de importe ínfimo hacia
  direcciones propias y distingue las que siguen sin gastar —donde el consejo
  todavía sirve— de las ya gastadas, donde la vinculación ya está hecha.
  El consejo es el contrario del instinto: **no hagas nada**, déjalas quietas y
  congélalas en el monedero si puedes. El daño solo ocurre al mezclarlas.
- **Enlaces «ver en Mempool»** en nueve puntos: transacción analizada, detalle
  de bloque y sus transacciones, dirección del explorador, historial del informe
  de wallet, direcciones atribuidas y fondos localizados del peritaje, y en el
  rastro de procedencia la dirección de cada entrada y su transacción de origen.
  Se construyen **siempre** desde la URL configurada; sin nodo, no hay enlace.

### Corregido
- **El rastro de procedencia enlazaba a mempool.space público** cuando no había
  nodo configurado (`base ? … : "https://mempool.space/tx/…"`). Un clic ahí le
  dice a un tercero qué transacción estás investigando, que es exactamente lo
  contrario de para lo que existe esta herramienta. Sin nodo ya no hay enlace:
  se muestra el txid en texto plano. Auditado que no queda ningún enlace
  saliente en toda la aplicación.
- La fee mediana del detalle de bloque se mostraba con dieciséis decimales.

### Nota de diseño
- Se descartó hacer persistentes las etiquetas BIP-329. Vinculan direcciones con
  descripciones en lenguaje natural ("ahorro", "pago a…") y guardarlas dejaría
  en disco justo el mapa que un atacante querría. Que vivan solo en memoria no
  es una carencia, es la misma decisión que ya se aplica a la URL del nodo.

---
## [1.13.0] — 2026-08-08
### Cambiado
- **El checklist decía que un swap alto era "normal en nodos con índice
  completo".** No lo es, y decirlo hace que se ignore durante semanas un
  síntoma con causa y con arreglo. El caso que lo cambió: swap al 99% con 18 GB
  de RAM libre, porque Fulcrum tenía `db_mem` a 16 GB — más de lo que cabe en
  la máquina junto al resto de servicios. Con el swap lleno el sistema se queda
  sin margen y, ante un pico, el OOM killer elige él a quién mata.
  - El umbral baja del 95% al 50%, que es cuando conviene mirarlo y no cuando
    ya es tarde, y pasa a estado de error por encima del 80%.
  - Si el swap sube **teniendo RAM libre**, el aviso lo señala: es la firma de
    un servicio con más memoria reservada de la que cabe, no de presión real.
  - Apunta al sospechoso habitual (`db_mem` de Fulcrum, que se sube para
    acelerar la sincronización inicial y es fácil olvidarse de bajar) e incluye
    el comando para ver qué proceso ocupa el swap.
- Misma corrección en la explicación de SWAP de los DOCS.

### Añadido
- **Nueva comprobación: direcciones que quedan vinculadas entre sí.** Era el
  hueco de fondo del analizador: medía la privacidad desde el lado de quien
  *construye* la transacción (¿se ve mi cambio?, ¿pago cifras redondas?) y no
  desde el lado de los dueños de las monedas gastadas, que es donde el daño es
  irreversible. Gastar N direcciones distintas a la vez las enlaza para siempre
  por CIOH, y eso no se decía en ningún sitio. El peso sube con el número de
  direcciones y no aplica en CoinJoin, donde romper esa vinculación es el
  objetivo.

### Corregido
- **El explorador mostraba saldo cero en direcciones con mucho historial.** El
  backend de Mempool sobre Fulcrum devuelve los importes a cero cuando la
  dirección tiene muchas transacciones, aunque el contador venga bien — y la app
  los presentaba como ciertos. Una dirección con 492 transacciones aparecía con
  "Balance: 0,00000000 BTC". Ahora se detecta la inconsistencia (tener
  transacciones y no haber recibido nada es imposible en la cadena), los
  importes se muestran como "no disponible" y se explica por qué. El contador de
  transacciones y el historial, que sí son correctos, se mantienen.
- Mismo arreglo en el perfil de dirección del peritaje: antes concluía "no es
  hot wallet" cuando en realidad no había podido evaluar la señal de flujo.
- **El fingerprinting atribuía transacciones a Electrum por AUSENCIA de rasgos**
  (locktime 0, sin RBF, sequence por defecto). Es justo al revés: Electrum
  moderno pone locktime a la altura actual y señaliza RBF. Lo que esas señales
  describen no es un monedero concreto, sino software que no configura nada.
  Ahora Electrum exige señales positivas y aparece un resultado nuevo, **"sin
  rasgos distintivos"**, que además no penaliza: no dejar huella es lo contrario
  de tener una huella identificable.

---
## [1.12.1] — 2026-07-27
### Corregido
- **El monitor mostraba una CPU por proceso que engañaba.** La columna `%CPU`
  de `ps aux` no es el consumo actual sino la **media desde que el proceso
  arrancó** (tiempo de CPU dividido por tiempo de vida). Un proceso que trabajó
  mucho hace tres días seguía apareciendo alto para siempre, y se leía como si
  estuviera saturando la máquina. Se detectó porque los porcentajes por proceso
  no cambiaban NUNCA entre lecturas mientras la CPU global sí variaba.
  - Ahora se mide de verdad: dos lecturas de `/proc/PID/stat` separadas 500 ms,
    el mismo método que ya usaba `getCpuUsage` para el total. Las dos esperas
    corren en paralelo dentro del mismo `Promise.all`, así que no cuesta tiempo.
  - La interfaz muestra el **porcentaje sobre el total de la máquina**, que es
    lo que suele querer saberse, con el porcentaje de un núcleo y la media de
    `ps` en el tooltip para poder comparar con `top`.
  - Comprobado con carga artificial: el proceso ocupado marcaba 100% de un
    núcleo (25% de un sistema de 4) mientras `ps` daba 152%, imposible para un
    proceso de un solo hilo.

### Cambiado
- El UTXO Map pedía las transacciones de contexto con `fetchWithTimeout`
  directo, saltándose la caché añadida en la 1.11.0. Era el único punto que no
  la aprovechaba. Ahora pasa por `get()`, así que esas transacciones —ya
  confirmadas, e inmutables— se guardan toda la sesión.

### Documentación
- **Reescrita la guía de instalación.** `SETUP.md` no era una guía: más de la
  mitad eran los pasos personales de git y Gitea del autor ("PASO 1 — Crear el
  repo en Gitea"), que se han movido a un documento privado. Ahora es una guía
  real, con una comprobación tras cada paso para saber si vas bien sin
  descubrirlo al final con una pantalla en blanco.
- **Corregida la configuración de nginx documentada, que estaba rota.** El
  README indicaba `alias /var/www/txoko/dashboard.html` — un alias a un
  ARCHIVO. Desde la 1.11.0, con las librerías en `vendor/` y rutas relativas,
  eso hace que el navegador no las encuentre y la página quede en blanco sin
  ningún error visible. Debe apuntar al **directorio**. Es el fallo más común
  de esta instalación y ahora está avisado en tres sitios, con una comprobación
  concreta (`curl` mirando el `content-type`, no solo el código 200) para
  descartarlo.
- Los pasos de instalación no mencionaban las librerías del frontend, sin las
  cuales la aplicación no arranca. Ya están integradas en el orden correcto.
- Eliminados del repositorio los datos personales del autor: rutas de su
  máquina en la documentación y, sobre todo, su nombre de usuario del sistema
  y su ruta de instalación dentro de `txoko-metrics.service`, que llevaban ahí
  desde el primer commit. El servicio usa ahora marcadores que hay que ajustar
  antes de instalarlo.
- README: estructura del repositorio actualizada (faltaban `tests/`,
  `instalar-fuentes.sh` y `FIXTURES.md`) y sección de instalación reducida a un
  resumen que remite a SETUP.md, para que haya una sola fuente de verdad.
- SETUP.md incluye ahora tabla de problemas frecuentes y cómo actualizar.

---
## [1.12.0] — 2026-07-27
### Añadido
- **Auditoría de PSBT: revisar una transacción ANTES de firmarla.** Hasta ahora
  toda la app era diagnóstico *a posteriori* — te contaba con detalle lo que ya
  había pasado y no podías cambiar. Esta es la primera pieza que llega a tiempo.
  Sustituye al antiguo "validador", que solo comprobaba que el archivo empezara
  por `psbt` y decía su tamaño.
  - **Parser completo de BIP174 escrito desde cero**, sin librerías, como el
    resto del proyecto. Validado contra los cinco vectores inválidos que publica
    el propio estándar: los rechaza los cinco, cada uno con un mensaje que
    explica en castellano qué está mal (truncada, sin salidas, ya firmada,
    sin transacción interna, con claves repetidas).
  - **Todo el análisis es offline.** Una PSBT bien formada ya lleva dentro los
    importes y scripts de sus entradas, así que no hace falta consultar el nodo:
    funciona con el nodo sincronizando, y el nodo ni se entera.
  - Acepta base64, hexadecimal o abrir el archivo `.psbt` directamente.
  - **Aviso crítico sobre xpubs incrustados.** Las PSBT suelen llevar dentro las
    claves públicas maestras de la cartera, y están hechas para compartirse — se
    mandan por correo o chat para que el resto firme. Quien reciba el archivo
    puede derivar todas las direcciones, presentes y futuras, y ver el saldo y
    el historial completos. No puede gastar, pero lo ve todo. Ningún wallet
    avisa de esto.
  - Detecta además: cambio identificable por tipo de dirección, importes
    redondos que delatan cuál es el pago, envíos a la propia cartera, carteras
    multifirma (con su M-de-N) y PSBTs incompletas sin los importes de entrada.
  - Cada aviso mantiene el formato del resto de la app — Hecho, Consecuencia y
    **Qué puedes hacer** —, que aquí cobra sentido literal: todavía estás a
    tiempo de cambiar la transacción.

### Corregido
- **Revisión de la criptografía watch-only.** Se verificó la derivación completa
  contra los vectores oficiales de los estándares: RIPEMD-160 (los seis del
  estándar, incluido el de un millón de caracteres), secp256k1, BIP32 (vectores
  1 y 2) y bech32/BIP173. **La matemática es correcta y no se tocó.** Los fallos
  estaban en la validación de la entrada:
  - **No se comprobaba la suma de verificación del xpub.** Un carácter mal
    copiado se aceptaba sin protestar y generaba 200 direcciones ajenas: el
    usuario habría visto su cartera "sin actividad" y se habría quedado
    tranquilo. Falso negativo silencioso, el mismo patrón que el resto de fallos
    de esta jornada. Nuevo `decodeBase58Check`.
  - **No se validaba la longitud** del material decodificado (deben ser 78
    bytes) ni que la clave pública fuese comprimida (0x02/0x03).
  - **`tpub` se trataba como mainnet.** La red se detectaba mirando si el texto
    empezaba por "tb", "u" o "v" — y un `tpub`, el formato más común de testnet,
    empieza por "t" pero no por "tb". Generaba direcciones `bc1…` a partir de
    claves de testnet. Ahora se detecta por bytes de versión, que son
    inequívocos, con las diez variantes (x/y/z/Y/Z y t/u/v/U/V).
  - **`deriveChildPubkey` aceptaba índices endurecidos**, matemáticamente
    imposibles desde una clave pública. No era alcanzable desde la interfaz,
    pero una función criptográfica debe defenderse sola.
- Añadida la carpeta `tests/` con las cuatro baterías y su documentación,
  incluido qué **no** cubren: no sustituyen una auditoría externa.

---
## [1.11.0] — 2026-07-27
### Añadido
- **Las librerías del frontend se sirven desde tu propio nodo.** React, ReactDOM
  y Babel se cargaban desde unpkg.com, y las fuentes IBM Plex desde
  fonts.googleapis.com. Ninguno de los dos veía qué transacciones analizabas —
  pero ambos recibían tu IP pública, la hora y el referer en cada apertura del
  dashboard: sabían que usabas Txoko, cuándo y desde dónde. Ese metadato es
  justo lo que esta herramienta enseña a proteger. Ahora no sale ni una
  petición fuera de tu red, verificable con
  `grep -E '(src|href)="https?://' dashboard.html` (no devuelve nada).
  - Consecuencia práctica: **el dashboard funciona sin conexión a internet**.
  - Las librerías se descargan una vez durante la instalación y se **verifican
    por hash** (SHA-256 publicados en SETUP.md).
  - Versiones fijadas (`react@18.3.1`, `@babel/standalone@7.23.10`) en vez de
    rangos: antes el CDN decidía qué versión te entregaba y podía cambiar sin
    aviso.
  - `instalar-fuentes.sh` automatiza la descarga de IBM Plex (licencia OFL) y
    genera el CSS. Comprueba cada archivo y aborta si algo falla.
- **Caché de respuestas del nodo con TTL y coalescencia** en `useApi`. Las
  pestañas se montan y desmontan al navegar, así que ir a otra pestaña y volver
  repetía todas las peticiones. Ahora:
  - Las **transacciones confirmadas se cachean toda la sesión** — son
    inmutables, no hay motivo para volver a pedirlas. Analizador, rastro de
    procedencia y peritaje dejan de pedir las mismas por separado.
  - Historial de direcciones 60 s, bloques 60 s, mempool y comisiones 20 s,
    estado del sistema 2 s (para que el monitor siga mostrando datos vivos).
  - **Coalescencia:** dos componentes que piden lo mismo a la vez generan una
    sola petición al nodo, no dos. Mismo patrón que ya usaba
    `system-metrics.js` en el servidor.
  - Medido: repetir un rastreo forense ya explorado cuesta **cero peticiones**.

### Cambiado
- **Un hit de OFAC ya no penaliza la banda de privacidad.** Era un error
  conceptual con consecuencias ideológicas: que tus monedas hayan pasado por una
  dirección sancionada no revela nada más sobre ti — tu privacidad es idéntica
  antes y después. Lo que cambia es la probabilidad de que un servicio regulado
  te bloquee un depósito, que es otro eje: censurabilidad, no privacidad.
  Restar puntos ahí equivalía a dar por buena la idea de "monedas contaminadas",
  justo la que la fungibilidad de Bitcoin niega. Se sigue informando del riesgo
  real, ahora como aviso de censura y con el contexto que faltaba: la lista OFAC
  es una decisión política de un gobierno concreto, no una determinación
  judicial, y fuera de su jurisdicción solo llega a través de intermediarios que
  la aplican.
- **RBF pasa a informativo, sin penalización.** Es buena práctica —permite
  desatascar una transacción sin sobrepagar de entrada— y hoy lo activan casi
  todos los wallets, así que distingue poco. Restar puntos empujaba al usuario
  hacia una decisión peor para esconder una señal débil.
- Checks con inferencia fuerte (`round_numbers`, `unnecessary_input`,
  `output_type_mismatch`) reescritos con el patrón Hecho / Interpretación /
  Consecuencia que ya usaban `dust` e `input_type_mixing`. Antes afirmaban de
  más ("un analista puede identificarlo sin ambigüedad"); ahora explican cuándo
  la señal falla y por qué son PROBABLE y no CERTEZA.
- `timing`: el texto didáctico describía patrones entre varias transacciones
  cuando el check solo ve una. Además se aclara que la hora mostrada es la del
  bloque, no la de la firma — entre ambas puede haber horas de mempool.

### Documentación
- README: nueva sección **"Sí, esto es chain analysis"**. El peritaje usa las
  mismas técnicas que las empresas de vigilancia de cadena y negarlo restaba
  credibilidad ante quien lee el código. Se explica qué cambia —quién lo
  ejecuta, sobre qué, dónde se detiene, quién se queda el informe— y el motivo
  de fondo: la misma herramienta que sigue el rastro de un ladrón demuestra lo
  fácil que es seguir el tuyo.
- El informe forense advierte del coste de denunciar: entregarlo vincula tu
  identidad legal con esas direcciones de forma permanente, ante una autoridad
  que puede compartir el expediente con empresas de análisis. Antes se
  recomendaba denunciar sin mencionar el precio.
- Aviso junto a los botones de exportación: el archivo lleva tus direcciones y
  tu declaración dentro. Nada ha salido de tu red hasta ese punto; a partir de
  ahí depende de quien lo descarga.
- Corregido "un único archivo HTML autocontenido" (aparecía cuatro veces): desde
  la 1.11.0 las librerías viven en `vendor/`. Se sustituye por una descripción
  exacta que además dice más — lo que lees en el archivo es lo que se ejecuta,
  no hay versión compilada que auditar por separado.

### Corregido
- **El informe ya no atribuye al actor direcciones del otro lado de un
  CoinJoin.** Detectado probando un rastro que atraviesa un Whirlpool real: el
  informe declaraba *"el rastro se rompe en un CoinJoin — no se puede atribuir
  con honestidad más allá de este punto"* y, tres líneas más abajo, listaba
  **10 direcciones atribuidas al actor**, cinco de ellas salidas de esa misma
  mezcla. Eran direcciones de otros participantes, señaladas en un documento
  pensado para acompañar una denuncia.
  - Los dos fundamentos que las colaban fallan precisamente ahí: **CIOH** asume
    que quien gasta varios inputs juntos los controla, y un CoinJoin existe para
    romper esa suposición (es la excepción clásica a la heurística); y la
    **huella de software** sale estable por construcción, porque todos los
    participantes usan el mismo programa.
  - `finalizeForensicGraph` excluye ahora las transacciones marcadas como
    `mixer` del conjunto de direcciones del actor y del union-find, y la
    atribución por huella salta esos nodos.
  - Verificado con el mismo caso: de 10 direcciones atribuidas a 0.
- **El informe de wallet ya no da un aprobado optimista cuando faltan datos.**
  Mismo patrón que el fallo del peritaje, en la pieza central del proyecto:
  `scanWallet` usaba `.catch(()=>[])` en las tres consultas del escaneo, así que
  una dirección que el nodo no pudo servir quedaba indistinguible de una
  dirección sin actividad. Sus transacciones no se traían, no contaban para la
  reutilización, no entraban en el union-find y no aparecían en el historial —
  y el informe daba su valoración de salud sin mencionar que le faltaban datos.
  El sesgo iba siempre hacia el optimismo: menos actividad vista es mejor nota.
  - Las tres consultas usan ahora `getStrict` y registran los fallos en
    `report.scanErrors`, con la dirección, la rama y en qué fase ocurrió.
  - Aviso en rojo **antes** de la banda de salud (una valoración leída sin saber
    que faltan datos es peor que ninguna valoración), y bloque equivalente al
  	principio del export Markdown.

- **Tampoco atribuye al actor las direcciones de un custodio.** Misma raíz que
  el fallo anterior, descubierta probando la poda por rama con un depósito real
  en Bitfinex: el cluster CIOH ya excluía las direcciones de custodio, pero la
  atribución por huella de software no, así que la hot wallet del exchange
  acababa listada como "dirección del actor" mientras la conclusión, dos líneas
  más abajo, la identificaba correctamente como Bitfinex. La dirección donde el
  ladrón deposita es del exchange, no del ladrón. Ambos criterios están ahora
  alineados: ni mezclas ni custodios entran por ninguna de las dos vías.
  Verificado: de 2 direcciones atribuidas a 1 (solo la rama legítima).

---
## [1.10.1] — 2026-07-27
### Añadido
- **Tope de ramificación en el peritaje (`MAX_FANOUT`, 25 salidas).** Detectado
  probando el fixture de dust attack: una transacción que reparte a cientos de
  direcciones hacía que el motor encolara todas sus ramas y, sobre todo, que
  perfilara cada dirección de salida — 2 peticiones por dirección, así que una
  tx de 143 salidas suponía ~286 peticiones al nodo antes siquiera de llegar al
  frontier, y la pestaña se congelaba. Ahora, por encima del tope, la tx se
  trata como reparto masivo (dust attack, lote de retiradas, airdrop): se corta
  ANTES de perfilar nada, con `stopReason: "fanOut"` y su propia conclusión en
  el informe, redactada como límite deliberado y no como inferencia sobre quién
  controla esas direcciones. Verificado con una tx real de 143 salidas: 2
  peticiones en total.

### Corregido
- **Peritaje forense: un fallo de consulta ya no se presenta como "rastro
  completo".** Detectado probando contra el nodo real: cuando el backend
  devolvía un 503 o agotaba el timeout, la app lo mostraba como
  *"✓ Rastro completo — no quedan ramas por explorar"* y contaba esa rama como
  terminal. La causa eran dos capturas silenciosas encadenadas — `get` devolvía
  `mockData` ante cualquier error y `findSpendingTx` remataba con
  `.catch(()=>[])` —, así que `[]` por error era indistinguible de `[]` porque
  el output sigue sin gastar. En un informe pericial eso convertía una consulta
  fallida en la conclusión más accionable del documento: *fondos localizados
  sin gastar*.
  - Nuevo `getStrict` en `useApi`: propaga el fallo en vez de disfrazarlo.
    `get` no cambia, así que el resto del dashboard mantiene su comportamiento.
  - El motor (`findSpendingTx`, `advanceForensicHop`, `initForensicTrace`)
    distingue "no se pudo consultar" de "no hay gasto" y registra los fallos en
    `trace.queryErrors`.
  - El informe excluye las ramas con consulta fallida de "fondos localizados
    sin gastar", las lista en su propia sección y abre las conclusiones
    avisando de que el rastreo está incompleto. Incluido en los export JSON y MD.
  - La UI muestra contador de consultas fallidas y sustituye el falso
    "rastro completo" por un aviso con el detalle de qué falló.
- Peritaje: el error al obtener la transacción de origen ya no culpa siempre al
  txid — distingue un txid inexistente de un fallo del nodo.
- Peritaje: el botón "Generar informe" explica por qué está deshabilitado en
  vez de quedarse inerte sin dar motivo.

### Cambiado
- El aviso de consulta fallida ya no dice que el fallo "suele ser transitorio":
  cuando se repite sobre la misma dirección no lo es, y ahora lo explica —
  historial demasiado pesado para servirlo dentro del tiempo de espera, con la
  indicación de comprobarla a mano antes de dar el rastro por cerrado.

### Documentación
- README: documentadas dos limitaciones reales del peritaje — las ramas que no
  se pueden comprobar (y por qué cortar es deliberado, no un defecto), y que el
  tope de volumen mide número de transacciones y no peso, así que una dirección
  con pocas transacciones muy grandes puede agotar el tiempo de espera igual.

---
## [1.10.0] — 2026-07-16
### Añadido
- Peritaje forense: nueva pestaña que rastrea fondos robados o perdidos hacia
  adelante, salto a salto, desde una transacción de origen (`txid:vout`) hasta
  un punto de parada natural — custodio identificado, dilución excesiva,
  CoinJoin real, o fondos aún sin gastar. Todo el rastreo corre sobre tu
  propio nodo (Bitcoin Core + Fulcrum + Mempool self-hosted), como el resto
  de la app: ninguna consulta sale de tu red.
  - Sigue todos los outputs de cada salto (no solo el presunto cambio),
    porque los fondos pueden repartirse en varias ramas; cada rama se
    detiene de forma independiente.
  - **A demanda, salto a salto:** el rastreo no corre solo — tú decides
    cuándo se explora el siguiente salto con el botón "Seguir el rastro",
    viendo en todo momento cuántas transacciones se han explorado y
    cuántas ramas quedan pendientes. Mismo espíritu que el rastro de
    procedencia hacia atrás (RastroProcedencia), aplicado al rastreo hacia
    adelante. Puedes generar el informe con lo explorado hasta ese momento,
    sin necesidad de terminar el rastreo entero.
  - Tope de volumen de transacciones (`tx_count`) como cinturón de
    seguridad aparte del control manual: si una dirección de salida tiene
    un historial extremadamente largo (miles de transacciones — típico de
    un hot wallet de exchange), el rastro se detiene ahí por precaución
    aunque el heurístico de perfil no la clasifique como custodio. Evita
    que una sola rama intente paginar el historial completo de una
    dirección con decenas de miles de transacciones.
  - Reutiliza las heurísticas existentes del analizador (CIOH, detección de
    cambio estructural, huella de wallet, CoinJoin, entidades conocidas) y
    añade tres nuevas: perfil de dirección (personal vs hot wallet de
    exchange), cambio conductual (se gasta rápido vs queda quieto) cruzado
    con la señal estructural, y comparación de huella de software entre
    saltos consecutivos.
  - Confirma cadenas de peeling multi-salto: el check de patrón de pago
    simple ya avisaba de que una sola transacción no basta para confirmar
    una cadena — este módulo es lo que cierra ese hueco, siguiendo el rastro
    hacia adelante de verdad.
  - Marco de tres niveles en cada afirmación del informe: HECHO (dato
    on-chain verificable), INFERENCIA (conclusión de una heurística, con su
    propia sub-etiqueta CERTEZA/PROBABLE/POSIBLE) y DECLARACIÓN (lo que
    cuenta el afectado, en un formulario de texto libre, siempre mostrado
    aparte y nunca mezclado con los hechos).
  - Informe con resumen, declaración del afectado, cronología, direcciones
    atribuidas con su fundamento, fondos localizados sin gastar,
    conclusiones numeradas, recomendaciones (con un aviso fijo contra
    estafas de "recuperación de fondos" siempre que hay declaración),
    metodología y anexo de verificación. Exportable a JSON y Markdown, igual
    que el informe de wallet.
  - No identifica la identidad real de nadie: como mucho llega a "hot wallet
    de [exchange]" o "custodio no identificado". No hace denuncias ni envíos
    automáticos a terceros — el informe es un documento que decides tú a
    dónde llevar.

### Cambiado
- `unionFindCluster` (vinculación por CIOH) y `guessChangeOutput` (señales de
  cambio estructural) se extrajeron de `buildWalletReport` y `analyzeTx`
  respectivamente a funciones compartidas, sin cambio de comportamiento, para
  que el peritaje forense las reutilice salto a salto.

---
## [1.9.0] — 2026-06-12
### Añadido
- Informe de wallet completo. Tras cargar tu xpub (watch-only), el botón
  "Analizar wallet" examina el conjunto de tus transacciones y produce un
  informe con tres partes: salud general (ALTA/MEDIA/BAJA según reutilización
  de direcciones y vinculación), clusters de vinculación detectados por la
  heurística CIOH (common-input-ownership: direcciones que gastaste juntas y
  que un observador asume del mismo dueño), e historial de cada transacción
  con su banda de privacidad. Exportable a JSON y Markdown. Es la visión de
  conjunto que ningún explorador ofrece: no analiza una transacción aislada,
  sino qué puede agrupar un observador de toda tu actividad. El escaneo se
  hace por lotes con pausas para no saturar el nodo, y todo el cálculo ocurre
  en el navegador.
- Presentación de resultados reorganizada. El informe de privacidad ahora
  abre con un resumen ("N señales a revisar · M correctas · K informativas"),
  mantiene los problemas siempre visibles y agrupa las señales correctas e
  informativas en secciones colapsables. Al desplegar un problema, la
  explicación didáctica aparece directa, con una línea "Qué puedes hacer"
  según el caso (ya está en la cadena / depende de tu wallet / puedes
  evitarlo al construir la transacción).

### Cambiado
- Las recomendaciones usan un lenguaje más claro y menos técnico: "depende
  del wallet" y "puedes evitarlo" en lugar de etiquetas crípticas. El peso de
  cada señal en la banda se describe como alto/medio/bajo en vez de un número.

### Corregido
- El monitor del sistema (system-metrics.js) ya no usa la librería express:
  ahora funciona solo con Node.js, sin dependencias ni `npm install`. Descargar
  y ejecutar. Esto elimina el error "Cannot find module 'express'" que veían
  los usuarios nuevos.
- Los nombres de proceso en "Procesos destacados" se muestran limpios: un
  servicio Node con flags (p.ej. Mempool con --max-old-space-size) aparece
  como "node (index.js)" en vez de mostrar el argumento crudo.
- La medición de CPU del monitor usa una ventana de 500ms para una lectura
  más estable y coherente con la de herramientas como `top`.
## [1.8.0] — 2026-06-04

### Añadido

- Importación de etiquetas BIP-329. Permite cargar el archivo `.jsonl` que
  exporta Sparrow (File → Export → Export Labels) para ver tus propias etiquetas
  junto al análisis. El archivo se lee en memoria del navegador y no sale del
  nodo. La etiqueta de la transacción analizada aparece de forma destacada bajo
  el txid, y el modal lista todas las etiquetas cargadas (referencia + etiqueta)
  para verificar lo que tienes importado.
- Watch-only por clave pública extendida (xpub/zpub). Pegando el Master Public
  Key de Sparrow, Txoko deriva tus direcciones de recepción y cambio en local y
  marca automáticamente, en cada transacción analizada, qué outputs son tuyos:
  recepción (verde) o cambio (ámbar), con su valor y etiqueta. Es lo que ningún
  explorador público puede decirte, porque no conoce tus direcciones. Toda la
  derivación (BIP32 + bech32) está implementada desde cero con las primitivas
  del navegador (Web Crypto API), sin librerías externas, fiel a la filosofía de
  código auditable. El xpub nunca sale del navegador.
- Selector del número de direcciones a derivar (20 / 50 / 100 por rama). Más
  direcciones dan más cobertura para wallets muy usados, a cambio de unos
  segundos más de cálculo. Se muestran las tres primeras direcciones derivadas
  para que el usuario verifique, comparándolas con Sparrow, que ha cargado el
  wallet correcto.
- Estado "Dirección sin usar" en el análisis de direcciones. Una dirección sin
  historial on-chain ya no se muestra como "privacidad aceptable" (que sugería
  erróneamente que era buena), sino como dirección nueva sin nada que analizar.

### Cambiado

- El informe de privacidad usa el sustantivo correcto ("dirección" o
  "transacción") según lo que se esté analizando, en lugar de decir siempre
  "transacción".

### Corregido

- Corregida la aritmética de curva secp256k1 usada en la derivación watch-only.
  El inverso modular por el algoritmo de Euclides extendido fallaba en ciertos
  casos con enteros grandes, y la suma de puntos no manejaba el caso punto más
  su inverso. Las operaciones pequeñas (2G, 3G) salían bien pero la derivación
  de direcciones reales producía resultados incorrectos. Resuelto usando el
  inverso por el pequeño teorema de Fermat y completando los casos de la suma de
  puntos. Verificado contra los vectores de prueba estándar de RIPEMD-160,
  bech32 (BIP173) y secp256k1, y contra la identidad de grupo.

---

## [1.7.0] — 2026-06-04

### Añadido

- Detección de CoinJoin estructural (WabiSabi y similares). El motor reconocía
  CoinJoin por denominaciones fijas (Whirlpool) o por outputs de igual valor
  (CoinJoin genérico), pero no capturaba WabiSabi, que usa outputs de valor
  variable. Se añadió una tercera variante: detecta mezclas por forma estructural
  (muchos inputs y outputs, ratio cercano a 1, sin output dominante). El
  fingerprint "Wasabi o JoinMarket" se activa también para esta variante.

- Check de datos OP_RETURN en el motor de privacidad. Hasta ahora OP_RETURN solo
  se detectaba en la herramienta dedicada de TOOLS. Ahora aparece en el informe
  de privacidad de Auditoría: informa de cuántos outputs OP_RETURN hay y su
  tamaño en bytes, sin mostrar el contenido. Una transacción con OP_RETURN fuerza
  banda BAJA independientemente del resto de señales.

- Check de tipo de script legacy (P2PKH/P2SH). Detecta cuando los inputs usan
  direcciones legacy (1... o 3...) en lugar de SegWit (bc1q...) o Taproot
  (bc1p...). Informa de que forman un conjunto de usuarios cada vez más pequeño,
  lo que reduce el anonimato por conjunto. Peso −15, certeza CERTEZA,
  actionability "wallet" (depende del software).

### Cambiado

- En transacciones CoinJoin, los checks "Mezcla de tipos de script en inputs",
  "Inputs innecesarios (consolidación revelada)" y "Fingerprinting de wallet"
  ahora se muestran como informativos (punto gris, sin penalización) en lugar de
  como advertencias en rojo. En una mezcla, estas condiciones son esperadas por
  diseño del protocolo — no son fallos del usuario.

### Corregido

- El check de batch payment ya no dispara en transacciones WabiSabi. Al no
  detectarse como CoinJoin, el filtro `!likelyCJ` no se activaba y un WabiSabi
  de 327×279 aparecía marcado como batch. Resuelto al corregir la detección.

---

## [1.6.0] — 2026-06-03

### Añadido

- Detección de exchanges (cuarta categoría de entidad, junto a OFAC, minería y
  CoinJoin). Cuando una transacción o un eslabón del rastro toca una dirección
  asociada a un exchange conocido, se marca con 🏦 y aparece en el veredicto y
  en la distancia a entidad del rastro.
- La detección distingue la fiabilidad de cada dirección según su origen, en
  línea con la honestidad del resto de la herramienta:
  - Direcciones que el propio exchange ha publicado, o de etiquetas públicas
    conocidas, se muestran como coincidencia (certeza PROBABLE).
  - Direcciones inferidas por agrupación (clustering) se muestran como "posible"
    (certeza POSIBLE), avisando claramente de que es una inferencia estadística
    no confirmada por el exchange y de que puede haber falsos positivos.
- Conjunto inicial de ~590 direcciones de 16 exchanges, mayoritariamente de
  datos de agrupación pública, etiquetadas con su fuente para reflejar su
  fiabilidad.

---

## [1.5.0] — 2026-06-03

### Cambiado

- Mejoras de legibilidad del rastro de procedencia, para interpretar los datos
  de un vistazo:
  - Veredicto arriba del rastro: "Camino limpio" (en verde) si nada de lo
    explorado toca entidades marcadas, o "Atención" (en ámbar) indicando qué
    toca y a cuántos saltos. Responde de un vistazo si hay algo que revisar.
  - Jerarquía visual: los eslabones con buena privacidad y sin marcas se
    muestran discretos; los que merecen atención (marca o banda no alta) se
    destacan con color. El ojo va directo a lo relevante.
  - Barra visual de cantidad en cada eslabón, para captar la proporción sin
    leer la cifra; el número queda al lado como apoyo.
  - Indicador de estructura (entradas → salidas) siempre visible junto a cada
    eslabón, útil para detectar consolidaciones grandes de un vistazo.
  - Detalle ampliado al pasar el ratón (o tocar en móvil) sobre el indicador
    de estructura: número exacto de entradas y salidas, valor en sat y BTC,
    bloque, comisión y tasa. Mantiene la vista limpia y el detalle a mano.
- Contraste de texto mejorado en toda la aplicación. El texto secundario
  (descripciones, datos de apoyo, el texto dentro de las casillas y el pie de
  página) era demasiado tenue y costaba leerlo. Se ha subido su contraste en
  los cuatro temas, manteniendo la jerarquía visual: el texto secundario se
  sigue distinguiendo del principal, pero ahora se lee con comodidad.

---

## [1.4.0] — 2026-06-02

### Añadido

- Distancia a una entidad en el rastro de procedencia. A medida que se exploran
  eslabones, un resumen arriba del rastro indica a cuántos saltos está lo más
  cercano de cada tipo marcado (OFAC, minería, CoinJoin) — por ejemplo "minería
  · a 2 saltos". Es honesto sobre su alcance: solo cuenta las ramas que se han
  seguido y avisa de que puede haber más sin explorar.

### Corregido

- Transacciones coinbase como origen del rastro. Antes mostraban un aviso
  confuso ("este input no indica su transacción de origen"), como si fuera un
  error. Ahora se reconocen como el principio natural del rastro: un mensaje
  claro indica que esas monedas se crearon ahí como recompensa de minado y no
  proceden de ninguna transacción anterior.

---

## [1.3.0] — 2026-06-02

### Añadido

- Rastro de procedencia. En la pestaña Auditoría, debajo del informe de
  privacidad, cada input de la transacción tiene un botón "seguir rastro" que
  trae su transacción de origen y muestra un eslabón con: el txid de origen
  (enlace a tu propio Mempool), cuánto fluyó, la fecha, la banda de privacidad
  de esa transacción y marcas relevantes (CoinJoin, OFAC, minería, coinbase).
- El rastro es recursivo: desde cada eslabón se puede seguir bajando por sus
  propios inputs, encadenando saltos hacia atrás nivel a nivel. Funciona bajo
  demanda —cada consulta la pide el usuario, para no sobrecargar el nodo— y
  comparte una caché en memoria para no repetir transacciones ya consultadas.
  Incluye un límite de profundidad y un botón para limpiar el rastro.

### Corregido

- Detección de CoinJoin en el rastro: antes marcaba como CoinJoin cualquier
  transacción cuyo análisis mencionara la palabra (lo que ocurría siempre,
  porque existe un indicador con ese nombre aunque dé negativo), produciendo
  falsos positivos. Ahora la marca solo aparece cuando el indicador de CoinJoin
  da positivo de verdad (estructura de varios inputs y salidas de igual valor).

---

## [1.2.1] — 2026-06-02

### Cambiado

- La herramienta de OP_RETURN pasa de decodificar y mostrar el contenido a
  solo detectar su presencia y tamaño. Para auditar privacidad, lo relevante
  es que una transacción contenga datos arbitrarios (revela uso de un
  protocolo o servicio), no qué dicen esos datos. Además, la herramienta no
  debe funcionar como visor de contenido arbitrario de la cadena. Ahora indica
  cuántos outputs OP_RETURN hay y su tamaño en bytes, sin mostrar el contenido.

---

## [1.2.0] — 2026-06-01

### Añadido

- Exportación del informe de privacidad de una transacción en dos formatos,
  desde la pestaña Auditoría. El botón "↓ JSON" descarga el análisis completo
  con su estructura (score, banda, wallets detectados y todas las señales con
  su detalle), pensado para procesar con scripts o archivar en formato máquina.
  El botón "↓ MD" descarga el informe legible en Markdown (diagnóstico, qué
  puede saber un analista, limitaciones, recomendaciones y una tabla de señales),
  para leer o guardar como documento. Ambos se generan en el navegador y se
  descargan en local — no sale nada del nodo.

### Corregido

- El botón "Analizar privacidad" del Lab ahora envía correctamente el txid a
  la pestaña Auditoría y lanza el análisis. Antes la pestaña aparecía vacía
  porque el identificador no se transmitía entre vistas.

---

## [1.1.0] — 2026-06-01

### Añadido

- Exportación del UTXO Map a CSV. Un botón "↓ CSV" en el UTXO Map descarga
  todos los UTXOs de la dirección analizada con su información: txid, vout,
  valor en sats y en BTC, estado de confirmación, altura de bloque, score
  de privacidad y problemas detectados. El archivo se genera en el navegador
  y se descarga en local — no pasa por ningún servidor, no sale nada del nodo.
  Pensado para abrir en una hoja de cálculo y ordenar o filtrar los UTXOs
  por privacidad.

---

## [1.0.0] — 2026-05-31

Primera versión completa y funcional. Suite de auditoría de privacidad
Bitcoin self-hosted, con motor de análisis, exploración de cadena, monitor
del nodo y detección de entidades.

### Motor de análisis de privacidad

- Análisis de transacción con 15+ heurísticas ponderadas
- Score de privacidad por bandas (ALTA / MEDIA / BAJA), sin precisión
  numérica falsa
- Informe narrativo en prosa: explica qué puede deducir un observador
- Distinción explícita entre certeza, probabilidad y posibilidad en cada señal
- Etiquetas de accionabilidad: qué es evitable, qué depende del wallet,
  qué ya está en la cadena y no se puede cambiar

### Detección de CoinJoin

- Whirlpool con denominaciones fijas y tolerancia del 2%
- CoinJoin genérico por outputs de igual valor
- Filtro de denominación mínima (10.000 sats) — descarta mezclas de polvo
  que no son CoinJoin reales
- OP_RETURN tratado correctamente: un Whirlpool con OP_RETURN de cambio se
  sigue detectando
- Supresión de penalizaciones coherente: en una mezcla no penaliza señales
  que son esperadas

### Fingerprinting de wallet

- Detección de BlueWallet, Bitcoin Core, Sparrow, Electrum y wallets con
  Taproot nativo a partir de señales estructurales combinadas
- Wallet inferido del tipo de CoinJoin (Whirlpool → Samourai/Sparrow,
  genérico → Wasabi/JoinMarket)
- En CoinJoin el fingerprinting es informativo y no penaliza

### Detección de entidades

- Índice de ~155 direcciones embebido, lookup local sin consultas externas
- OFAC: alerta crítica si una dirección está en la lista de sanciones
  (Blender.io, Sinbad, Garantex, Suex, Chatex, Lazarus Group)
- Mining pools: marca informativa de origen en pool de minería
  (F2Pool, Foundry, Antpool, MARA, Braiins, Luxor, Ocean, NiceHash, Bitfury)

### Exploración y monitor

- Explorador de bloques y búsqueda on-chain
- Vista de Mempool con stats, fees y bloques proyectados
- Monitor del nodo: estado de Bitcoin Core, sistema y logs en tiempo real
- UTXO Map con score de privacidad por moneda
- Herramientas: conversor de unidades, validador de dirección, decodificadores

### Experiencia de uso

- El análisis se mantiene al cambiar de pestaña y volver (Privacy Lab y
  Auditoría) — el estado vive en memoria, sin escribir en disco
- Diseño responsive para móvil
- Tema cypherpunk

### Filosofía

- Sin dependencias externas de datos: todo viene del propio nodo del usuario
- Ninguna consulta sale de la red del usuario
- Didáctica honesta sobre las limitaciones del análisis

[1.0.0]: https://git.bitcointxoko.org/pikaro/txoko-dashboard