Una auditoría de código abierto detecta un desplazamiento fijo de hashrate en el firmware Bitfortun BS-1
Publicación de la fuente: 2026-09-10 · Análisis editorial publicado: 2026-09-27
La revisión del código público encontró rutas de pantalla que suman 400 GH/s al hashrate medido y un desplazamiento separado de 0,4 TH/s en el historial de un minuto. El valor principal de la API no estaría modificado, permitiendo compararlo con el pool y la pantalla.
Análisis e implicaciones prácticas
Esta sección contiene nuestro análisis y cálculos ilustrativos, separados del informe original.
Qué encontró la revisión
Solo Satoshi informó de adiciones fijas en varias rutas de visualización del firmware público del Bitfortun BS-1. En DisplayDriver::updateHashrate(), el código lee el hashrate actual más 400.0f tanto para la eficiencia mostrada como para el valor de pantalla. En history.cpp, la media de un minuto devuelve 0,4 adicional y otra línea desplaza un búfer nuevo en 400 elementos. El análisis revisó el commit bbd42bc de un repositorio iniciado el 12 de agosto de 2026 y lo comparó con el upstream NerdQAxe+ citado por el proyecto.
Los desplazamientos afectan la presentación, no el trabajo probado
Según el informe, el campo principal hashRate de /api/system/info no está inflado. La distinción importa: el firmware calcula el panel, mientras los ingresos dependen de shares válidos aceptados por el pool. Sumar una constante puede hacer que la pantalla parezca más rápida sin producir un nonce adicional. ASIC.tools no probó un BS-1 físico, por lo que limita su conclusión a las rutas publicadas y la comparación del revisor. No demuestra cambios en registros del pool, bloques Bitcoin ni todos los endpoints de la API.
El tamaño de 400 GH/s
El BS-1 se comercializó alrededor de 5,5 TH/s, de modo que 0,4 TH/s representa aproximadamente un siete por ciento del nominal. El efecto relativo crece si la máquina rinde por debajo y disminuye si supera el objetivo. Al ser constante, podría ocultar en parte una degradación por temperatura o voltaje. El código no prueba intención: puede ser una decisión de presentación, un artefacto de pruebas o un error. Cualquiera de esas explicaciones exige retirar o declarar claramente la suma antes de considerar la pantalla una medición.
El pool es la referencia independiente
Un pool estima hashrate por shares enviados y dificultad durante el tiempo. El método es ruidoso en ventanas cortas, pero independiente de la pantalla. El propietario puede comparar 24 horas o más del pool con el campo API sin modificar y el panel, revisando shares rechazados y stale. Si la pantalla queda aproximadamente 0,4 TH/s por encima de la API bajo distintas condiciones, coincide con el patrón publicado. Una lectura aislada no basta porque varianza, cortes de red, calentamiento y reinicios generan diferencias reales.
El método de comparación es reproducible
El revisor clonó el repositorio BS-1 en un commit indicado, siguió cada llamada que alimenta pantalla y API HTTP, clonó el upstream y buscó las mismas cadenas en su historial. En upstream, DisplayDriver llama getCurrentHashrate() sin +400.0f y los desplazamientos no aparecieron. Una respuesta sólida del fabricante publicaría patch, versión etiquetada, binarios reproducibles y una definición de valores brutos, medios o estimados. Deben guardarse hashes de commit porque una rama mutable puede cambiar después de la auditoría.
Código abierto permite verificar, no garantiza honestidad
Publicar el código no evitó el cálculo cuestionable, pero lo hizo visible. Open source aún necesita revisores, compilaciones deterministas y una forma de confirmar que el binario del equipo coincide con el repositorio. Un proveedor podría publicar un árbol y entregar otra imagen o incluir componentes opacos. El operador debe buscar versiones firmadas, checksums, procedencia de compilación y rollback documentado. El código auditable es un control esencial, pero no sustituye pruebas de hardware, vatímetro ni medición del pool.
Qué puede comprobar un propietario con seguridad
Primero registre versión y configuración sin cambiar frecuencia o voltaje. Exporte el hashrate de la API, capture la pantalla y obtenga accepted hashrate del pool durante al menos 24 horas. Anote temperatura, uptime, rechazos y reinicios. Unifique unidades: 400 GH/s equivalen a 0,4 TH/s. Para actualizar, use sólo una versión que identifique la revisión exacta, verifique su checksum y conserve una imagen de recuperación. Un binario comunitario no verificado puede crear más riesgo que una corrección cosmética.
Qué evidencia resolvería el problema
Una resolución completa incluiría explicación del fabricante, patch público, fuente etiquetada, hashes de binarios coincidentes y mediciones independientes antes y después. La interfaz debería separar estimación del chip, hashrate derivado de shares y resultado del pool. Hasta entonces, el comprador debe tratar la pantalla del BS-1 como una estimación y usar shares aceptados para decisiones económicas. El caso recuerda que todo valor local de eficiencia es salida de software; una granja necesita medición externa y auditoría de código cuando sea posible.
Fuente: Solo Satoshi / public source code ↗
Calculadora de minería ↗
