Bitcoin Core

Pavel vende libros a cambio de bitcoin. Una clienta le muestra un justificante en el móvil, pero él quiere saber si el pago ha llegado de verdad y aparece en un bloque válido. Puede consultar un explorador público o utilizar una cartera conectada a su propio nodo. Bitcoin Core es el programa que permite mantener ese nodo: recibe datos de otros, pero comprueba por sí mismo si son válidos. Aquí, un nodo es un ordenador con un programa que comprueba por su cuenta las reglas de Bitcoin; un bloque es un conjunto de transacciones añadido al historial compartido. Pavel es un ejemplo ilustrativo. La idea es sustituir la confianza ciega en una pantalla ajena por una verificación propia. Instalarlo no lo convierte en minero, no le regala BTC ni le permite deshacer pagos de otras personas. El proyecto publica su código bajo la licencia MIT, que permite estudiarlo, modificarlo y distribuirlo respetando sus condiciones. [1] [16]

Es fácil confundir ambas tareas porque Bitcoin Core puede hacer las dos. El nodo comprueba la historia y los bloques nuevos. La cartera sigue los fondos correspondientes, genera direcciones y prepara transacciones; si gestiona claves privadas, también puede firmar con ellas. Una clave privada es un dato secreto con el que la cartera crea una firma digital que autoriza gastar los bitcoins correspondientes. La propia clave no se envía a otros nodos. Core puede funcionar sin cartera. Pavel podría usar otra aplicación compatible para pagar y su nodo como fuente de datos verificados; algunas conexiones requieren software adicional. Tener Core abierto no conecta automáticamente todas las demás carteras a ese nodo. Para orientarse entre los nombres: bitcoin-qt ofrece una interfaz gráfica, bitcoind funciona en segundo plano y bitcoin-cli envía órdenes al programa. [12] [17]

Un nodo nuevo tiene que ponerse al día con la historia. Es la Initial Block Download, o IBD: la descarga inicial de bloques. Durante la sincronización habitual descarga bloques y comprueba sus enlaces, el trabajo de los mineros y las reglas de las transacciones. Así construye su chainstate, un registro local de salidas todavía no gastadas, llamadas UTXO. Una salida de transacción indica una cantidad y las condiciones para gastarla, como una firma necesaria. Permanece en ese registro hasta que otra transacción la gasta. No es una lista de nombres y cuentas bancarias. La velocidad depende del equipo, el disco y la conexión; un comienzo lento no implica necesariamente un fallo. Pavel espera a que termine antes de verificar pagos actuales.

Conviene matizar algo: assumevalid puede omitir comprobaciones de scripts, es decir, condiciones de gasto, muy atrás en el historial bajo determinadas condiciones; -assumevalid=0 desactiva ese atajo. Otra función, AssumeUTXO, permite partir de una instantánea de estado comprobada y procesar la historia anterior en segundo plano. La instantánea guarda el estado de los UTXO en un bloque concreto. El programa compara primero su hash, una huella digital, con el valor previsto en su código; eso no significa que ya haya verificado por sí mismo toda la historia anterior. Sus supuestos son distintos: no sería correcto afirmar que todas las instalaciones han realizado exactamente las mismas comprobaciones desde el primer momento. [9] [10] [12] [17]

Una vez sincronizado, Core sigue recibiendo datos de los nodos conectados, llamados peers. Guarda las transacciones sin confirmar que acepta en su Mempool, una sala de espera temporal. Estar ahí no equivale a tener una confirmación en un bloque, y cada nodo puede guardar transacciones diferentes. Cuando llega un bloque, Core lo verifica. Entre las cadenas candidatas válidas elige la de mayor trabajo acumulado, no la que tenga más votos de ordenadores ni simplemente más bloques. Pavel distingue por tanto entre haber visto el pago y tenerlo confirmado. Su nodo tampoco garantiza que una transacción se incluya inmediatamente ni elimina las reorganizaciones, en las que otra rama válida sustituye parte de la historia que estaba siguiendo. [16]

Imaginemos que el nodo de Pavel no admite una transacción sin confirmar en su Mempool. Eso no significa que nunca pueda aparecer en un bloque válido. Las reglas de consenso determinan qué bloques y gastos son válidos para el nodo. La relay policy local añade condiciones sobre las transacciones sin confirmar que acepta y retransmite, por ejemplo para proteger sus recursos frente a la saturación. Esa política no se aplica del mismo modo a las transacciones dentro de un bloque recibido: ahí cuenta la validez según el consenso. Por eso, diferencias entre configuraciones del Mempool no dividen por sí solas la red. Distinguir ambos niveles permite seguir los debates sobre Core sin confundir cada ajuste con una modificación de las reglas monetarias. [13]

Core guarda datos de bloques, el estado del nodo y, si se usan, carteras. El pruning ahorra espacio eliminando archivos antiguos de bloques y datos necesarios para deshacer sus cambios después de procesarlos. El nodo sigue verificando bloques nuevos; simplemente deja de tener todo el archivo a mano. Consultar datos históricos o volver a buscar pagos antiguos puede exigir descargarlos de nuevo. Los índices facilitan ciertas búsquedas; txindex, por ejemplo, es incompatible con pruning. Conviene elegirlos según el servicio que deba prestar el nodo. La diferencia esencial es otra: los bloques públicos pueden descargarse otra vez, pero no permiten recuperar claves privadas perdidas. Una cartera Core necesita su propia copia de seguridad. Con el programa en marcha, utiliza su función de respaldo, como backupwallet, en lugar de copiar sin más una base de datos que está recibiendo escrituras. [11] [12]

Pavel empieza por la web oficial y lee las instrucciones de la versión elegida. Una suma SHA-256 es la huella del archivo descargado: detecta diferencias respecto al archivo esperado. Por sí sola no dice quién publicó esa huella. Por eso también hay que comprobar las firmas digitales y la identidad de sus claves. Si un atacante entrega tanto el programa como su propia suma, que coincidan no frustra el ataque. Para verificar más a fondo, el proyecto utiliza compilaciones reproducibles: personas independientes pueden obtener archivos idénticos a partir del mismo código y comparar resultados. Guix ayuda a homogeneizar el entorno de compilación. Esto refuerza la comprobación del origen del programa, pero no demuestra que su código esté libre de errores. [8] [7]

Core ofrece JSON-RPC, una interfaz con la que otros programas pueden controlarlo. Sirve para consultar el estado del nodo e integrar servicios, pero según las carteras disponibles y los permisos también puede permitir operaciones con fondos. Sus credenciales no deben entregarse a un supuesto ayudante. La interfaz no cifra por sí misma el tráfico y no está diseñada para exponerse a Internet. Conectarse normalmente a otros nodos Bitcoin es distinto de hacer públicos estos controles. Para el acceso local, Core también utiliza credenciales temporales en el archivo .cookie. La administración remota necesita una conexión protegida y acceso restringido, conforme a la documentación. Para probar un nodo no hace falta comenzar abriendo su administración al mundo. [14]

Cualquiera puede proponer un cambio de código. Otros colaboradores lo leen, prueban y comentan; los mantenedores del repositorio, o maintainers, pueden incorporar los cambios aceptados. Eso no les da control remoto sobre el nodo de Pavel. Su operador decide qué programa ejecuta. Tampoco esa elección es un voto que permita a una persona cambiar las reglas de los demás: una modificación incompatible puede separar su nodo del resto. Bitcoin Core es una implementación importante de las reglas, no una empresa dueña de toda la red. Al leer anuncios, distingue entre propuesta, incorporación al código, publicación de una versión y uso real. Entre esos pasos puede haber un largo recorrido. [15]

Puedes empezar manteniendo un nodo sin guardar claves privadas en él. Pavel verifica el archivo y las firmas, deja terminar la IBD y comprueba que su cartera realmente utiliza datos de su nodo. Después vigila conexiones, avance de bloques y espacio libre. Antes de actualizar lee las release notes, que explican cambios y posibles condiciones de migración; si usa una cartera, comprueba el respaldo y la recuperación. El archivo de diagnóstico debug.log ayuda a investigar problemas, pero no conviene publicarlo sin revisarlo. Pruning, índices y RPC deben ajustarse a su uso, no a un tutorial copiado a ciegas. Un nodo propio debe ser una herramienta comprensible de verificación. No es obligatorio para una primera compra pequeña, pero cobra sentido cuando quieres saber por qué consideras válidos tus pagos. [12] [14]