Bitcoin Core corrige el arranque con pruning e índices nuevos
Publicación de la fuente: 2026-09-18 · Análisis editorial publicado: 2026-09-20
El PR #36150 evita podar bloques antes de sincronizar un índice recién activado. Está integrado en master y no equivale todavía a una versión instalada.
Análisis e implicaciones prácticas
Esta sección contiene nuestro análisis y cálculos ilustrativos, separados del informe original.
El fallo exacto corregido
El pull request #36150 de Bitcoin Core se integró en master el 11 de septiembre de 2026 y Bitcoin Optech lo destacó el día 18. El disparador era concreto: partir de un nodo sin podar, activar a la vez un índice nuevo y un objetivo de pruning en el mismo reinicio, y permitir que el podado de arranque actuara antes de que el índice vacío bloqueara los bloques necesarios. Los datos podían borrarse antes de sincronizar. El parche inicializa el bloqueo en génesis cuando el índice aún no tiene best block y conserva el historial requerido.
Qué índices son relevantes
Optech cita el índice de filtros compactos y el índice de estadísticas UTXO. El primero ayuda a clientes y servicios que consultan filtros sin descargar cada transacción; el segundo acelera consultas concretas sobre UTXO. Son funciones del nodo, no controles de hashrate ASIC, y no aumentan la velocidad de minería. La relación es operativa: pools, mineros solo, monitorización y pagos dependen de nodos fiables. Si el nodo no arranca o el índice no está disponible, el software aguas abajo pierde una fuente aunque los ASIC sigan encendidos.
Por qué el comportamiento anterior era costoso
Una vez podados los bloques necesarios, cambiar una opción no los recrea desde el disco local. La discusión del PR indica que la recuperación práctica podía exigir un reindex completo: volver a obtener o leer muchos datos y esperar la construcción. En un sitio remoto consume ancho de banda, I/O y tiempo, prolongando la degradación. El bug no dañaba firmware ASIC ni cambiaba consenso. Era un problema de orden de arranque entre índices y pruning, pero podía convertir una modificación rutinaria en una ventana larga de recuperación.
Código integrado no es versión instalada
GitHub confirma que el cambio está integrado en master y asociado al hito 32.0. No demuestra que un nodo de producción ya lo tenga, ni conviene descargar una build master arbitraria por un solo fix. Compruebe versión real, notas del paquete y canal firmado. Si hoy debe reconfigurar una versión sin parche, no active índice nuevo y pruning en el mismo reinicio. Secuencie el trabajo para completar el índice mientras los bloques siguen disponibles o siga un procedimiento probado del mantenedor.
Planifique antes de tocar almacenamiento
Inventaríe tamaño de datadir, espacio libre, estado de pruning, índices, tip, progreso y cobertura de backup. Estime duración de reindex con ese hardware y red y compruebe si la ventana soporta el peor caso. Asegure que pool o monitorización dispone de otro nodo sano. Copie configuración y unidades de servicio, pero no trate una copia del directorio blockchain en ejecución como backup portátil garantizado. Use apagado y snapshot documentados y conserve logs con argumentos exactos del primer reinicio.
Verificación tras reinicio
Tras reiniciar, confirme chain tip, peers razonables y progreso de cada índice sin error inmediato. Vigile disco e I/O porque la indexación inicial puede sostener carga. Desde un cliente staging ejecute los RPC exactos usados por minería o pagos. Valide por separado plantillas de bloque o workflow del pool: sincronizar un índice no demuestra todas las dependencias. Mantenga el nodo anterior hasta superar un periodo de observación. Si se detiene el progreso, conserve logs y no cambie varias variables simultáneamente para mantener el diagnóstico.
Alcance y límite de seguridad
El PR #36150 es una corrección de fiabilidad para una transición de configuración. La discusión no describe ejecución remota, fondos robados, bloques inválidos ni división de consenso. No debe llamarse vulnerabilidad crítica sin evidencia. Importa porque la disponibilidad del nodo forma parte de la resiliencia minera y una transición de almacenamiento mal planificada puede detener servicios. Clasifique con precisión, priorice según uso real de pruning e índices y mantenga autenticación, segmentación, binarios firmados y mínimo privilegio en su plan de hardening.
Qué debe hacer el operador ahora
Primero determine si algún nodo activará a la vez pruning y un índice ausente. Si no, el disparador estrecho quizá no aplique. Después compruebe versión y documentación sin suponer que master está instalado. Pruebe la transición exacta en un nodo no crítico con disco suficiente y plan de recuperación medido. Siga la primera versión que incluya el fix y valide checksum firmado. La lección es procedural: ahorrar almacenamiento y añadir servicios compiten por los mismos bloques históricos, de modo que secuencia y evidencia de rollback deben constar en el cambio.
Evidencias para el cambio
Adjunte PR upstream, nota del paquete que incluye el fix, checksum firmado, estado previo, diff de configuración, previsión de disco y recuperación. Después añada logs, tiempo del índice y resultados RPC de servicios productivos. Registre si se evitó reindex completo; el uptime del proceso no demuestra éxito. Así otro operador puede repetir, el revisor distingue código upstream del paquete y el rollback tiene base si almacenamiento o rendimiento difieren del canary.
Fuente: Bitcoin Core / Bitcoin Optech ↗
Calculadora de minería ↗
