Bitcoin es una innovadora red de pagos y una nueva clase de dinero.
Bitcoin usa tecnología peer-to-peer o entre pares para operar sin una autoridad central o bancos; la gestión de las transacciones y la emisión de bitcoins es llevada a cabo de forma colectiva por la red.
Bitcoin es de código abierto; su diseño es público, nadie es dueño o controla Bitcoin y todo el mundo puede participar. Por medio de sus muchas propiedades únicas, Bitcoin permite usos interesantes no contemplados por ningún sistema de pagos anterior.
Que novedades incluye la versión 29.0 See changelog
Released
Cambios en P2P y Red
-
Se ha eliminado el soporte para UPnP. Si quieres abrir un puerto automáticamente, considera usar la opción -natpmp, que emplea PCP o NAT-PMP dependiendo del soporte del router. (#31130)
-
libnatpmp ha sido reemplazada por una implementación integrada de PCP y NAT-PMP (sigue habilitada mediante la opción -natpmp). Esto permite el reenvío automático de puertos IPv4 y también la apertura de huecos (pinholing) en IPv6. (#30043)
-
Cuando se utiliza la opción de configuración -port, el puerto por defecto para conexiones onion ahora se calculará como ese puerto + 1, en lugar de ser un valor fijo (8334 en la red principal). Esto permite de nuevo configuraciones con múltiples nodos locales usando distintos -port y sin -bind, lo cual provocaba un error de inicio en la versión 28.0 por colisión de puertos. Ten en cuenta que si tienes configurado manualmente un HiddenServicePort en el archivo torrc, es posible que necesites ajustarlo. Por ejemplo, si usas -port=5555 sin -bind=...=onion, antes Bitcoin Core escuchaba en 127.0.0.1:8334. Ahora escuchará en 127.0.0.1:5556. Deberías cambiar HiddenServicePort 8333 127.0.0.1:8334 por HiddenServicePort 8333 127.0.0.1:5556, o configurar bitcoind con -bind=127.0.0.1:8334=onion para mantener el comportamiento anterior. (#31223)
-
Al recibir una transacción huérfana (una transacción no confirmada que gasta entradas desconocidas), el nodo intentará descargar los padres faltantes desde todos los pares que anunciaron dicha transacción. Este cambio puede aumentar el uso de ancho de banda, pero mejora la fiabilidad del manejo de huérfanas. (#31397)
Cambios en Política del Mempool y Minado
-
El “dust efímero” es un nuevo concepto que permite una única salida de tipo “dust” en una transacción, siempre que sea sin comisión. Para gastar cualquier salida no confirmada de dicha transacción, se debe gastar también este “dust”, junto con cualquier otra salida deseada. Es decir, este tipo de transacción debe incluirse en un paquete en el que el “dust” se cree y se gaste simultáneamente. (#30239)
-
Debido a un error, el peso reservado por defecto del bloque (4.000 WU) para la cabecera de tamaño fijo, recuento de transacciones y transacción coinbase se reservaba dos veces y no se podía reducir. Como resultado, el peso total reservado era siempre de 8.000 WU, lo que impedía alcanzar el peso máximo incluso especificando -blockmaxweight en su valor máximo (4.000.000 WU). La solución consolida la reserva y añade una nueva opción de inicio, -blockreservedweight, que especifica el peso reservado directamente. Su valor por defecto es 8.000 WU para mantener la compatibilidad, con un mínimo permitido de 2.000 WU. Si usas un valor menor, asegúrate de que el peso total de la cabecera, recuento y coinbase no lo exceda, o podrías minar bloques inválidos. (#31384)
RPCs Actualizados
-
La respuesta de testmempoolaccept ahora incluye un campo reject-details en algunos casos, similar a los mensajes de error completos de sendrawtransaction. (#28121)
-
Los bloques duplicados enviados con submitblock ahora conservarán sus datos incluso si fueron previamente eliminados por pruning. Si pruning está activado, esos datos se eliminarán más adelante cuando el archivo de bloque correspondiente sea seleccionado para ello. (#31175)
-
getmininginfo ahora devuelve nBits y el objetivo actual en el campo target. También añade un objeto next que muestra altura, nBits, dificultad y objetivo del siguiente bloque. (#31583)
-
getblock y getblockheader ahora también devuelven el objetivo actual en el campo target. (#31583)
-
getblockchaininfo y getchainstates ahora incluyen nBits y el objetivo actual en el campo target. (#31583)
-
Los campos curtime (BIP22) y mintime (BIP23) del RPC getblocktemplate ahora tienen en cuenta la corrección de desincronización horaria propuesta en BIP94 en todas las redes. Esto evita que mineros no actualizados generen bloques inválidos si dicha corrección se activa como softfork. (#31376, #31600)
Nuevos RPCs
-
getdescriptoractivity permite buscar toda la actividad de envío/recepción relacionada con un conjunto de descriptores dentro de un conjunto de bloques especificado. Se puede usar junto con scanblocks para reducir la necesidad de indexación adicional. (#30708)
APIs REST Actualizadas
-
GET /rest/block/<BLOCK-HASH>.json y GET /rest/headers/<BLOCK-HASH>.json ahora devuelven el objetivo actual en el campo target.
Configuración Actualizada
-
Se ha eliminado el valor máximo permitido para la opción -dbcache debido al crecimiento reciente del conjunto UTXO. Antes, valores altos se reducían automáticamente a 16 GiB (1 GiB en sistemas de 32 bits). (#28358)
-
El manejo de las opciones negadas como -noseednode, -nobind, -norpcbind, etc., ha cambiado. Ahora, al negarlas simplemente se restauran los valores por defecto, sin efectos secundarios inesperados.
-
Desde la versión 28.0, la opción de inicio -mempoolfullrbf se establece por defecto en 1. Dado que esta política está ya ampliamente adoptada, se ha eliminado la opción, haciendo de replace-by-fee completo el comportamiento estándar. (#30592)
-
Establecer -upnp ahora mostrará una advertencia y se interpretará como -natpmp. Se recomienda usar directamente -natpmp. (#31130, #31916)
-
Como medida de seguridad, Bitcoin Core no arrancará si el parámetro -blockreservedweight es inferior a 2000 WU o si -blockmaxweight o -blockreservedweight superan el límite de consenso de 4.000.000 WU.
-
Pasar -debug=0 o -debug=none ahora se comporta como -nodebug: se eliminan las categorías de depuración previas, pero las siguientes opciones -debug seguirán aplicándose.
-
El valor por defecto de -rpcthreads ha pasado de 4 a 16, y el de -rpcworkqueue de 16 a 64. (#31215)
Sistema de Compilación
-
El sistema de compilación ha migrado de Autotools a CMake:
-
La versión mínima requerida de CMake es 3.22.
-
No se permiten compilaciones dentro del mismo directorio fuente.
-
Se recomienda que los subdirectorios de compilación contengan la palabra “build”.
-
Algunas variables por defecto han cambiado (por ejemplo, ahora se necesita -DWITH_ZMQ=ON para compilar con ZMQ y -DBUILD_GUI=ON para incluir bitcoin-qt).
-
El tipo de compilación por defecto para generadores de configuración única es “RelWithDebInfo”. En el modo “Release”, CMake usa -O3, pero esto se sustituye por -O2 por estabilidad.
-
Los ejecutables y librerías generados se ubican por defecto en bin/ y lib/ dentro del directorio de compilación.
-
Se admite instalación por componentes, coincidiendo el nombre del componente con el del objetivo de compilación (por ejemplo, bitcoind).
-
Si usabas variables como CPPFLAGS, CFLAGS, etc., con Autotools, deberías usar las correspondientes de CMake (APPEND_CPPFLAGS, etc.). Si usas las variables CMAKE_<...>_FLAGS, asegúrate de que el comportamiento del compilador/enlazador sea el esperado.
-