Se lanzó una nueva versión del software original de Bitcoin lanzado por Satoshi Nakamoto en 2009.
112 desarrolladores trabajaron en Bitcoin Core 24.0 durante aproximadamente siete meses para traer mejoras tangibles a la billetera de Bitcoin Core, comunicaciones punto a punto (P2P), interfaz gráfica de usuario (GUI) y mucho más.
Este artículo explora algunos de los principales cambios.
Actualizaciones de Wallet
Soporte inicial de Miniscript
Bitcoin Core 24.0 está introduciendo soporte para Miniscript al extender el descriptor de salida wsh(). Si bien es una integración inicial y rudimentaria, el movimiento allana el camino para implementar secuencias de comandos más complejas en Bitcoin de una manera más simple y segura.
Miniscript se puede considerar como un marco (o plantilla) para Bitcoin Script, el lenguaje de programación nativo de Bitcoin. Bitcoin Script es responsable de habilitar todas las funciones de programación disponibles para Bitcoin, incluida, por ejemplo, la que quizás sea la más simple de ellas: determinar quién puede gastar una moneda determinada. Para cada transacción de Bitcoin, el remitente solicita la dirección del destinatario y, con esa información, construye un script que bloquea el envío de Bitcoin de manera que solo el destinatario pueda gastarlo. Si bien es bastante fácil construir scripts simples como el anterior con Bitcoin Script, cuanto más complejo se vuelve el script, mayor es la posibilidad de error humano. Aquí es donde entra en juego Miniscript.
Miniscript permite escribir un subconjunto de Bitcoin Scripts de forma estructurada. Permite el análisis, la composición y la firma genérica, entre otras cosas, lo que permite que los desarrolladores escriban scripts avanzados de forma más segura. En otras palabras, Miniscript”contiene”alguna funcionalidad de Bitcoin Scripts preestablecidos para un patrón de comportamiento esperado, lo que limita los riesgos eventuales a medida que se minimiza el comportamiento inesperado. En la práctica, proporciona una”caja de herramientas”para que los desarrolladores jueguen y creen scripts avanzados y complejos para Bitcoin en lugar de tener que hacerlo todo manualmente a través de Bitcoin Script.
A partir de Bitcoin Core 24.0, los usuarios ahora pueden cree una billetera que contenga un script Miniscript, cree direcciones para esa billetera y fináncielas con bitcoin. Sin embargo, el monedero Bitcoin Core aún no admite el gasto de esas direcciones, lo que significa que, por el momento, los monederos habilitados para Miniscript en Bitcoin Core son solo de visualización.
Transacciones sin cambios
Se ha introducido un nuevo RPC, sendall, que permite a los usuarios gastar en su totalidad salidas de transacciones específicas no gastadas (UTXO). La RPC enviará el importe retenido en las UTXO especificadas a uno o más destinatarios sin generar cambio. (De forma predeterminada, sendall gastará cada UTXO en la billetera).
Este comportamiento puede ser deseable en algunas situaciones. Primero, naturalmente, el usuario podría querer vaciar su billetera. Llamar al nuevo RPC con configuraciones predeterminadas hará precisamente eso de una manera fácil. En segundo lugar, es posible que el usuario desee mejorar su privacidad renunciando al cambio.
Cambiar direcciones son complicados porque los usuarios a menudo pierden la noción de dónde se originaron y, como tales, pueden mezclarlos con otros UTXO como entradas en una transacción futura. Esto plantearía un problema de privacidad debido a la heurística de propiedad de entrada común, una premisa ampliamente utilizada en el análisis de la cadena que supone que todas las entradas en una transacción pertenecen al mismo usuario. En el ejemplo de salida de cambio, el usuario estaría haciendo ese enlace, arriesgándose efectivamente a una desanonimización de varias de sus monedas, ya que un analista de cadena podría agrupar algunas de las direcciones de ese usuario como una billetera.
Un inmutable El pago combate este problema al crear una transacción que gasta la totalidad de los UTXO seleccionados. Como no hay cambios, el usuario no puede cometer el error mencionado anteriormente. Además, un pago inalterable introduce una duda razonable a un analista de la cadena que se pregunta si la nueva salida es propiedad de la misma entidad que envió el pago (un mero movimiento de fondos a una nueva dirección) o si ahora es propiedad de un usuario diferente.
Cambiar la aleatorización de salida para evitar huellas dactilares
Como se explicó anteriormente, cambiar las salidas puede ser una fuga de privacidad. Si bien sendall mitiga por completo el uso de una dirección de cambio, en realidad habrá pocas ocasiones en las que el usuario posea una UTXO del tamaño exacto del pago que debe realizarse. Asegurarse de que un observador no pueda detectar cuál de las salidas es la dirección de cambio ayuda al usuario a ganar un poco de privacidad porque no será trivial vincular una dirección recién creada (salida de cambio) con la entrada gastada ahora para esa transacción..
Por lo general, cuando no hay una UTXO con el monto exacto del pago, la mayoría de las billeteras y los usuarios optan intuitivamente por la más cercana a ese número. Como consecuencia, un observador que observa la cadena de bloques puede ver qué salida es el pago (la más grande) y cuál es el cambio (la más pequeña). Esto genera muchos de los riesgos antes mencionados.
Para reducir la probabilidad de que un observador pueda identificar el resultado del cambio y agrupar las direcciones de los usuarios, Bitcoin Core ahora aleatoriza los valores del resultado del cambio.
Comenzando con la versión 24.0, la billetera Bitcoin Core elegirá un número aleatorio entre el tamaño del pago y tres veces el tamaño del pago. Este número informará su selección de UTXO para el gasto. Esto significa que a veces el algoritmo elegirá una UTXO cuyo valor esté más cerca del pago y otras veces seleccionará una UTXO cuyo valor esté más cerca del límite superior de tres veces el monto del pago. El primer escenario producirá el escenario típico de producción de cambio inferior al pago, mientras que el último producirá lo contrario: una producción de cambio que es mayor que el pago. Dado que no hay forma de que un observador de blockchain sepa cuándo ocurre cada escenario en un momento determinado, el usuario debería poder disfrutar de mayores garantías de privacidad.
Actualizaciones para reemplazar por tarifa
RBF proporciona opcionalidad para un usuario de Bitcoin cada vez que envía una transacción a la red. A menudo, un usuario no quiere pagar de más las tarifas de los mineros y, como tal, puede elegir un”término medio”entre la tarifa pagada y la velocidad a través de la cual la transacción se incluye en un bloque. Pero si el valor de la tarifa seleccionado por el usuario es demasiado bajo o el mempool está congestionado, la transacción podría tardar demasiado en incluirse en un bloque (o podría quedarse atascada en el mempool por completo). RBF permite al usuario”aumentar”la tarifa de su transacción en tal caso, lo que en la mayoría de los casos permite una liquidación más rápida.
Sin embargo, bajo el capó, RBF en realidad no aumenta la tarifa. Lo que sucede en segundo plano es que el cliente de software transmitirá una nueva transacción con las mismas entradas y la mayoría de las mismas salidas. (Algunos valores de salida cambian; el valor de la tarifa cambiará naturalmente para reflejar el nuevo número y, por lo general, esa diferencia se deduce de la cantidad que se enviaba a la dirección de cambio).
Históricamente, los nodos solo transmitían el primera versión de una transacción que vieron. Con el advenimiento de RBF, se introdujo un mecanismo para permitir a los usuarios señalar que estaban enviando una transacción que eventualmente podría recibir una reducción de tarifas, es decir, reemplazarse por una versión con una tarifa más alta. Esto sirvió como un aviso para los nodos, haciéndoles saber que las versiones de esa transacción con una tarifa más alta podrían enviarse en un momento posterior y que también deberían retransmitirse. Probablemente, la versión de la transacción con una tarifa más alta tenderá a ser más atractiva para los mineros y, como tal, se seleccionará primero. Una vez que eso suceda y se incluya en un bloque, la transacción de tarifa más baja se eliminará de los mempools de los nodos, ya que intentaría un doble gasto.
Bitcoin Core 24.0 presenta dos actualizaciones a la funcionalidad RBF.
Primero, ahora permite a los usuarios configurar sus nodos para transmitir transacciones reemplazables sin aplicar el indicador RBF. Esto se puede hacer a través de la nueva opción mempoolfullrbf. Estará desactivado de forma predeterminada, pero aquellos interesados en habilitarlo pueden activarlo.
En segundo lugar, RBF ahora está configurado como estándar en la billetera de Bitcoin Core. Las transacciones ahora optan por RBF de forma predeterminada y la opción de inicio-walletrbf está predeterminada en verdadero. Los usuarios pueden optar por no participar en RBF ajustando una transacción determinada en su proceso de creación o configurando la opción de inicio-walletrbf en falso.
Migración de billetera de descriptor
Bitcoin Core 23.0 hizo que las billeteras de descriptor sean las estándar. Los descriptores facilitan la vida del usuario al hacer una copia de seguridad de su billetera y luego restaurar esa copia de seguridad en un formato estándar.
Antes de que existieran los descriptores, los usuarios tenían que conocer la ruta de derivación de su billetera, que dicta cómo se deriva la clave maestra de la billetera. direcciones que se utilizarán para recibir y enviar bitcoins. Dado que las billeteras pueden tener diferentes rutas de derivación, no era suficiente que una copia de seguridad contuviera únicamente las frases iniciales. A veces, el usuario puede tener suerte e intentar restaurar una copia de seguridad con una billetera que aprovechó la misma ruta de derivación, pero dada la baja probabilidad de que eso suceda, sitios web completos se dedican a ayudar a los usuarios a descubrir qué ruta de derivación usar para billeteras antiguas y nuevas emergió.
El descriptor resuelve este problema al ser descriptivo sobre qué ruta de derivación usa la billetera respaldada, lo que mejora en gran medida la experiencia del usuario. La idea es que una copia de seguridad de la cartera del descriptor contenga toda la información necesaria para que cualquier cliente de software la restaure correctamente (siempre que el cliente esté habilitado para el descriptor).
Ahora, Bitcoin Core 24.0 presenta una nueva herramienta para migrar billeteras heredadas a un formato de billetera descriptor, lo que permite a los usuarios aprovechar este estándar emergente para proteger mejor su preciado bitcoin. Aunque todavía es experimental, se ha introducido un nuevo RPC (migratewallet). Este documento proporciona más detalles sobre su funcionalidad.
Cambios en la GUI
La GUI de Bitcoin Core ha sido conocida por no proporcionar el mismo nivel de funcionalidad que las llamadas a procedimientos remotos (RPC) y el comando. Las herramientas de línea pueden lograr. Bitcoin 24.0 está tomando algunas medidas para cambiar un poco eso.
La versión más reciente de Bitcoin Core trae un nuevo elemento de menú en la GUI que permite a los usuarios restaurar una billetera desde una copia de seguridad, lo que facilita que personas sin conocimientos técnicos restaurar copias de seguridad. Anteriormente, esta opción solo existía en la línea de comandos.
Otra deficiencia que tenía la GUI en comparación con la interfaz RPC estaba relacionada con la configuración del cliente Bitcoin Core. El famoso archivo bitcoin.conf es el santo grial de la configuración de Bitcoin Core, pero nuevamente, se puede modificar principalmente a través de la línea de comandos. Existía una opción para modificar la configuración en la GUI, pero una advertencia dejaba en claro que bitcoin.conf tenía prioridad sobre la GUI en caso de que tanto el archivo como la GUI intentaran establecer datos para la misma configuración. Por lo tanto, si bien la GUI proporcionó una opción simple para cambiar la configuración, el archivo de configuración seguía siendo la forma más confiable de personalizar el cliente Bitcoin Core.
Bitcoin Core 24.0 cambia eso. La nueva actualización unifica la página de configuración de la GUI con el archivo bitcoin.conf. Ahora, cuando un usuario abre la configuración del cliente en la GUI, la configuración que se muestra se extrae del archivo de configuración. De manera similar, los cambios de configuración realizados en la GUI ahora se reflejan en bitcoin.conf. (Vale la pena señalar que la relación allí es indirecta, porque los cambios en la GUI en realidad se establecen en settings.json, un archivo que tiene prioridad sobre bitcoin.conf.)
Cambios en las comunicaciones P2P
Nueva lógica para descargar encabezados
Bitcoin Core 24.0 trae una actualización de la forma en que los pares en la red alcanzan la punta de la cadena, ya sea porque están arrancando por primera vez o han pasado mucho tiempo sin conectarse a la red de Bitcoin.
Antes de este lanzamiento, un nuevo par que se unía a Bitcoin comenzaba a buscar pares desde los que descargar encabezados de bloque. El compañero no descarga bloques completos al principio porque tiene el incentivo de comprobar si está siguiendo la cadena correcta antes de descargar los bloques de esa cadena. De lo contrario, se corre el riesgo de descargar bloques para la cadena equivocada, lo que desperdicia recursos.
Si bien la descarga de encabezados ayuda a ahorrar tiempo y recursos, aún podría ocurrir un ataque de agotamiento de recursos donde un actor malicioso envía spam al par con millones de falsos encabezados de bloque. Dado que el cliente necesita descargar y guardar los encabezados en el disco, una cantidad de datos lo suficientemente grande podría paralizar el hardware del par.
Para mitigar esta amenaza, Bitcoin Core introdujo el concepto de puntos de control hace años. Los puntos de control determinan qué bloques deben estar presentes en una cadena para que sea válida. Sin embargo, esta solución también representa un problema, ya que se podría abusar de los puntos de control para hacer retroceder efectivamente la cadena más larga. Tal posibilidad no es deseable en Bitcoin, por lo que se tuvo que idear una solución diferente. Entra en esta nueva actualización.
Con Bitcoin Core 24.0, los pares ahora descargan encabezados de bloque dos veces. En la primera ejecución, los encabezados se descargan y descartan (no se guardan en el disco) hasta que se encuentra una cantidad suficiente de trabajo, lo que sugiere que la cadena que ha estado siguiendo el compañero es válida. En ese caso, el par luego reinicia el proceso, pero ahora, además de descargar, el par también guarda los encabezados de bloque en el disco. Al guardar los encabezados en el disco solo una vez que el par está seguro de que son parte de una cadena con una prueba de trabajo significativa, el par evita usar grandes cantidades de almacenamiento en un ataque eventual, como el agotamiento de recursos. Esto también elimina la necesidad de puntos de control y podría decirse que es una solución más elegante, ya que no depende del aporte humano para determinar la validez de la cadena.
Gracias a Aaron van Wirdum por sus comentarios.
Para obtener más detalles y otros cambios, consulte Bitcoin Core 24.0 notas de la versión. Para descargar Bitcoin Core 24.0, navega aquí. Los detalles sobre Bitcoin Core 24.0 también se explican en audio en el podcast Explicación de Bitcoin episode 65.