Todo lo recopilado de fuentes oficiales.
141 publicaciones
FillBlock recibe dos correcciones de P2P en Bitcoin Core 29.2: una comprobación de mutación del witness (#32646) y otra de cabecera vacía antes de la llamada (#33296). Las comprobaciones TRUC ya no se aplican en las reorganizaciones (#33504), y getblock y getblockheader dejan de devolver el objetivo de la punta de la cadena (#33446).
Bitcoin Core
Los límites de OP_RETURN prácticamente desaparecen en Bitcoin Core 30.0: -datacarriersize pasa a 100.000 por defecto y una transacción puede llevar varias salidas de datos, aunque -datacarriersize=83 recupera el tope anterior. Las comisiones de retransmisión por defecto bajan a 0,1 satoshis por vB, las operaciones de firma legacy se limitan a 2500 por transacción estándar y un nuevo comando bitcoin envuelve los ejecutables existentes.
Bitcoin Core
El registro incondicional en disco se limita en Bitcoin Core 29.1 a 1 MiB por hora para cada punto de origen (#32604), y las transacciones estándar pueden incluir como máximo 2500 operaciones de firma legacy potencialmente ejecutadas. Las comisiones de retransmisión por defecto bajan a 100 satoshis por kvB, mientras que las compilaciones de 32 bits limitan -maxmempool a 500 MB y -dbcache a 1 GiB.
Bitcoin Core
Algo más de la mitad de los cambios de Bitcoin Core 28.2 tienen que ver con la compilación. Guix ya notariza el paquete de la app para macOS y firma todos los binarios de macOS y Windows (#31407), y depends recibe arreglos de compilación para libevent en NetBSD (#31500) y freetype con cmake (#32693).
Bitcoin Core
Treinta y un colaboradores de Bitcoin Core firman una carta según la cual el software de nodo no debe negarse a retransmitir transacciones con demanda económica sostenida que llegan de forma fiable a los bloques, ya que usuarios y mineros pueden sortear esos filtros. Insisten en que eso no avala el uso para datos no financieros y en que solo los usuarios deciden qué software y qué políticas ejecutan.
Bitcoin Core
Años de spam continuo de addr podían desbordar el identificador de 32 bits del gestor de direcciones de Bitcoin Core y hacer caer el nodo; es lo que quedaba de un ataque que ya había frenado el límite de frecuencia de v22.0. La versión 29.0 pasa a un identificador de 64 bits y cierra CVE-2024-52919, de gravedad baja. Lo encontró Eugene Siegel y el cambio es de Martin Zumsande.
Bitcoin Core
Bitcoin Core 29.0 elimina el soporte de UPnP; -natpmp funciona ahora con una implementación propia de PCP y NAT-PMP en lugar de libnatpmp. El polvo efímero llega como nueva política, una corrección del peso de bloque reservado por duplicado añade -blockreservedweight y los nodos piden los padres que faltan a todos los pares que anunciaron un huérfano. Las versiones 26.x y anteriores alcanzan el fin de mantenimiento.
Bitcoin Core
Con -port configurado, Bitcoin Core 28.1 calcula el puerto de escucha onion predeterminado como ese puerto más uno, en vez de fijarlo en 8334 en mainnet, de modo que varios nodos locales vuelven a convivir sin chocar al arrancar. Quizá haya que cambiar las líneas HiddenServicePort escritas a mano en torrc. También se borran los datos secretos en DecodeExtKey (#31166).
Bitcoin Core
Un par que anuncia un bloque y luego se queda parado podía tener a un nodo de Bitcoin Core esperando hasta 10 minutos antes de probar en otro sitio, y un atacante podía repetir la jugada. CVE-2024-52922, de gravedad media, notificado y corregido por Greg Sanders, se mitiga en v25.1 y v26.0, que pueden pedir un bloque de inmediato a hasta 3 pares de bloques compactos de alto ancho de banda.
Bitcoin Core
La versión 27.2 de Bitcoin Core cierra una condición de carrera en la detección de autoconexiones (#30394) y corrige las llamadas a FillPSBT que devolvían complete=true por error (#30357). El hilo de carga de bloques y el planificador cambian su orden de cierre (#30435), y el código compila con miniupnpc 2.2.8 y GCC 15.
Bitcoin Core
Los bloques mutados de un par podían borrar el estado de descarga de otros pares que anunciaban el mismo bloque en Bitcoin Core anterior a v25.0, y el nodo olvidaba un bloque compacto que aún estaba reconstruyendo. Suhas Daftuar detectó el problema, y #27608 limita a cada par a su propio estado. CVE-2024-52921 tiene gravedad media.
Bitcoin Core
Los nodos con Bitcoin Core anterior a v25.0 podían caer en remoto con un mensaje blocktxn repetido para un mismo bloque, que hacía saltar una aserción según la cual FillBlock solo se ejecuta una vez. No hacía falta ninguna colisión de short-id: bastaba con incluir transacciones ausentes de la raíz de Merkle del bloque para llegar a la misma ruta. Niklas Gögge encontró y corrigió este fallo de gravedad alta, CVE-2024-35202.
Bitcoin Core
Un pico de actividad en la red a principios de mayo de 2023, agravado por nodos espía, ralentizó la propagación de bloques y transacciones, porque ordenar unos conjuntos inv-to-send sobredimensionados consumía casi todo el tiempo del hilo P2P. El problema, de gravedad media, se corrigió en Bitcoin Core v25.0 con #27610, que descarta antes las transacciones que ya no están en la mempool y vacía los conjuntos más deprisa a medida que crecen.
Bitcoin Core
Testnet4 (BIP94) llega con Bitcoin Core 28.0, junto con una retransmisión limitada de paquetes para parejas de un padre y un hijo, las transacciones TRUC estándar de BIP 431 y un nuevo tipo de salida Pay To Anchor. -mempoolfullrbf pasa a valer 1 por defecto, y libbitcoinconsensus desaparece tras quedar obsoleta en 27.0.
Bitcoin Core
Cadenas de cabeceras de baja dificultad podían tumbar en remoto nodos de Bitcoin Core anteriores a v24.0.1, y una sola cadena manipulada servía contra cualquier nodo de la red. La corrección de #25717 obliga al nodo a comprobar que una cadena acumula suficiente trabajo antes de guardarla, con lo que además deja de depender de los checkpoints frente a ataques conocidos. Gravedad: alta.
Bitcoin Core
Haciéndose pasar por un dispositivo UPnP en la red local, un atacante podía alimentar a un nodo de Bitcoin Core con respuestas M-SEARCH infladas hasta agotar su memoria. Solo corrían peligro los nodos iniciados con -miniupnp, ya que la biblioteca viene desactivada por defecto. El fallo, de gravedad baja, se corrigió en v22.0.
Bitcoin Core
El spam de mensajes addr podía hacer caer un nodo de Bitcoin Core: 2^32 inserciones en addrman desbordaban un contador de ID de 32 bits y hacían saltar una aserción. Eugene Siegel notificó este fallo de gravedad alta en 2021, y v22.0 incluye la corrección de Pieter Wuille.
Bitcoin Core
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.
Bitcoin Core
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.
Bitcoin Core
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.
Bitcoin Core
