Por Canuto  

Bitcoin Core v30.0 ya está disponible: trae cambios en políticas de tarifas, límites de firma, nuevas herramientas de línea de comandos, mejoras de red y de seguridad, además de la eliminación de soporte para billeteras BDB y varias RPC heredadas.
***

  • Versión disponible: Bitcoin Core v30.0, con binarios en https://bitcoincore.org/bin/bitcoin-core-30.0/ y avisos de seguridad en la nota de lanzamiento.
  • Cambios importantes: límite de opsig a 2500, datacarriersize por defecto 100.000, nuevos feerates mínimos y nueva herramienta “bitcoin” con soporte IPC experimental.
  • Billeteras y RPC: no se cargan ni crean billeteras BDB; RPCs legacy eliminadas; cinco vulnerabilidades de baja severidad corregidas en 30.0.

Bitcoin Core v30.0 ya está disponible según la nota de lanzamiento publicada por Bitcoin Core en bitcoincore.org. Los binarios pueden descargarse desde https://bitcoincore.org/bin/bitcoin-core-30.0/ y el código fuente permanece en el repositorio oficial del proyecto.

La publicación oficial advierte que las versiones 27.x y anteriores han alcanzado el Fin de Mantenimiento y dejarán de recibir actualizaciones.

Además, la política de divulgación de seguridad del proyecto indica que en dos semanas se divulgarán vulnerabilidades corregidas: no hay vulnerabilidades de severidad media o alta en la versión 28.0, y en la 30.0 se corrigieron 5 vulnerabilidades de severidad baja.

La nota de lanzamiento pide a los usuarios reportar errores en el rastreador de issues de GitHub y sugiere suscribirse a la lista de anuncios para recibir notificaciones de seguridad y actualizaciones. Toda la información técnica y los números de referencia en esta crónica proceden de la propia nota de lanzamiento de Bitcoin Core.

Para lectores que se inician en el tema: Bitcoin Core es la implementación de referencia del protocolo Bitcoin. Actualizaciones mayores como esta afectan a validación, mempool, RPC, billetera y herramientas de minado, por lo que requieren una revisión cuidadosa antes de desplegarse en nodos en producción.

En este artículo sintetizamos las novedades más relevantes, explicamos cómo actualizar y analizamos las implicaciones para operadores de nodos, mineros y usuarios de billeteras.

Cómo actualizar y requisitos de compatibilidad

Actualizar a Bitcoin Core 30.0 implica cerrar la instancia actual y ejecutar el instalador en Windows, copiar la aplicación en macOS o reemplazar los ejecutables bitcoind/bitcoin-qt en Linux. La nota oficial explica que el cierre completo del proceso puede tardar varios minutos en algunos casos.

Actualizar directamente desde versiones en Fin de Vida es posible, pero puede demorar más si se requiere migración del directorio de datos. La herramienta y las RPC de migración siguen soportando versiones antiguas de billeteras para facilitar la transición.

Bitcoin Core 30.0 es compatible y probado en sistemas que emplean el kernel de Linux 3.17+, macOS 13+ y Windows 10+. Aunque el software puede ejecutarse en otros sistemas tipo Unix, no se recomienda su uso fuera de las plataformas soportadas regularmente.

Antes de actualizar, los operadores deben verificar opciones de configuración personalizadas que puedan quedar obsoletas. La nota señala, por ejemplo, que la opción -maxorphantx ha dejado de tener efecto y debería eliminarse de las configuraciones para evitar errores en futuras versiones.

Se recomienda hacer copias de seguridad del datadir y de las billeteras antes de la actualización y revisar la lista de cambios de índices y registros, ya que algunas transformaciones requieren resíncronización o limpieza manual de directorios antiguos.

Cambios en políticas, tarifas y mempool

Una modificación importante en la política limita a 2500 el número máximo de operaciones de firma legadas potencialmente ejecutadas en una sola transacción estándar.

El conteo incluye operaciones de todos los scripts de salida anteriores, scripts de entrada y scripts de canje P2SH si existen. Bitcoin Core indica que el nuevo límite no debería afectar transacciones estándar típicas, y fue introducido para prepararse ante un posible despliegue de BIP54 (#32521).

La opción -datacarriersize se incrementa por defecto a 100.000, lo que efectivamente elimina el límite práctico anterior dado que el tamaño máximo de transacción será el factor limitante. Los usuarios que deseen el comportamiento previo pueden restablecer -datacarriersize=83.

Además, ahora se permiten múltiples salidas de data carrier (OP_RETURN) en una misma transacción para reenvío y minería, sujetas al límite agregado indicado por -datacarriersize (#32406).

Los feerates mínimos también cambian: el feerate mínimo de bloque -blockmintxfee se ajusta a 0.001 satoshis por vB, y los feerates mínimos de reenvío -minrelaytxfee y -incrementalrelayfee se establecen en 0.1 satoshis por vB por defecto.

Bitcoin Core advierte que, a menos que estos valores más bajos se adopten ampliamente en la red, las transacciones creadas con tarifas reducidas podrían no propagarse ni confirmarse; las tarifas de la billetera permanecen sin cambios y debe ajustarse -mintxfee para crear transacciones con tarifas menores usando la billetera (#33106).

En cuanto al mempool y el reenvío de paquetes, se mejoró el reenvío oportunista 1 padre – 1 hijo para manejar situaciones con padres no confirmados y topologías más amplias. La zona de transacciones huérfanas recibió protecciones ante ataques de denegación de servicio: ahora los límites se calculan en función del número y peso de entradas únicas, con reglas que fijan topes como 3.000 en recuento de entradas y 404.000 Wu multiplicado por el número de pares para el peso, reemplazando el antiguo -maxorphantx (#31385, #31829).

Nuevas herramientas, IPC de minería y cambios en índices y registro

Se añadió un nuevo comando de línea llamado bitcoin que actúa como wrapper para invocar otros ejecutables: “bitcoin node” equivale a bitcoind, “bitcoin gui” a bitcoin-qt y “bitcoin rpc” a bitcoin-cli -named. El comando facilita el descubrimiento de funciones sin reemplazar las utilidades previas (#31375).

La herramienta bitcoin también habilita una interfaz de minería IPC experimental. Al iniciar el nodo con bitcoin -m node -ipcbind=unix, el proceso escuchará un socket Unix para permitir clientes IPC (p. ej. Stratum v2) que soliciten plantillas de bloques y envíen bloques minados. Esta funcionalidad añade dependencias que pueden desactivarse en compilación con -DENABLE_IPC=OFF. Actualmente la opción -m inicia un binario interno nuevo bitcoin-node y es obligatoria, aunque se espera que sea opcional en el futuro (#31098, #31802).

En la instalación, varios binarios de prueba y soporte ahora se instalan en libexec/ en lugar de bin/, y pueden invocarse a través del nuevo comando bitcoin. En Windows el instalador ya no añade el sufijo “(64-bit)” en el menú Inicio y elimina artefactos obsoletos durante actualizaciones (#31679, #32132, #33422).

La implementación de coinstatsindex se cambió para evitar un fallo de desbordamiento observado en Signet; la nueva versión del índice debe sincronizarse desde cero y se almacena en /indexes/coinstatsindex/. La versión antigua se mantiene para soportar posibles downgrades, aunque puede eliminarse manualmente si no se planea volver atrás (#30469).

Respecto al registro, el registro incondicional en disco se limita ahora a una cuota de 1MiB por hora por ubicación de origen. Cuando -logsourcelocations está habilitado, la salida de log incluye la firma completa de la función en lugar del nombre corto, y los registros suprimidos se indicarán con un prefijo [*] si procede (#32604).

RPCs, wallet y cambios en la GUI

Bitcoin Core 30.0 depreca la opción de inicio -paytxfee y la RPC settxfee, planeando su eliminación en la versión 31.0. El proyecto aconseja confiar en la estimación de tarifas o especificar fee_rate por transacción en RPCs como fundrawtransaction, sendtoaddress, send, sendall y sendmany (#31278).

Se introdujeron múltiples cambios en RPCs: descriptors con espacios en claves públicas dentro de fragmentos ahora devuelven error; submitpackage ya no exige que todos los padres no confirmados estén presentes; waitfornewblock acepta un argumento opcional current_tip y deja de estar oculta. Además, psbtbumpfee y bumpfee permiten sustitución bajo fullrbf sin requerir señalización BIP-125 (#31603, #31385, #30635, #31953).

Las respuestas de validación de scripts cambiaron su prefijo a block-script-verify-flag-failed y mempool-script-verify-flag-failed para distinguir errores de bloque y mempool. getmininginfo ahora devuelve blockmintxfee, y getmempoolinfo incluye permitbaremultisig y maxdatacarriersize para reflejar configuraciones relevantes (#33183, #33189, #29954).

Para la billetera, las billeteras heredadas BDB ya no pueden crearse ni cargarse; deben migrarse al formato descriptor usando la RPC migratewallet. Esto permitió eliminar opciones redundantes en bitcoin-wallet y suprimir una larga lista de RPCs legacy-only: addmultisigaddress, dumpprivkey, dumpwallet, importaddress, importmulti, importprivkey, importpubkey, importwallet, newkeypool, sethdseed y upgradewallet (#32944, #28710, #32438, #31250).

La billetera añadió soporte para gastar y crear transacciones TRUC, aplicando las reglas de política TRUC y evitando mezclar UTXOs TRUC con UTXOs de otras versiones. Asimismo, se eliminaron parámetros y campos relacionados con watchonly: include_watchonly y iswatchonly ya no existen en RPCs. getwalletinfo pierde los campos balance, immature_balance y unconfirmed_balance; getunconfirmedbalance se eliminó y se recomienda consultar getbalances para balances sin confirmar (#32896, #32618, #32721).

En la GUI, la migración a Qt 6 introduce soporte de modo oscuro en Windows y uso del backend Metal en macOS. Como detalle de usabilidad, algunos anchos de columna personalizados en la pestaña Transacciones se han restablecido tras la eliminación de billetera heredada (#30997, #32459).

Finalmente, la versión añade un nuevo endpoint REST /rest/spenttxouts/BLOCKHASH para obtener salidas gastadas de manera eficiente usando datos de deshacer del bloque, y limita parámetros de inicio como -maxmempool y -dbcache en sistemas de 32 bits a 500MB y 1GiB respectivamente (#32540, #32530).

Implicaciones para operadores y usuarios; créditos

Las implicaciones son múltiples: operadores de nodos deben evaluar la necesidad de resíncronizar índices como coinstatsindex y revisar opciones obsoletas en sus configuraciones. Mineros y pools que adopten IPC experimental podrán integrar Stratum v2 u otro software cliente, pero deben planear cambios en la compilación si no requieren IPC.

Los administradores de infraestructura deben prestar atención a los nuevos feerates mínimos por defecto y a la recomendación de usar fee_rate por transacción si se pretende pagar menos que las tarifas predeterminadas de la billetera. La adopción de los nuevos valores por la red en general determinará si las transacciones con tarifas más bajas se propagan de forma fiable.

Para desarrolladores y gestores de aplicaciones que usan RPCs, las deprecaciones y cambios de firma obligan a actualizar integraciones y a validar que descriptores y parámetros no incluyan espacios indebidos. Las modificaciones en nombres de errores y nuevos campos en respuestas requieren actualizaciones en la lógica de handling de errores.

La nota de lanzamiento agradece a un largo listado de contribuyentes por su trabajo directo en la versión. Entre los nombres mencionados están 0xb10c, amisha, Andrew Toth, Anthony Towns, Antoine Poinsot, Ava Chow, benthecarman, Brandon Odiwuor, brunoerg, Bue-von-hon, Bufo, Chandra Pratap, Chris Stewart, Cory Fields, Daniel Pfeifer, Daniela Brozzoni, David Gumberg, deadmanoz, dennsikl, dergoegge, enoch, Ethan Heilman, Eugene Siegel, Eunovo, Eval EXEC, Fabian Jahr, fanquake, Florian Schmaus, fuder.eth, furszy, glozow, Greg Sanders, Hao Xu, Haoran Peng, Haowen Liu, Hennadii Stepanov, Hodlinator, hoffman, ishaanam, ismaelsadeeq, Jameson Lopp, janb84, Jiri Jakes, John Bampton, Jon Atack, josibake, jurraca, kevkevin, kevkevinpal, kilavvy, Kristaps Kaupe, l0rinc, laanwj, leopardracer, Lőrinc, Luis Schwab, Luke Dashjr, MarcoFalke, marcofleon, Martin Zumsande, Matt Corallo, Matthew Zipkin, Max Edwards, monlovesmango, Murch, nai­yoma, nervana21, Nicola Leonardo Susca, Novo, pablomartin4btc, Peter Todd, Pieter Wuille, Pol Espinasa, Prabhat Verma, rkrux, Roman Zeyde, Ryan Ofsky, Saikiran, Salvatore Ingala, Sebastian Falbesoner, Sergi Delgado Segura, Shunsuke Shimizu, Sjors Provoost, stickies-v, stratospher, stringintech, strmfos, stutxo, tdb3, TheCharlatan, Tomás Andróil, UdjinM6, Vasil Dimov, VolodymyrBg, w0xlt, will, willcl-ark, William Casarin, woltx, yancy y zaidmstrr, además de todos los colaboradores de las traducciones en Transifex.

En síntesis, Bitcoin Core 30.0 proporciona múltiples mejoras y cambios estructurales que exigen lectura atenta de la nota de lanzamiento y pruebas en entornos controlados antes de desplegar la versión en nodos de producción.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados