junio 24, 2021

Bitcoin Optech # 151: Selección de transacciones

El boletín Bitcoin Optech de esta semana describe una propuesta para cambiar el algoritmo de selección de transacciones de Bitcoin Core y más.

El boletín Bitcoin Optech proporciona a los lectores un resumen de alto nivel de las noticias técnicas más importantes sobre Bitcoin, junto con recursos que les ayudan a aprender más. Para ayudar a nuestros lectores a mantenerse al día con Bitcoin, volvemos a publicar el último número de este boletín a continuación. Recuerde suscribirse para recibir este contenido directamente en su bandeja de entrada.

El boletín de esta semana describe una propuesta para cambiar el algoritmo de selección de transacciones de Bitcoin Core para los modelos de bloques mineros para aumentar ligeramente la rentabilidad de los mineros y brindar a los usuarios que se benefician de tarifas adicionales un mayor apalancamiento colectivo. También se incluyen nuestras secciones regulares que describen lanzamientos de software y lanzamientos candidatos, así como cambios notables en el popular software de infraestructura de Bitcoin.

Nuevo

  • Construcción del modelo de bloques basado en el conjunto de candidatos (CSB): Mark Erhardt publicó en la lista de correo de Bitcoin-Dev un análisis que él y Clara Shikhelman realizaron sobre un algoritmo de selección de transacciones alternativo para mineros. Las reglas de consenso de Bitcoin dictan que no se puede incluir ninguna transacción en un bloque a menos que todos sus antepasados ​​no confirmados también se incluyan anteriormente en ese mismo bloque. Bitcoin Core aborda esta restricción al tratar cada transacción con antepasados ​​no confirmados como si contuviera tanto las tarifas como el tamaño de esos antepasados. Por ejemplo, si la transacción B depende de la transacción A no confirmada, entonces Bitcoin Core suma las tarifas pagadas por las dos transacciones y las divide por el tamaño combinado de las dos transacciones. Esto permite que Bitcoin Core compare de manera justa todas las transacciones en el grupo de memoria en función de su tasa efectiva, ya sea que esas transacciones tengan antepasados ​​o no. Sin embargo, Erhardt y Shikhelman señalan que un algoritmo más sofisticado que puede requerir un poco más de CPU puede encontrar conjuntos de transacciones vinculadas que son aún más rentables para minar que el algoritmo simple existente de Bitcoin Core. Los autores probaron su algoritmo con datos históricos de mempool y descubrieron que habría cobrado un poco más de tarifas que el algoritmo existente de Bitcoin Core en casi todos los bloques recientes. Si los mineros lo implementan y lo utilizan, el algoritmo mejorado podría permitir que varios usuarios, cada uno de los cuales recibió un resultado de una unión grande o un pago masivo, pagaran una pequeña parte de las tarifas totales necesarias para el aumento de las tarifas de CPFP en esa unión o pago. Esto sería una mejora con respecto al caso actual en el que el margen de tarifa de CPFP de cada usuario se considera de forma independiente y es posible que varios márgenes de tarifa asociados no tengan un efecto general en la obtención de una transacción anterior.

Liberar y liberar candidatos

Nuevas versiones y versiones candidatas para proyectos populares de infraestructura de Bitcoin. Considere actualizar a nuevas versiones o ayudar a probar versiones candidatas.

  • HWI 2.0.2 es una versión menor que agrega soporte para firmar mensajes con BitBox02, todavía usa h en lugar de ' a las rutas BIP32 indicadas con derivación reforzada e incluye varias correcciones de errores.
  • LND 0.13.0-beta.rc3 es un candidato de lanzamiento que agrega soporte para el uso de un nodo completo de Bitcoin podado, permite que los pagos se reciban y envíen usando Atomic MultiPath (AMP) y aumenta sus capacidades de PSBT, entre otras mejoras y correcciones de errores.

Cambios notables en el código y la documentación.

Cambios notables esta semana en Bitcoin Core, C-Lightning, Eclair, LND, Rust-Lightning, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, Bitcoin Improvement Proposals (BIP) y Lightning BOLT.

  • Bitcoin Core # 20833 es el primer PR en un esfuerzo por implementar la aceptación de paquetes mempool en Bitcoin Core. Este cambio permite testmempoolaccept RPC para aceptar múltiples transacciones donde las transacciones posteriores pueden derivarse de transacciones anteriores. Los PR futuros podrían permitir probar las cadenas de transacciones L2, enviar paquetes de transacciones directamente al grupo de memoria a través de RPC y comunicar paquetes a través de la red P2P.
  • Bitcoin Core # 22017 actualiza el certificado de firma de código utilizado para las versiones de Windows después de que el emisor revocara el certificado anterior sin proporcionar una razón explícita. Varias versiones recientes de Bitcoin Core podrían volver a publicarse con números de versión ligeramente diferentes para que sus binarios de Windows puedan usar este certificado.
  • Bitcoin Core # 18418 aumenta el número máximo de UTXO recibidos en la misma dirección que se gastarán simultáneamente si el avoid_reuse se fija el indicador de cartera. Cuanto mayor sea el número de salidas gastadas juntas, más altas se pueden comparar las tarifas con una billetera con métricas predeterminadas, pero también, es menos probable que terceros puedan identificar las transacciones posteriores del usuario.
  • C-Lightning # 4501 agrega esquemas JSON para la salida de aproximadamente la mitad de los comandos actuales de C-Lightning (y se espera que se agreguen esquemas para la otra mitad en el futuro). La salida producida durante una ejecución del conjunto de pruebas C-Lightning se valida con esquemas para garantizar la coherencia. Los esquemas también se utilizan para generar automáticamente documentación de C-Lightning sobre la salida producida por cada pedido.
  • LND # 5025 agrega soporte básico para usar el marcador. Entre otras implementaciones de LN rastreadas por Optech, C-Lightning también admite marcadores (consulte el boletín n. ° 117).
  • LND # 5155 agrega una opción de configuración para seleccionar aleatoriamente UTXO de billetera para gastar en una transacción; esto reduce la fragmentación de UTXO en la billetera con el tiempo. En contraste, el algoritmo de selección de monedas predeterminado en LND gasta UTXO de valor más alto antes que UTXO de valor más bajo; esto minimiza las tarifas a corto plazo, pero puede resultar en la necesidad de pagar tarifas más altas en el futuro cuando ya se hayan gastado todos los insumos cercanos al tamaño de la transacción, o más.
  • BOLT # 672 actualiza BOLT2 para permitir que los nodos negocien un option_shutdown_anysegwit opción que, si se establece, permite a LN cerrar transacciones para poder pagar cualquier versión del script segwit, incluidos los tipos de script que aún no tienen un significado consensuado en la red, como las direcciones de la raíz principal.
  • BOLTs # 872 actualiza el uso de BOLT3 de BIP69 para especificar aún más el orden de clasificación que se utilizará para las entradas y salidas de transacciones de confirmación. Un comentarista señala que el uso de BIP69 hasta ahora ha causado tres problemas separados que pueden haber llevado a cierres accidentales de canales y pequeñas pérdidas de fondos debido a cargos innecesarios en la cadena. El comentarista sugiere que esta es otra razón para alejarse del uso explícito de BIP69 (por otras razones, consulte el boletín # 19).

Encuentre el artículo original aquí.

Suscríbase directamente al boletín de Bitcoin Optech para recibir este contenido directamente en su bandeja de entrada cada mes.

Artículo publicado por primera vez en la revista Bitcoin