Más allá de la caída ya pública, CVE-2018-17144 permitía a un minero inflar la oferta de bitcoin en las versiones 0.15.X a 0.16.2 gastando una salida dos veces dentro de una misma transacción. Los desarrolladores se guardaron esa parte para dar tiempo a pasar a 0.16.3 o 0.17.0rc4. Se cree que más de la mitad del hashrate ya está parcheado, no se conocen intentos de explotación y se insta a los usuarios afectados a actualizar.
CVE-2018-17144 hace que Bitcoin Core, de 0.14.0 a 0.16.2, se caiga ante un bloque con una transacción que gasta dos veces la misma entrada, y se pide a los usuarios que actualicen de inmediato a 0.16.3. Solo un minero dispuesto a renunciar a al menos 12,5 BTC en ingresos permitidos podría generar un bloque así.
El RPC verifytxoutproof de Bitcoin Core 0.16.2 ya no cae ante un ataque costoso a las pruebas SPV revelado a principios de junio, aunque los clientes SPV reales siguen expuestos. Otra corrección hace que abandontransaction descarte todos los descendientes de una transacción en lugar de detenerse en sus hijas.
Bitcoin Core 0.16.1 deja de retransmitir OP_CODESEPARATOR en scripts de firma legacy, un cambio de política que facilita desplegar futuras correcciones para bloques lentos de validar. Los mineros pierden la opción -blockmaxsize en favor de -blockmaxweight y reciben la corrección de un fallo que podía costarles ingresos al producir dos bloques en rápida sucesión.
Segwit pasa a ser la opción predeterminada del monedero en Bitcoin Core 0.16.0: las direcciones nuevas son p2sh-segwit salvo que -addresstype indique otra cosa, y se pueden generar y pagar direcciones nativas bc1 según BIP173. Los monederos nuevos son solo HD y las versiones anteriores los rechazan, mientras que la pantalla de envío de la GUI activa ahora por defecto RBF de BIP125.
Como precaución ante futuras bifurcaciones de la red, Bitcoin Core 0.15.1 expulsa durante la sincronización inicial a los pares que ofrecen una cadena por debajo de minimum-chain-work, igual que a los pares salientes que sirven cabeceras que se sabe inválidas. Una punta de cadena atascada 30 minutos provoca ahora una conexión saliente adicional. Los mineros pierden el uso directo de blockmaxsize, obsoleto y reducido a fijar implícitamente un límite de peso.
Un cierre inesperado de la GUI al arrancar motivó Bitcoin Core 0.15.0.1: algunos clientes que actualizaban a 0.15.0 se caían con un ajuste de comisión personalizado que la interfaz ya no ofrece. Un parche mínimo, #11332, trata ese valor inválido.
Las estimaciones de comisiones de Bitcoin Core 0.15.0 llegan a 1008 bloques vista, frente a los 25 anteriores, y en la GUI se puede subir la comisión de una transacción sin confirmar con Replace-By-Fee. Una base de datos de chainstate por salida acelera entre un 30 y un 40 % la descarga inicial de bloques. La conversión se hace sola en el primer arranque y tarda entre 5 y 30 minutos, aproximadamente.
Los colaboradores habituales de Bitcoin Core no tienen ningún vínculo con btc1, la implementación de Segwit2x, y el proyecto rechaza que sea una actualización necesaria: la califica de ruptura polémica de las reglas de la red. Segwit, el soft fork previsto para dentro de unos días, nada tiene que ver con ese hard fork y no exige nada a la mayoría de los usuarios. El comunicado advierte además de que Segwit2x no prevé una protección fuerte contra replay.
Quien haya activado UPnP debe instalar Bitcoin Core 0.14.2 sin demora: un error de signo de entero en el miniupnpc incluido, CVE-2017-8798, permite a atacantes de la red local provocar una denegación de servicio u otros posibles daños. UPnP sigue desactivado por defecto, de modo que los nodos que nunca lo encendieron no se ven afectados.
Los mineros sin segwit pueden seguir usando getblocktemplate tras la activación, porque Bitcoin Core 0.14.1 quita las transacciones segwit de la plantilla. El -dbcache predeterminado pasa a 450 MiB y el límite se respeta también en los picos de volcado. Los argumentos renombrados de createrawtransaction y disconnectnode rompen las llamadas que usan argumentos con nombre de 0.14.0.
El monedero de un nodo nuevo podría enviar y recibir antes de terminar la sincronización con el modo híbrido SPV de bloque completo que figura en la hoja de ruta de Bitcoin Core: descarga primero los bloques a partir de la clave más antigua del monedero mientras la validación completa sigue en segundo plano. Desaparecen las filtraciones de privacidad de los filtros Bloom a cambio de más ancho de banda, y los pagos deberían esperar a 6 o más confirmaciones.
Cambiar ECDSA por firmas Schnorr reduciría un multifirma 50 de 50 al tamaño de un gasto con una sola clave y ocultaría su política a los observadores. La hoja de ruta de Bitcoin Core señala como principal obstáculo la cancelación, en la que un firmante malicioso resta la clave de otro usuario. La deslinearización responde a ese ataque, aunque su prueba de seguridad sigue en revisión por pares.
La caché de firmas de Bitcoin-Qt 0.7.0, Ultraprune con LevelDB en 0.8.0 y la sincronización headers-first de Bitcoin Core 0.10 protagonizan la primera parte de un repaso a las mejoras de velocidad del software de referencia. Solo la verificación de scripts en paralelo aportó entre un 35 % y un 100 % en las pruebas de los desarrolladores.
Los nodos nuevos completaron la descarga inicial de bloques 5,7 veces más rápido con Bitcoin Core 0.14.0 que con 0.13.2 en una prueba en Amazon EC2 con la configuración predeterminada: 6 horas y 24 minutos frente a 1 día, 12 horas y 40 minutos. Detrás de esa ganancia están los bloques assumed valid y la memoria compartida entre la mempool y la caché de UTXO. Los monederos estrenan además un aumento de comisión opcional, desactivado por defecto.
Los envíos del monedero que topan con el límite de cadenas sin confirmar ya no devuelven un error de RPC en Bitcoin Core 0.13.2. Se notifican como correctos, y la inserción en la mempool se reintenta al retransmitir, sin necesidad de reiniciar. Se desactivan las estimaciones de comisión para un objetivo de 1 bloque y se corrige el tratamiento de los bloques compactos inválidos.
Envolver segwit en P2SH es lo que más bytes cuesta: un 19 % extra para P2WSH/P2SH y un 11 % para P2WPKH/P2SH en una transacción de 180 bytes, según el recuento de Bitcoin Core sobre lo que traería BIP141. La validación necesita unos cinco hashes SHA256 más por transacción. Los fallos, los bloques más grandes y las comisiones más bajas se sopesan como riesgos, y los autores no toman partido sobre la activación.
Los mineros ya tienen código para señalizar el soft fork de segwit en Bitcoin Core 0.13.1, con la señalización abierta desde el 15 de noviembre de 2016, al empezar el siguiente periodo de reajuste. El lock-in requiere el 95 % de los bloques en un periodo de 2016, y la activación llega un periodo después. Los monederos siguen siendo compatibles, así que quizá solo tengan que actuar los mineros.
Segwit necesita el respaldo de dos grupos: mineros que señalicen el bit 1 en el 95 % de los bloques de un periodo de reajuste y suficientes nodos completos con Bitcoin Core 0.13.1 o una implementación compatible. La señalización se abre en el primer reajuste que caiga a partir del 15 de noviembre de 2016. Hay pasos específicos para mineros, operadores de nodos, usuarios de monederos y desarrolladores, también para quienes decidan no actualizar.
El código de segwit llega con Bitcoin Core 0.13.0, pero sigue inactivo en mainnet; para usarlo allí hará falta una versión posterior, previsiblemente 0.13.1. La retransmisión de bloques compactos (BIP152) reduce los picos de ancho de banda, y los monederos nuevos usan claves HD de BIP32, de modo que una sola copia de seguridad cubre todas las claves privadas futuras. Las compilaciones para Linux ARM se suman además a las descargas oficiales.