BITCOIN OPTECH (28 de Junio, 2023). Bitcoin Optech Newsletter #259 | Traducción al español de IT4Bitcoin

 

Boletín Bitcoin Optech #259

12 de julio de 2023

Esta semana en el boletín se describe una propuesta para eliminar detalles de la especificación de LN que ya no son relevantes para los nodos modernos, y se incluye la penúltima entrada en nuestra serie limitada semanal sobre la política del mempool, además de nuestras secciones regulares que resumen una reunión del Bitcoin Core PR Review Club, anuncian nuevas versiones y candidatas a versiones, y describen cambios destacados en software de infraestructura popular de Bitcoin.

Noticias

● Propuesta de limpieza de especificación de LN: Rusty Russell publicó en la lista de correo Lightning-Dev un enlace a una solicitud de extracción (PR) donde propone eliminar algunas características que ya no son soportadas por implementaciones modernas de LN y asumir que otras características siempre serán soportadas. En relación con los cambios propuestos, Russell también presenta los resultados de una encuesta que realizó sobre las características públicas de los nodos según sus mensajes de difusión (gossip). Sus resultados indican que casi todos los nodos admiten las siguientes características:

• Mensajes de cebolla de tamaño variable: se convirtieron en parte de la especificación en 2019 (ver Boletín #58) alrededor del mismo tiempo que la especificación se actualizó para usar campos Type-Length-Value (TLV). Esto reemplazó el formato original para el enrutamiento de cebolla cifrada que requería que cada salto utilizara un mensaje de longitud fija y limitaba el número de saltos a 20. El formato de tamaño variable facilita mucho el reenvío de datos arbitrarios a saltos específicos, siendo la única desventaja que el tamaño general del mensaje permanece constante, por lo que cualquier aumento en la cantidad de datos enviados disminuye el número máximo de saltos.

• Consultas de difusión: se convirtieron en parte de la especificación en 2018 (ver BOLTs #392). Esto permite que un nodo solicite a sus pares solo un subconjunto de mensajes de difusión enviados por otros nodos en la red. Por ejemplo, un nodo puede solicitar solo actualizaciones recientes de difusión, ignorando actualizaciones más antiguas para ahorrar ancho de banda y reducir el tiempo de procesamiento.

• Protección contra pérdida de datos: se convirtió en parte de la especificación en 2017 (ver BOLTs #240). Los nodos que utilizan esta característica envían información sobre el estado más reciente de sus canales cuando se vuelven a conectar. Esto puede permitir que un nodo detecte que ha perdido datos y aliente a un nodo que no ha perdido datos a cerrar el canal en su estado más reciente. Ver Boletín #31 para más detalles adicionales.

• Claves remotas estáticas: se convirtieron en parte de la especificación en 2019 (ver Boletín #67), lo que permite que un nodo solicite que cada actualización de canal se comprometa a enviar los fondos no-HTLC del nodo a la misma dirección. Antes de este cambio, se utilizaba una dirección diferente en cada actualización de canal. Después de este cambio, un nodo que opte por este protocolo y pierda datos casi siempre recibirá finalmente al menos parte de sus fondos en la dirección elegida, como una dirección en su billetera HD.

Las respuestas iniciales a la PR de limpieza propuesta fueron positivas.

Esperando confirmación #9: Propuestas de Política

Una serie limitada semanal sobre retransmisión de transacciones, inclusión en el mempool y selección de transacciones para minar, incluyendo por qué Bitcoin Core tiene una política más restrictiva de lo permitido por el consenso y cómo las billeteras pueden usar esa política de manera más efectiva.

La publicación de la semana pasada describió las salidas de anclaje y CPFP (Carve Out) para asegurar que cualquiera de las partes del canal pueda aumentar la tarifa de sus transacciones de compromiso compartidas sin requerir colaboración. Este enfoque todavía tiene algunas desventajas: los fondos del canal están vinculados para crear salidas de anclaje, las tarifas de las transacciones de compromiso generalmente pagan de más para asegurar que cumplan con las tarifas mínimas del mempool, y CPFP Carve Out solo permite un descendiente adicional. Las salidas de anclaje no pueden asegurar la misma capacidad de aumentar las tarifas para transacciones compartidas entre más de dos partes, como coinjoins o protocolos de contratos de múltiples partes. Esta publicación explora los esfuerzos actuales para abordar estas y otras limitaciones.

Package relay incluye cambios en el protocolo P2P y en la política para permitir el transporte y validación de grupos de transacciones. Esto permitiría que una transacción de compromiso (commitment transaction) pueda tener su tarifa aumentada por un hijo (child) incluso si la transacción de compromiso no cumple con la tarifa mínima del mempool. Además, Package RBF permitiría que el hijo con tarifa aumentada pague por reemplazar las transacciones con las que su padre (parent) tiene conflictos. Package relay está diseñado para eliminar una limitación general en la capa de protocolo base. Sin embargo, debido a su utilidad en el aumento de tarifas de transacciones compartidas, también ha generado varios esfuerzos para eliminar el pinning (inmovilización) para casos de uso específicos. Por ejemplo, Package RBF permitiría que las transacciones de compromiso se reemplacen entre sí cuando se transmiten con sus respectivos hijos de aumento de tarifas, eliminando la necesidad de múltiples salidas de anclaje en cada transacción de compromiso.

Una advertencia es que las reglas existentes de RBF requieren que la transacción de reemplazo pague una tarifa absoluta más alta que las tarifas agregadas pagadas por todas las transacciones a reemplazar. Esta regla ayuda a prevenir ataques de denegación de servicio (DoS) a través de reemplazos repetidos, pero permite que un usuario malintencionado aumente el costo de reemplazar su transacción al agregar un hijo con alta tarifa pero baja tasa de tarifa. Esto dificulta que la transacción sea minada al evitar injustamente su reemplazo por un paquete con tarifa alta, y a menudo se conoce como «pinning de regla 3».

Los desarrolladores también han propuesto formas completamente diferentes de agregar tarifas a transacciones prefirmadas. Por ejemplo, al firmar las entradas de la transacción utilizando SIGHASH_ANYONECANPAY | SIGHASH_ALL, el transmisor de la transacción podría proporcionar tarifas agregando entradas adicionales a la transacción sin cambiar las salidas. Sin embargo, como RBF no tiene ninguna regla que requiera que la transacción de reemplazo tenga un «puntaje de minería» más alto (es decir, que se seleccione para un bloque más rápido), un atacante podría inmovilizar estos tipos de transacciones al crear reemplazos encabezados por ancestros de baja tasa de tarifa. Lo que complica la evaluación precisa del puntaje de minería de las transacciones y paquetes de transacciones es que los límites actuales de ancestros y descendientes son insuficientes para limitar la complejidad computacional de este cálculo. Cualquier transacción conectada puede influir en el orden en que las transacciones se seleccionan en un bloque. Un componente completamente conectado, llamado cluster, puede ser de cualquier tamaño dado los límites actuales de ancestros y descendientes.

Una solución a largo plazo para abordar algunas deficiencias del mempool y los ataques de pinning de RBF es reestructurar la estructura de datos del mempool para rastrear clusters en lugar de solo conjuntos de ancestros y descendientes. Estos clusters estarían limitados en tamaño. Un límite de cluster restringiría la forma en que los usuarios pueden gastar UTXOs no confirmados, pero haría posible linearizar rápidamente todo el mempool utilizando el algoritmo de minería basado en el puntaje de ancestros, construir plantillas de bloque extremadamente rápido y agregar un requisito de que las transacciones de reemplazo tengan un puntaje de minería más alto que las transacciones a reemplazar.

Sin embargo, es posible que ningún conjunto de políticas pueda satisfacer la amplia gama de necesidades y expectativas para la retransmisión de transacciones. Por ejemplo, mientras que los destinatarios de una transacción de pago agrupada se benefician al poder gastar sus salidas no confirmadas, un límite de descendencia relajado deja espacio para el pinning de Package RBF de una transacción compartida a través de tarifas absolutas. Se desarrolló una propuesta de política de retransmisión de transacciones v3 para permitir que los protocolos de contrato opten por un conjunto más restrictivo de límites de paquete. Las transacciones v3 solo permitirían paquetes de tamaño dos (un padre y un hijo) y limitarían el peso del hijo. Estos límites mitigarían el pinning de RBF a través de tarifas absolutas y ofrecerían algunos de los beneficios del mempool en clusters sin necesidad de una reestructuración del mempool.

Ephemeral Anchors se basa en las propiedades de las transacciones v3 y el relay de paquetes para mejorar aún más las salidas de anclaje. Exime a las salidas de anclaje pertenecientes a una transacción v3 sin tarifas del límite de polvo, siempre que la salida de anclaje sea gastada por un hijo de aumento de tarifas. Dado que la transacción sin tarifas debe ser aumentada por exactamente un hijo (de lo contrario, un minero no estaría incentivado a incluirla en un bloque), esta salida de anclaje es «efímera» y no formaría parte del conjunto UTXO. La propuesta de anclaje efímero impide implícitamente que las salidas que no son de anclaje se gasten mientras no estén confirmadas sin el timelock de 1 OP_CSV, ya que el único hijo permitido debe gastar la salida de anclaje. También haría factible la simetría LN con CPFP como mecanismo de provisión de tarifas para transacciones de cierre de canales. También hace este mecanismo disponible para transacciones compartidas entre más de dos participantes. Los desarrolladores han estado utilizando bitcoin-inquisition para implementar Anclajes Efímeros y propuestas de soft forks para construir y probar estos cambios de múltiples capas en un signet.

Los problemas de «pinning» resaltados en esta publicación, entre otros, generaron una gran cantidad de discusiones y propuestas para mejorar la política de RBF el año pasado en listas de correo, solicitudes de extracción, redes sociales y reuniones presenciales. Los desarrolladores propusieron e implementaron soluciones que van desde pequeñas enmiendas hasta una revisión completa. La opción «-mempoolfullrbf», destinada a abordar las preocupaciones de «pinning» y una discrepancia en las implementaciones de BIP125, iluminó la dificultad y la importancia de la colaboración en la política de retransmisión de transacciones. Aunque se hizo un esfuerzo genuino para involucrar a la comunidad utilizando métodos típicos, como iniciar la conversación en la lista de correo bitcoin-dev con un año de anticipación, quedó claro que los métodos de comunicación y toma de decisiones existentes no produjeron el resultado deseado y necesitaban ser refinados.

La toma de decisiones descentralizada es un proceso desafiante, pero necesario para apoyar el diverso ecosistema de protocolos y aplicaciones que utilizan la red de retransmisión de transacciones de Bitcoin. La próxima semana será nuestra última publicación en esta serie, en la que esperamos alentar a nuestros lectores a participar y mejorar este proceso.

Bitcoin PR Review Club

En esta sección mensual, resumimos una reunión reciente del Bitcoin Core PR Review Club, destacando algunas de las preguntas y respuestas importantes. Haga clic en una pregunta a continuación para ver un resumen de la respuesta de la reunión.

«Stop relaying non-mempool txs» es una solicitud de extracción (PR) de Marco Falke (MarcoFalke) que simplifica el cliente de Bitcoin Core eliminando una estructura de datos en memoria llamada «mapRelay», que puede causar un alto consumo de memoria y ya no es necesaria o al menos tiene un beneficio muy marginal. Este mapa contiene transacciones que pueden o no estar en el mempool, y a veces se utiliza para responder a solicitudes de datos (getdata) de los pares.

- ¿Cuáles son las razones para eliminar "mapRelay"?- ¿Por qué es difícil determinar el uso de memoria de "mapRelay"?- ¿Qué problema se resuelve al introducir "m_most_recent_block_txs"? (Esta es una lista de solo las transacciones en el bloque más recientemente recibido).- ¿Considera necesario introducir "m_most_recent_block_txs", en lugar de simplemente eliminar "mapRelay" sin reemplazo alguno?- ¿Cuáles son los requisitos de memoria para "m_most_recent_block_txs" en comparación con "mapRelay"?- ¿Existen escenarios en los que las transacciones estarían disponibles durante un tiempo más corto o más largo que antes como resultado de este cambio?

Lanzamientos y candidatos a lanzamientos

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

- LND v0.16.4-beta es una versión de mantenimiento de este software de nodo LN que corrige una fuga de memoria que puede afectar a algunos usuarios.

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

Cambios destacados de 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 (BIPs), Lightning BOLTs y Bitcoin Inquisition.