BITCOIN OPTECH (05 de Julio, 2023). Bitcoin Optech Newsletter #258 | Traducción al español de IT4Bitcoin

 

Boletín Bitcoin Optech #258

05 de julio de 2023

Este boletín semanal incluye otro artículo de nuestra serie limitada sobre la política de la mempool, además de nuestras secciones regulares que anuncian nuevos lanzamientos y candidatos a lanzamiento, y describen cambios destacados en el software de infraestructura popular de Bitcoin.

Noticias

Esta semana no se encontraron noticias significativas en las listas de correo de Bitcoin-Dev y Lightning-Dev.

Esperando confirmación #8: Política como una interfaz

Una serie limitada semanal sobre la transmisión de transacciones, la inclusión en la mempool y la selección de transacciones para la minería, incluyendo por qué Bitcoin Core tiene una política más restrictiva que la permitida por el consenso y cómo las carteras pueden utilizar esa política de manera más efectiva.

Hasta ahora, en esta serie, hemos explorado las motivaciones y desafíos asociados con la transmisión descentralizada de transacciones, lo que ha llevado a la necesidad de reglas de validación de transacciones más restrictivas a nivel local y global que el consenso. Dado que los cambios en la política de transmisión de transacciones en Bitcoin Core pueden afectar si las transacciones de una aplicación se transmiten, requieren ser socializados con la comunidad de Bitcoin más amplia antes de ser considerados. Del mismo modo, las aplicaciones y los protocolos de segunda capa que utilizan la transmisión de transacciones deben ser diseñados teniendo en cuenta las reglas de política para evitar la creación de transacciones que sean rechazadas.

Los protocolos de contratación dependen aún más de las políticas relacionadas con la priorización, ya que la aplicabilidad en la cadena depende de poder confirmar rápidamente las transacciones. En entornos adversos, las contrapartes malintencionadas pueden tener interés en retrasar la confirmación de una transacción, por lo que también debemos pensar en cómo se pueden aprovechar las peculiaridades de la interfaz de política de transacciones en contra de un usuario.

Las transacciones de la Lightning Network cumplen con las reglas de estandarización mencionadas en publicaciones anteriores. Por ejemplo, el protocolo peer-to-peer especifica un «dust_limit_satoshis» en su mensaje «open_channel» para especificar un umbral de «dust» (cambio insignificante). Dado que una transacción que contiene una salida con un valor menor que el umbral de «dust» no se transmitirá debido a los límites de «dust» de los nodos, esos pagos se consideran «no exigibles en la cadena» y se eliminan de las transacciones de compromiso.

 Los protocolos de contratación a menudo utilizan rutas de gasto con bloqueo temporal para dar a cada participante la oportunidad de impugnar el estado publicado en la cadena. Si el usuario afectado no puede confirmar una transacción dentro de ese período de tiempo, puede sufrir una pérdida de fondos. Esto hace que las tarifas sean extremadamente importantes como mecanismo principal para aumentar la prioridad de confirmación, pero también más desafiantes. La estimación de la tasa de comisión se complica por el hecho de que las transacciones se transmitirán en algún momento desconocido posterior, los nodos a menudo operan como clientes ligeros y algunas opciones de aumento de tarifas no están disponibles. Por ejemplo, si un participante de un canal de LN se desconecta, la otra parte puede transmitir unilateralmente una transacción de compromiso prefirmada para liquidar la distribución de sus fondos compartidos en la cadena. Ninguna de las partes puede gastar unilateralmente el UTXO compartido, por lo que cuando una de las partes está desconectada, no es posible firmar una transacción de reemplazo para aumentar la tarifa de la transacción de compromiso. En su lugar, las transacciones de compromiso de LN pueden incluir salidas ancla para que los participantes del canal puedan adjuntar un hijo que aumente la tarifa en el momento de la transmisión.

Sin embargo, este método de aumento de tarifas también tiene limitaciones. Como se mencionó en una publicación anterior, agregar una transacción CPFP no es efectivo si las tarifas mínimas de la mempool aumentan por encima de la tarifa de la transacción de compromiso, por lo que aún deben firmarse con una tarifa ligeramente sobreestimada en caso de que las tarifas mínimas de la mempool aumenten en el futuro. Además, el desarrollo de las salidas ancla incluyó varias consideraciones debido a que una de las partes puede tener interés en retrasar la confirmación. Por ejemplo, una parte (Alice) puede transmitir su propia transacción de compromiso a la red antes de desconectarse. Si la tarifa de esta transacción de compromiso es demasiado baja para una confirmación inmediata y si la contraparte de Alice (Bob) no recibe su transacción, puede haber confusión cuando las transmisiones de su versión de la transacción de compromiso no se transmitan con éxito. Cada transacción de compromiso tiene dos salidas ancla para que cualquiera de las partes pueda usar CPFP en cualquiera de las transacciones de compromiso, por ejemplo, Bob puede intentar transmitir ciegamente un aumento de tarifa CPFP de la versión de Alice de la transacción de compromiso, incluso si no está seguro de que ella haya transmitido previamente su versión. Cada salida ancla se asigna un valor pequeño por encima del umbral de «dust» y puede ser reclamada por cualquiera después de cierto tiempo para evitar inflar el conjunto de UTXO.

Lanzamientos y candidatos a lanzamientos

 ● Core Lightning 23.05.2 es una versión de mantenimiento de este software de nodo LN que contiene varias correcciones de errores que pueden afectar a los usuarios en producción. Se recomienda considerar la actualización a esta nueva versión para aprovechar las mejoras y correcciones implementadas. También se anima a los usuarios a ayudar en la prueba de las versiones candidatas para garantizar la estabilidad y el rendimiento del software.

Cambios destacados en el código y la documentación