Al firmar, Bitcoin Core 26.2 ya no da por hecho que un TapMiniscript es correcto (#29853), getnetworkhashps lanza un error ante parámetros inválidos (#28554) y setmocktime tiene un máximo obligatorio (#29869). También compila con miniupnpc 2.2.8.
Antes de Bitcoin Core 0.10.1, los mensajes recibidos podían llegar a 32 MiB, así que un atacante podía forzar esa reserva de RAM por conexión y quizá tumbar el nodo. Lo notificó el usuario de Bitcointalk Evil-Knievel; #5843 bajó el límite a 2 MiB, luego ampliado a 4 MB para Segwit. La divulgación anunciada para 2015 se aplazó y los detalles salieron a la luz en 2024.
IPv6 abarataba el engorde de la lista de bloqueos de Bitcoin Core, que no tenía límite, y cada mensaje GETADDR obligaba a recorrerla por cada dirección devuelta, hasta 2500. De gravedad alta, tanto la caída por memoria como el consumo de CPU se resolvieron con #19219, publicado en 0.20.1 y 0.21.0.
Dos fallos en la gestión del mensaje version, un desbordamiento de entero con signo y un error lógico en abs64, permitían a un atacante desviar el tiempo ajustado de una víctima hasta que esta rechazaba bloques nuevos por estar fechados demasiado lejos en el futuro. El atacante tenía que figurar entre los primeros 200 pares en conectarse. La vulnerabilidad, de gravedad media, se corrigió en Bitcoin Core 0.21.0.
Abrir un enlace de pago BIP72 malicioso podía hacer caer Bitcoin-Qt: su parámetro r podía apuntar a un archivo enorme, y la aplicación intentaba reservar memoria para él mientras la descarga seguía en silencio en segundo plano. El fallo, de gravedad media, desapareció cuando #17165 eliminó el soporte de BIP70, incluido en 0.20.0.
Transacciones huérfanas manipuladas, inválidas pero costosas de validar, podían bloquear un nodo durante horas, porque cada transacción recién aceptada desencadenaba una búsqueda cuadrática en la caché de huérfanas. #15644, de Pieter Wuille, interrumpe ese trabajo para atender mensajes nuevos en cuanto aparece una coincidencia. La corrección de este fallo de gravedad alta llegó a los usuarios con Bitcoin Core 0.18.0.
Un mensaje GETDATA mal formado podía dejar el hilo net_processing girando al 100 % de CPU en versiones de Bitcoin Core anteriores a 0.20.0, con 1,5 MB más de memoria por cada par atacante. Los demás pares seguían recibiendo servicio, de ahí la gravedad baja. John Newbery encontró el fallo y lo corrigió en #18808.
Las cabeceras construidas directamente sobre el bloque génesis, que solo necesitaban dificultad 1, se saltaban la lógica de checkpoints desde Bitcoin Core 0.12.0 hasta 0.15.0, de modo que un atacante con spam podía hacer crecer mapBlockIndex sin límite y quizá dejar el nodo sin memoria. Cory Fields notificó este fallo de gravedad media en 2017, y #11028 lo cerró.
Un solo INV con 50.000 elementos de bloque podía obligar a un nodo a poner en cola 50.000 respuestas getheaders de alrededor de 1 kB cada una, y un par que se negara a leerlas mantenía lleno ese búfer de envío de 50 MB. #18962, de John Newbery, presentado como un ahorro de ancho de banda, pasó a enviar un GETHEADERS por INV y salió en 0.20.0.
Callar las respuestas GETDATA y luego inundar con anuncios falsos para expulsar una transacción del mapa g_already_asked_for, de 50.000 entradas, permitía a un atacante volver a anunciarla una y otra vez e impedir que la víctima la pidiera a nadie más. John Newbery reveló el fallo, de gravedad media; #19988, de Pieter Wuille, lo corrigió en Bitcoin Core 0.21.0.
Un segundo desbordamiento de búfer en miniupnpc, descubierto por Wladimir J. Van Der Laan, filtraba datos y podía encadenarse con CVE-2015-6031 para lograr ejecución remota de código, como él mismo demostró con el miniupnpc 1.6-precise de Ubuntu. Su exploit no se trasladaba directamente a Bitcoin Core, y la versión 0.12 incluyó la corrección en febrero de 2016.
Bitcoin Core 27.1 viene lleno de correcciones: se repara el aumento de comisión de la GUI para transacciones sin firmar, su campo de IP del proxy deja de aceptar un puerto y GetAddedNodeInfo() ya detecta los pares CJDNS de addnode (#30085). También cambia el tratamiento de TapMiniscript al firmar (#29853).
El transporte v2 de BIP324 se activa por defecto en Bitcoin Core 27.0, y el nuevo algoritmo CoinGrinder busca el conjunto de entradas más ligero con comisiones de 30 sat/vB o más. El tiempo ajustado por la red abandona el código de consenso en favor de la hora del sistema, así que a los operadores les importa más tener el reloj en hora. libbitcoinconsensus queda obsoleta y su retirada está prevista para v28.
Los nodos con Bitcoin Core 25.2 dejan de procesar bloques mutados (#29412). Además, la actualización corrige un segfault en getrawtransaction (#29003), un use-after-free en WalletBatch::EraseRecords (#29176) y un cierre inesperado de la GUI al seleccionar «Mask values».
Las sesiones I2P de Bitcoin Core 26.1 usan cifrado ECIES-X25519 y ElGamal (#29200), y el nodo ya registra el progreso mientras carga la mempool. Entre las correcciones figuran el rechazo a procesar bloques mutados (#29412) y un monedero que se salta la selección de monedas BnB con SFFO activado (#28994).
El transporte v2 experimental de BIP324 se estrena en Bitcoin Core 26.0, desactivado por defecto y disponible con -v2transport. Un nuevo RPC, loadtxoutset, carga instantáneas de assumeutxo y deja un nodo utilizable en minutos mientras el chainstate original termina de validarse en segundo plano, y submitpackage envía transacciones en crudo a la mempool como paquete.
Bitcoin Core 24.2 ya no sirve estimaciones de comisiones caducadas (#27622) y corrige cómo trata el RPC las direcciones bech32 inválidas (#27727). Casi todo lo demás afecta al sistema de compilación y a la CI, con una corrección para compilar el paquete Qt de macOS con el enlazador de Xcode 15 (#28543).
La descarga en paralelo de bloques compactos llega con Bitcoin Core 25.1 (#27626). Otras correcciones afectan a una caída de REST en /deploymentinfo (#27853), al apagado del servidor tras desconectarse un cliente remoto (#28551) y a la migración de monederos, que ya rechaza scripts inválidos (#28125).
Los reescaneos de monederos de descriptores se aceleran en Bitcoin Core 25.0 cuando hay filtros de bloques compactos BIP158 disponibles con -blockfilterindex=1, y un nuevo RPC, scanblocks, busca en ellos. La política de retransmisión acepta ahora transacciones a partir de 65 bytes sin witness. Con -blocksonly, la memoria máxima de la mempool baja de 300 MB a 5 MB.
Tres cambios de P2P marcan Bitcoin Core 23.2: se acabó la corrupción de peers.dat (#26909), no se borra antes de tiempo el estado de descarga de otros pares (#27608) y las colas inv-to-send van más rápidas (#27610). El resto es trabajo de compilación y CI, como compilar bdb con clang-16 en aarch64.