BITCOIN OPTECH (19 de Julio, 2023). Bitcoin Optech Newsletter #260 | Traducción al español de Conociendo Cripto

 

Boletín Bitcoin Optech #260

19 de julio de 2023

El boletín de esta semana incluye la entrada final de nuestra serie semanal limitada sobre la política de mempool, además de nuestras secciones regulares que describen cambios notables en los clientes, los servicios y el popular software de infraestructura de Bitcoin.

Noticias

No se encontraron noticias significativas esta semana en las listas de correo de Bitcoin-Dev o Lightning-Dev.

Esperando confirmación #10: Participe

La entrada final de nuestra serie semanal limitada sobre la retransmisión de transacciones, la inclusión de mempool y la selección de transacciones de minería, que incluye por qué Bitcoin Core tiene una política más restrictiva que la permitida por consenso y cómo las billeteras pueden usar esa política de manera más efectiva.

Esperamos que esta serie les haya dado a los lectores una mejor idea de lo que está pasando mientras esperan la confirmación. Comenzamos con una discusión sobre cómo algunos de los valores ideológicos de Bitcoin se traducen en su estructura y objetivos de diseño. La estructura distribuida de la red peer-to-peer ofrece una mayor resistencia a la censura y privacidad en comparación con un modelo centralizado típico. Una red abierta de retransmisión de transacciones ayuda a todos a conocer las transacciones en bloques antes de la confirmación, lo que mejora la eficiencia de la retransmisión de bloques, hace que unirse como nuevo minero sea más accesible y crea una subasta pública para el espacio de bloques. Dado que la red ideal consta de muchas entidades independientes y anónimas que ejecutan nodos, el software del nodo debe diseñarse para proteger contra DoS y, en general, minimizar los costos operativos.

Las tarifas juegan un papel importante en la red de Bitcoin como la forma «justa» de resolver la competencia por el espacio de bloques. Los Mempools con reemplazo de transacciones y algoritmos de desalojo y selección conscientes de paquetes usan la compatibilidad de incentivos para medir la utilidad de almacenar una transacción y habilitan RBF y CPFP como mecanismos de aumento de tarifas para los usuarios. La combinación de estas políticas de mempool, billeteras que construyen transacciones de manera económica y una buena estimación de la tarifa crea un mercado eficiente para el espacio de bloques que beneficia a todos.

Los nodos individuales también hacen cumplir la política de retransmisión de transacciones para protegerse contra el agotamiento de los recursos y expresar preferencias personales. A nivel de toda la red, las reglas de estandarización y otras políticas protegen los recursos que son críticos para escalar, la accesibilidad para ejecutar un nodo y la capacidad de actualizar las reglas de consenso. Como la gran mayoría de la red hace cumplir estas políticas, son una parte importante de la interfaz sobre la que se basan las aplicaciones de Bitcoin y los protocolos L2. Tampoco son perfectos. Describimos varias propuestas relacionadas con políticas que abordan limitaciones amplias y casos de uso específicos, como ataques de fijación en transacciones de liquidación L2.

También destacamos que la evolución continua de las políticas de red requiere la colaboración entre los desarrolladores que trabajan en protocolos, aplicaciones y billeteras. A medida que el ecosistema de Bitcoin crece con respecto al software, los casos de uso y los usuarios, un proceso de toma de decisiones descentralizado se vuelve más necesario pero también más desafiante. Incluso a medida que crece la adopción de Bitcoin, el sistema surge de las preocupaciones y los esfuerzos de sus partes interesadas: no hay una empresa a cargo de recopilar los comentarios de los clientes y contratar ingenieros para crear nuevas funciones de protocolo o eliminar funciones no utilizadas. Las partes interesadas que deseen formar parte del consenso aproximado de la red tienen diferentes vías para participar: informándose, planteando preguntas y problemas, involucrándose en el diseño de la red o incluso contribuyendo a la implementación de mejoras. La próxima vez que su transacción tarde demasiado en confirmarse, ¡ya sabe qué hacer!

Cambios en los servicios y el software del cliente

En esta función mensual, destacamos actualizaciones interesantes para las carteras y servicios de Bitcoin.

● Prueba beta de Wallet 10101 que combina fondos entre LN y DLC: 10101 anunció una billetera creada con LDK y BDK que permite a los usuarios negociar derivados sin custodia usando DLC en un contrato fuera de la cadena que también se puede usar para enviar, recibir y reenviar pagos de LN . Los DLC se basan en oráculos que usan firmas de adaptadores para la certificación de precios.

● LDK Node anunciado: el equipo de LDK anunció LDK Node v0.1.0. LDK Node es una biblioteca Rust de nodo Lightning que utiliza las bibliotecas LDK y BDK para permitir a los desarrolladores configurar rápidamente un nodo Lightning con autocustodia y al mismo tiempo proporcionar un alto grado de personalización para diferentes casos de uso.

● Payjoin SDK anunciado: Payjoin Dev Kit (PDK) se anunció como una biblioteca de Rust que implementa BIP78 para usar en billeteras y servicios que desean integrar la funcionalidad de payjoin.

● Se anuncia la versión beta de Validating Lightning Signer (VLS): VLS permite la separación de un nodo Lightning de las claves que controlan sus fondos. Un nodo Lightning que se ejecute con VLS enrutará las solicitudes de firma a un dispositivo de firma remoto en lugar de claves locales. La versión beta es compatible con CLN y LDK, reglas de validación de capa 1 y capa 2, capacidades de copia de seguridad/recuperación y proporciona una implementación de referencia. El anuncio de la publicación del blog también requiere pruebas, solicitudes de funciones y comentarios de la comunidad.

● BitGo agrega compatibilidad con MuSig2: BitGo anunció la compatibilidad con BIP327 (MuSig2) y señaló las tarifas reducidas y la privacidad adicional en comparación con sus otros tipos de direcciones compatibles.

● Peach agrega compatibilidad con RBF: la aplicación móvil Bitcoin de Peach para el intercambio entre pares anunció la compatibilidad con el aumento de tarifas de reemplazo por tarifa (RBF).

● La billetera Phoenix agrega soporte de empalme: ACINQ anunció una prueba beta para la próxima versión de su billetera móvil Lightning de Phoenix. La billetera admite un solo canal dinámico que se reequilibra mediante el empalme y un mecanismo similar a la técnica de intercambio en potencia (ver Podcast #259).

● Solicitud de comentarios del kit de desarrollo de minería: el equipo que trabaja en el kit de desarrollo de minería (MDK) ha publicado una actualización sobre su progreso en el desarrollo de hardware, software y firmware para los sistemas de minería de Bitcoin. La publicación solicita comentarios de la comunidad sobre casos de uso, alcance y enfoque.

● Binance agrega soporte Lightning: Binance anunció soporte para enviar (retiros) y recibir (depósitos) utilizando Lightning Network.

● Nunchuk agrega compatibilidad con CPFP: Nunchuk anunció la compatibilidad con el aumento de tarifas Child-Pays-For-Parent (CPFP) tanto para los remitentes como para los destinatarios de una transacción.

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

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

● Bitcoin Core #27411 evita que un nodo anuncie su dirección Tor o I2P a pares en otras redes (como IPv4 o IPv6) y no anunciará su dirección desde redes no anónimas a pares en Tor e I2P. Esto ayuda a evitar que alguien asocie la dirección de red normal de un nodo a una de sus direcciones en una red de anonimato. CJDNS se trata de manera diferente a Tor e I2P en este momento, aunque eso puede cambiar en el futuro.

● Core Lightning #6347 agrega la capacidad de que un complemento se suscriba a cada notificación de evento usando el comodín *.

● Core Lightning #6035 agrega la capacidad de solicitar una dirección bech32m para recibir depósitos en scripts de salida P2TR. El cambio de transacción ahora también se enviará a una salida P2TR de forma predeterminada.

● LND n.° 7768 implementa los BOLT n.° 1032 y n.° 1063 (consulte el boletín informativo n.° 225), lo que permite que el receptor final de un pago (HTLC) acepte un monto mayor al que solicitó y con un tiempo antes de que caduque más largo del que solicitó. Anteriormente, los receptores basados en LND cumplían con el requisito de BOLT4 de que la cantidad y el delta de vencimiento equivalían exactamente a la cantidad que solicitaban, pero esa exactitud significaba que un nodo de reenvío podía probar el siguiente salto para ver si era el receptor final cambiando ligeramente cualquiera de los valores.

● Libsecp256k1 #1313 comienza la prueba automática utilizando instantáneas de desarrollo de los compiladores GCC y Clang que pueden permitir la detección de cambios que podrían resultar en la ejecución de cierto código libsecp256k1 en tiempo variable. El código de tiempo no constante que funciona con claves privadas y nonces puede provocar ataques de canal lateral. Consulte el Boletín n.º 246 para una ocasión en la que eso pudo haber sucedido y el Boletín n.º 251 para otra ocasión y un anuncio de que se planeó este tipo de prueba.