BITCOIN OPTECH (21 de Junio, 2023). Bitcoin Optech Newsletter #256 | Traducción al español de ConociendoCripto

 

Boletín Bitcoin Optech #256

junio 21, 2023

El boletín de esta semana resume una discusión sobre la ampliación de las facturas BOLT11 para solicitar dos pagos. También se incluye otra entrada en nuestra serie semanal limitada sobre la política de mempool, además de las secciones regulares que describen las actualizaciones de clientes y servicios, nuevos lanzamientos y candidatos a lanzamiento, y los cambios en el software de infraestructura de Bitcoin más popular.

Noticias

● Propuesta para ampliar las facturas BOLT11 y solicitar dos pagos: Thomas Voegtlin publicó en la lista de correo Lightning-Dev para sugerir que las facturas BOLT11 se amplíen para permitir opcionalmente que un receptor solicite dos pagos separados de un pagador, cada uno con un secreto y un monto diferentes. Voegtlin explica cómo esto podría ser útil tanto para los intercambios submarinos como para los canales JIT:

● Submarine swaps, donde pagar una factura LN fuera de la cadena resulta en recibir fondos en la cadena (los submarine swaps también pueden funcionar en sentido contrario, de la cadena a la cadena fuera de ella, pero eso no se está discutiendo aquí). El receptor de la cadena elige un secreto y el pagador fuera de la cadena paga un HTLC al hash de ese secreto, que se enruta a través de LN hacia un proveedor de servicios de submarine swaps. El proveedor de servicios recibe un HTLC fuera de la cadena para ese secreto y crea una transacción en la cadena que paga a ese HTLC. Cuando el usuario está seguro de que la transacción en la cadena es segura, revela el secreto para liquidar el HTLC en la cadena, lo que permite al proveedor de servicios liquidar el HTLC fuera de la cadena (y cualquier pago reenviado en LN que también dependa del mismo secreto).

Sin embargo, si el receptor no revela su secreto, entonces el proveedor de servicios no recibirá ninguna compensación y deberá gastar la salida en la cadena que acaba de crear, incurriendo en costos sin obtener beneficios. Para evitar este abuso, los servicios de submarine swaps existentes requieren que el pagador pague una tarifa utilizando LN antes de que el servicio cree una transacción en la cadena (el servicio puede optar por reembolsar parte o la totalidad de esta tarifa si se liquida el HTLC en la cadena). La tarifa inicial y el submarine swaps son de diferentes cantidades y deben liquidarse en momentos diferentes, por lo que necesitan usar secretos diferentes. Una factura BOLT11 actual solo puede contener un compromiso con un secreto y una cantidad, por lo que cualquier billetera que realice el submarine swap en la actualidad necesita estar programada para manejar la interacción con el servidor o necesita que tanto el pagador como el receptor completen un flujo de trabajo de múltiples pasos.

● Canales Just-in-Time (JIT), donde un usuario sin canales (o sin liquidez) crea un canal virtual con un proveedor de servicios; cuando llega el primer pago a ese canal virtual, el proveedor de servicios crea una transacción en la cadena que financia el canal y contiene ese pago. Al igual que cualquier HTLC de LN, el pago fuera de la cadena se realiza a un secreto que solo conoce el receptor. 

Sin embargo, una vez más, si el usuario no revela su secreto, entonces el proveedor de servicios no recibirá ninguna compensación y incurrirá en costos en la cadena sin obtener beneficio alguno. Voegtlin cree que los proveedores de servicios existentes de canales JIT evitan este problema al requerir que el usuario revele su secreto antes de que la transacción de financiamiento sea segura, lo que, según él, puede generar problemas legales y evita que las billeteras no custodiadas ofrezcan un servicio similar.

Voegtlin sugiere que permitir que una factura BOLT11 contenga dos compromisos separados de secretos, cada uno con un monto diferente, permitirá utilizar un secreto y monto para una tarifa inicial para pagar los costos de transacción en la cadena y el otro secreto y monto para el submarine swap real o el financiamiento del canal JIT. La propuesta recibió varios comentarios, algunos de los cuales resumiremos:

● Lógica dedicada requerida para los intercambios submarinos: Olaoluwa Osuntokun señala que el receptor de un intercambio submarino necesita crear un secreto, distribuirlo y luego liquidar un pago a él en la cadena. La forma más económica de liquidarlo es interactuando con el proveedor de servicios de intercambio. Si el pagador y el receptor van a interactuar de todos modos con el proveedor de servicios, como suele ser el caso con algunas implementaciones existentes donde el pagador y el receptor son la misma entidad, no necesitan comunicar información adicional mediante una factura. Voegtlin respondió que un software dedicado puede manejar la interacción, eliminando la necesidad de lógica adicional en la billetera fuera de la cadena que paga los fondos y la billetera en la cadena que recibe los fondos, pero esto solo es posible si la billetera LN puede pagar dos secretos y montos separados en la misma factura.

● BOLT11 está obsoleto: Matt Corallo respondió que aún no ha sido posible que todas las implementaciones de LN actualicen su soporte BOLT11 para admitir facturas que no contengan un monto (para permitir pagos espontáneos), por lo que no cree que agregar un campo adicional sea un enfoque práctico en este momento. Bastien Teinturier hace un comentario similar, sugiriendo agregar soporte a las ofertas. Voegtlin no está de acuerdo y considera que agregar soporte es práctico.

● Alternativa de extracción de canal: Corallo también pregunta por qué se debe modificar el protocolo para admitir submarine swap si están disponibles las extracciones de canal. No se mencionó en el hilo, pero tanto los submarine swaps como las extracciones de canal permiten mover fondos fuera de la cadena hacia una salida en la cadena; sin embargo, las extracciones de canal pueden ser más eficientes en la cadena y no son vulnerables a problemas de tarifas no compensadas. Voegtlin responde que los submarine swaps permiten a un usuario de LN aumentar su capacidad para recibir nuevos pagos de LN, lo cual no ocurre con las extracciones de canal.

La discusión parecía estar en curso al momento de escribir esto.

Esperando confirmación n.° 6: Coherencia de la Política

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

La publicación de la semana pasada presentó la política, un conjunto de reglas de validación de transacciones aplicadas además de las reglas de consenso. Estas reglas no se aplican a las transacciones en los bloques, por lo que un nodo aún puede mantenerse en consenso incluso si su política difiere de la de sus pares. Al igual que un operador de nodo puede decidir no participar en la transmisión de transacciones, también son libres de elegir cualquier política, incluso ninguna en absoluto (exponiendo su nodo al riesgo de denegación de servicio). Esto significa que no podemos asumir una homogeneidad completa de las políticas de mempool en toda la red. Sin embargo, para que la transacción de un usuario sea recibida por un minero, debe viajar a través de un camino de nodos que la acepten en su mempool; por lo tanto, la falta de similitud en la política entre los nodos afecta directamente la funcionalidad de transmisión de transacciones.

Como ejemplo extremo de diferencias de política entre nodos, imaginemos una situación en la que cada operador de nodo elija un nVersion aleatorio y solo acepte transacciones con ese nVersion. Dado que la mayoría de las relaciones peer-to-peer tendrían políticas incompatibles, las transacciones no se propagarían hacia los mineros.

Por otro lado, políticas idénticas en toda la red ayudan a converger el contenido del mempool. Una red con mempools coincidentes transmite las transacciones de manera más fluida y también es ideal para la estimación de tarifas y la transmisión de bloques compactos, como se mencionó en publicaciones anteriores.

Dada la complejidad de la validación del mempool y las dificultades que surgen de las disparidades de política, Bitcoin Core ha sido históricamente conservador en cuanto a la configurabilidad de las políticas. Si bien los usuarios pueden ajustar fácilmente la forma en que se cuentan los sigops (bytespersigop) y limitar la cantidad de datos incrustados en las salidas OP_RETURN (datacarriersize y datacarrier), no pueden optar por no cumplir con el peso máximo estándar de 400,000 unidades de peso ni aplicar un conjunto diferente de reglas de RBF relacionadas con las tarifas sin cambiar el código fuente. 

Algunas de las opciones de configuración de políticas de Bitcoin Core existen para adaptarse a las diferencias en los entornos de operación de los nodos y los propósitos de ejecución de un nodo. Por ejemplo, los recursos de hardware de un minero y el propósito de mantener un mempool difieren de un usuario común que ejecuta un nodo ligero en su computadora portátil o Raspberry Pi. Un minero puede optar por aumentar la capacidad de su mempool (maxmempool) o el plazo de vencimiento (mempoolexpiry) para almacenar transacciones de baja tarifa durante los momentos de mayor tráfico, y luego extraerlas más tarde cuando el tráfico disminuya. Los sitios web que brindan visualizaciones, archivos y estadísticas de red pueden ejecutar múltiples nodos para recopilar la mayor cantidad de datos posible y también mostrar el comportamiento predeterminado del mempool.

En un nodo individual, la elección de la capacidad del mempool afecta la disponibilidad de herramientas para aumentar las tarifas. Cuando las tarifas mínimas del mempool aumentan debido a que las transacciones presentadas superan el tamaño predeterminado del mempool, las transacciones eliminadas desde la parte inferior del mempool y las nuevas transacciones que tienen una tarifa inferior a esta ya no pueden aumentar la tarifa utilizando CPFP.

Por otro lado, dado que las transacciones eliminadas ya no están siendo utilizadas por ninguna transacción en el mempool, puede ser posible aumentar la tarifa mediante RBF cuando antes no era posible. La nueva transacción no está reemplazando realmente nada en el mempool del nodo, por lo que no necesita cumplir con las reglas habituales de RBF. Sin embargo, los nodos que no han eliminado la transacción original (porque tienen una capacidad de mempool más grande) tratan la nueva transacción como una sustitución propuesta y requieren que cumpla con las reglas de RBF. Si la transacción eliminada no estaba señalizando la posibilidad de reemplazo según BIP125, o la tarifa de la nueva transacción no cumple con los requisitos de RBF a pesar de tener una tarifa alta, el minero puede no aceptar la nueva transacción. Las billeteras deben manejar las transacciones eliminadas con cuidado: las salidas de la transacción no se pueden considerar disponibles para gastar, pero los insumos también están indisponibles para reutilizar.

A primera vista, puede parecer que un nodo con una capacidad de mempool más grande hace que CPFP sea más útil y RBF menos útil. Sin embargo, la transmisión de transacciones está sujeta al comportamiento emergente de la red y es posible que no haya una ruta de nodos que acepten el CPFP del usuario hasta el minero. Por lo general, los nodos solo reenvían las transacciones una vez que las aceptan en su mempool y ignoran los anuncios de transacciones que ya existen en sus mempools; los nodos que almacenan más transacciones actúan como agujeros negros cuando se les vuelve a transmitir esas transacciones. A menos que toda la red aumente las capacidades de sus mempools, lo cual sería una señal para cambiar el valor predeterminado, los usuarios deben esperar poco beneficio al aumentar la capacidad de sus propios mempools. El valor mínimo de tarifa del mempool establecido por los mempools predeterminados limita la utilidad de usar CPFP durante períodos de alto tráfico. Un usuario que logre enviar una transacción CPFP a su propio mempool de mayor capacidad podría no darse cuenta de que la transacción no se propagó a nadie más.

La red de transmisión de transacciones está compuesta por nodos individuales que se unen y abandonan dinámicamente la red, y cada uno de ellos debe protegerse contra la explotación. Como tal, la transmisión de transacciones solo puede ser un esfuerzo óptimo y no podemos garantizar que cada nodo conozca todas las transacciones no confirmadas. Al mismo tiempo, la red de Bitcoin funciona mejor si los nodos convergen en un conjunto de políticas de transmisión de transacciones que hagan que los mempools sean lo más homogéneos posible. El próximo artículo explorará qué políticas se han adoptado para adaptarse a los intereses de la red en su conjunto.

Cambios en servicios y software de clientes

En esta sección mensual, destacamos actualizaciones interesantes en billeteras y servicios de Bitcoin.

● Librerías Greenlight de código abierto: Greenlight, proveedor de servicios de nodo CLN sin custodia, ha anunciado un repositorio de librerías de cliente y enlaces de lenguaje, así como una guía para un marco de pruebas.

● Depurador de Tapscript Tapsim: Tapsim es una herramienta de depuración (ver Boletín #254) y visualización de ejecución de scripts para Tapscript utilizando btcd.

● Anuncio de Bitcoin Keeper 1.0.4: Bitcoin Keeper es una billetera móvil que admite múltiples firmantes, signatarios de hardware, BIP85 y, con la última versión, soporte de coinjoin utilizando el protocolo Whirlpool.

● Anuncio de la billetera Lightning EttaWallet: Recientemente se anunció la billetera móvil EttaWallet con características Lightning habilitadas por LDK y un enfoque sólido en la usabilidad, inspirado en el diseño de billeteras de gasto diario de la Comunidad de Diseño de Bitcoin.

● Anuncio de prueba de concepto de sincronización de encabezado de bloque basada en zkSNARK: BTC Warp es una prueba de concepto de sincronización de cliente liviano que utiliza zkSNARKs para probar y verificar una cadena de encabezados de bloque de Bitcoin. Una publicación de blog proporciona detalles sobre los enfoques utilizados.

● Lanzamiento de lnprototest v0.0.4: El proyecto lnprototest es un conjunto de pruebas para LN que incluye «un conjunto de ayudantes de prueba escritos en Python3, diseñados para facilitar la escritura de nuevas pruebas cuando se proponen cambios en el protocolo de la red Lightning, así como probar implementaciones existentes». 

Lanzamientos y versiones candidatas Nuevos lanzamientos y versiones candidatas de proyectos populares de infraestructura de Bitcoin. Por favor, considere actualizar a los nuevos lanzamientos o ayudar a probar las versiones candidatas.

● Eclair v0.9.0 es un nuevo lanzamiento de esta implementación de LN que «contiene mucho trabajo preparatorio para funciones importantes (y complejas) de Lightning: dual-funding, splicing y ofertas BOLT12». Por ahora, las características son experimentales. El lanzamiento también «hace que los complementos sean más poderosos, introduce medidas de mitigación contra varios tipos de DoS y mejora el rendimiento en muchas áreas del código base». Cambios notables en el código y la documentación Cambios destacados esta semana en Bitcoin Core, Core Lightning, Eclair, LDK, LND, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, BDK, Propuestas de Mejora de Bitcoin (BIP), Lightning BOLTs e Inquisición de Bitcoin.

● LDK #2294 agrega soporte para responder a mensajes onion y acerca LDK al soporte completo de ofertas.

● LDK #2156 agrega soporte para pagos keysend que utilizan pagos de ruta múltiple simplificados. LDK anteriormente admitía ambas tecnologías, pero solo cuando se usaban por separado. Los pagos de ruta múltiple deben utilizar secretos de pago, pero LDK anteriormente rechazaba los pagos keysend con secretos de pago, por lo que se agregaron errores descriptivos, una opción de configuración y una advertencia sobre el degradado para mitigar posibles problemas.