Glosario Técnico de Bitcoin Core

Fundamentos Previos

C++ moderno (C++11 en adelante): Conjunto de estándares del lenguaje C++ posteriores a C++11 que incluyen mejoras de sintaxis y librerías para código más claro y seguro. Estas versiones introducen características como punteros inteligentes y RAII que facilitan la gestión automática de recursos.
RAII, punteros inteligentes, STL, lambdas, templates: Características clave de C++ moderno: RAII (Resource Acquisition Is Initialization) garantiza liberar recursos automáticamente en los destructores; los punteros inteligentes (std::unique_ptr, std::shared_ptr) automatizan la gestión de memoria; la STL (Standard Template Library) ofrece contenedores y algoritmos genéricos; las lambdas son funciones anónimas inline; y los templates permiten programación genérica con código reutilizable.
Sistemas operativos (procesos, hilos, sockets, I/O asincrónico): Un proceso es la instancia en ejecución de un programa. Un hilo es una subunidad de ejecución dentro de un proceso. Un socket es un punto final de comunicación en red que permite a dos procesos intercambiar datos. La E/S asincrónica son operaciones de entrada/salida no bloqueantes: el hilo inicia la operación y puede seguir ejecutando, recibiendo notificación cuando ésta concluye.
Redes TCP/IP y protocolos personalizados: El modelo TCP/IP define cómo se envían los datos en paquetes con direcciones de origen/destino a través de redes. Sobre TCP/IP se pueden implementar protocolos a nivel de aplicación personalizados (por ejemplo, el protocolo P2P de Bitcoin), que especifican cómo formatear y comunicar mensajes propios. Estos protocolos son conjuntos de reglas comunes que ambas partes deben seguir.

Criptografía aplicada

SHA-256, RIPEMD-160: Son funciones hash criptográficas. SHA-256 genera un resumen de 256 bits y es la base de la prueba de trabajo (PoW) de Bitcoin, además de usarse en IDs de bloques/transacciones. RIPEMD-160 genera resúmenes de 160 bits; en Bitcoin se aplica a la clave pública (tras SHA-256) para producir direcciones más cortas y seguras.
ECDSA y curva secp256k1: El algoritmo de firma digital ECDSA (Elliptic Curve Digital Signature Algorithm) con la curva elíptica secp256k1 se usa para firmar transacciones en Bitcoin. Secp256k1 fue elegida por Satoshi Nakamoto por su alta seguridad y eficiencia en generación de claves.
Codificación Base58Check / Bech32: Base58Check es un esquema que codifica datos binarios en una cadena alfanumérica (sin caracteres ambiguos) agregando un checksum. Se usa para direcciones legacy de Bitcoin (empiezan por “1” o “3”). Bech32 es el formato moderno de direcciones SegWit (empiezan por “bc1”), más legible y sin distinción de mayúsculas/minúsculas.
Árboles de Merkle: Estructura de datos en forma de árbol hash binario que agrupa transacciones en pares y calcula hashes ascendentes hasta obtener una raíz única (Merkle Root). Cada nodo padre contiene el hash de sus hijos, por lo que verificar la raíz permite validar eficientemente todas las transacciones del bloque.
Proof-of-Work (PoW): Mecanismo de consenso en Bitcoin donde los mineros deben resolver un problema criptográfico (encontrar un hash del bloque que cumpla cierta dificultad) demostrando que dedicaron esfuerzo computacional. Es un protocolo de consenso distribuido usado por Bitcoin, donde el bloque con mayor trabajo acumulado se acepta como válido.

Estructura del protocolo de Bitcoin

Formato de transacciones y bloques: Una transacción Bitcoin incluye: versión, lista de entradas (UTXOs previos consumidos) y de salidas (montos y scripts de bloqueo), más el campo lock_time. Un bloque agrupa varias transacciones e incluye en su cabecera (80 bytes) campos como versión, hash del bloque anterior, Merkle root de transacciones, marca temporal, dificultad y nonce.
Bitcoin Script y principales tipos (P2PKH, P2SH, P2WPKH): Bitcoin Script es el lenguaje de scripting basado en pila (no Turing-completo) usado para definir condiciones de gasto. Los scripts comunes incluyen P2PKH (Pay-to-PubKeyHash, direcciones legacy que usan hash de clave pública; es el más común), P2SH (Pay-to-ScriptHash, direcciones que empiezan con “3” y permiten scripts complejos o multifirma), y P2WPKH (direcciones SegWit nativas en formato Bech32 “bc1..”, con firmas segregadas para eficiencia).
Mempool y políticas de relay: El mempool es la “sala de espera” local de un nodo donde quedan las transacciones no confirmadas. Las políticas de relay definen qué transacciones acepta y retransmite un nodo: típicamente sólo las con tarifa mínima (por defecto 1 sat/vByte), y si el mempool se llena, se expulsan (“eviction”) las de menor comisión. También se aplican reglas de expiración temporal y rechazo de transacciones inválidas o con RBF inadecuado.
Mecanismo de consenso y reglas (BIP34, BIP141): Bitcoin sigue el consenso de Nakamoto: la cadena más larga (más trabajo) es la válida. Algunas reglas específicas son implementadas por BIPs. Por ejemplo, BIP34 exige incluir la altura del bloque en la transacción coinbase (desde el bloque 227.836) para evitar bifurcaciones accidentales. BIP141 (SegWit) introduce el “testigo segregado”, moviendo las firmas fuera del Merkle tree de transacciones y habilitando el nuevo formato de direcciones Bech32.

Arquitectura de Bitcoin Core

Estructura del repositorio y carpetas clave: El código fuente de Bitcoin Core está organizado por componentes. Por ejemplo, src/ contiene los subdirectorios principales como consensus/, net/, wallet/, rpc/, test/, etc. Las carpetas src/bitcoin-cli.cpp, src/bitcoind.cpp, src/wallet/, etc. contienen la implementación respectiva de la CLI, del daemon y del monedero.
Archivos validation.cpp y chainparams.cpp: validation.cpp agrupa la lógica principal de validación de bloques y transacciones (funciones ConnectBlock, AcceptToMemoryPool, etc.), aplicando las reglas de consenso. chainparams.cpp define parámetros de red (mainnet, testnet, regtest): contiene hashes genesis, puertos, exigencias de dificultad, alturas de activación de forks, etc. Ambos archivos son fundamentales para entender cómo se validan bloques y se configuran las redes.
Subsistemas: nodo, wallet y P2P: Bitcoin Core actúa como un nodo completo: descarga y verifica cada bloque y transacción antes de propagarlos a otros pares. El subsistema wallet gestiona llaves privadas, direcciones y el conjunto UTXO local para construir/transmitir transacciones. El subsistema P2P maneja la comunicación de red: descubrimiento de pares, intercambio de mensajes (version/verack, inv, getdata, block, tx, etc.) y mantenimiento de conexiones.
Indexación de UTXO y block index: Bitcoin Core mantiene bases de datos indexadas en LevelDB. El block index (mapa mapBlockIndex) almacena metadatos de cada bloque (versiones, hashes, altura, etc.) en memoria. El UTXO set se guarda en la base chainstate de LevelDB, almacenando todos los outputs no gastados con sus scripts, montos y datos necesarios.
Uso de LevelDB: Bitcoin Core utiliza LevelDB (almacenamiento clave-valor embebido) para datos persistentes. Por ejemplo, la carpeta blocks/index/ es un LevelDB que contiene metadata de todos los bloques conocidos, y chainstate/ es un LevelDB con la representación actual de todos los UTXOs. Estos índices aceleran las operaciones de validación y búsqueda de bloques/transacciones.

Red P2P

Handshake: mensajes version y verack: Al conectar con otro nodo, se intercambia primero un mensaje version (que incluye la versión de protocolo, capacidades y nonce único) y el nodo remoto responde con su propio version. Después cada lado envía un verack para confirmar la recepción del version. No se intercambian otros mensajes hasta completar este handshake.
Manejo de inv, getdata, block y tx: Un nodo anuncia nuevos bloques o transacciones con el mensaje inv (“inventory”): lista hashes de objetos disponibles. El receptor filtra los ya conocidos y usa getdata para pedir contenido específico de bloque(s) o transacción(es). Entonces el nodo responde con mensajes block (conteniendo un bloque completo) o tx (conteniendo una transacción) según corresponda.
Mecanismos de protección (eviction y DoS): Bitcoin Core asigna puntajes DoS a mensajes o peers que violan el protocolo; si superan umbrales, se les banea (se abandona la conexión). Además, para manejar conexiones, el nodo puede realizar eviction de pares: si hay más conexiones de las permitidas, desconecta periódicamente peers menos valiosos (p. ej. más lentos o con peor latencia), priorizando relaciones de intercambio de bloques eficientes. Internamente también expulsa (evicts) transacciones de baja tarifa cuando el mempool se llena.
Compact Block Relay (BIP152): Con BIP152 se introdujo el mensaje cmpctblock (compact block) para acelerar el relevo de bloques. En lugar de enviar todo el bloque, un nodo envía el encabezado del bloque más una lista de “short IDs” de transacciones; el par reconstruye el bloque usando transacciones ya conocidas en su mempool. Esto reduce el ancho de banda necesario en la propagación de bloques.

Testing y contribución

Pruebas funcionales en Python: Son tests de alto nivel (end-to-end) escritos en Python que ejecutan uno o varios nodos bitcoind y simulan flujos reales (envío de tx, reorganizaciones, pruebas de características, etc.). Verifican que distintos componentes (red, wallet, RPC) funcionen juntos correctamente.
Unit tests en C++: Son pruebas de bajo nivel escritas en C++ (usualmente usando Boost.Test) para comprobar funciones o clases aisladas. Aseguran que fragmentos específicos de código funcionen según lo esperado. En Bitcoin Core las pruebas unitarias están en src/test/ y se ejecutan con make check.
Bitcoind, bitcoin-cli y manejo de logs: bitcoind es el daemon completo de Bitcoin Core que corre en segundo plano y maneja la red y la blockchain. bitcoin-cli es la interfaz de línea de comandos que envía comandos RPC al bitcoind (por ejemplo, getblockchaininfo, sendtoaddress, etc.). Bitcoind escribe su salida detallada en archivos de log (e.g. debug.log en el directorio de datos) para registro de eventos, errores e información de depuración.
Pull requests y participación en Review Club: Un Pull Request (PR) es una propuesta de cambio al código fuente enviada en GitHub para revisión. Bitcoin Core alienta a colaborar mediante PRs siguiendo la guía de contribución. El Bitcoin Core PR Review Club es un foro mensual (IRC) donde voluntarios revisan PRs abiertos y explican partes del código a nuevos contribuidores, ayudando a entender el proceso de revisión y el código base.
Lecturas y BIPs: Recursos clave incluyen Mastering Bitcoin (libro de Andreas Antonopoulos) como guía exhaustiva; BIPs relevantes para Bitcoin Core como BIP16, BIP32/39 (wallet HD), BIP141 (SegWit), BIP340-342 (Taproot/Schnorr); y foros como Delving Bitcoin y el boletín/developer Slack de Bitcoin Optech, que publican actualizaciones técnicas, casos de estudio y eventos para desarrolladores.