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

 

Boletín Bitcoin Optech #257

28 de junio de 2023

El boletín de esta semana resume una idea para evitar el anclaje de transacciones coinjoin y describe una propuesta para utilizar especulativamente cambios esperados en el consenso. También se incluye otro artículo de nuestra serie semanal limitada sobre la política de mempool, además de nuestras secciones regulares que describen preguntas populares y respuestas en Bitcoin Stack Exchange, nuevos lanzamientos y versiones candidatas, y cambios en software de infraestructura de Bitcoin popular.

Noticias

● Evitando el anclaje de transacciones coinjoin con el relevo de transacciones v3: Greg Sanders publicó en la lista de correo de Bitcoin-Dev una descripción de cómo las reglas de relevo de transacciones v3 propuestas podrían permitir la creación de una transacción multiparte de estilo coinjoin que no sería vulnerable al anclaje de transacciones. La preocupación específica con el anclaje es que uno de los participantes en un coinjoin puede usar su entrada en la transacción para crear una transacción en conflicto que impida que la transacción coinjoin se confirme.

Sanders propone que las transacciones de estilo coinjoin pueden evitar este problema al hacer que cada participante inicialmente gaste sus bitcoins en un script que solo pueda gastarse con la firma de todos los participantes en el coinjoin o solo por el participante después de que expire un bloqueo de tiempo. Alternativamente, para un coinjoin coordinado, el coordinador y el participante deben firmar juntos (o el participante solo después de la expiración del bloqueo de tiempo).

Hasta que expire el bloqueo de tiempo, el participante ahora debe hacer que las otras partes o el coordinador firmen cualquier transacción en conflicto, lo cual es poco probable que hagan a menos que la firma sea en el mejor interés de todos los participantes (por ejemplo, un aumento de tarifa).

● Uso especulativo de cambios esperados en el consenso: Robin Linus publicó en la lista de correo de Bitcoin-Dev una idea para gastar dinero en un fragmento de script que no se puede ejecutar durante mucho tiempo (como 20 años). Si ese fragmento de script se interpreta según las reglas de consenso actuales, permitirá a los mineros reclamar todos los fondos pagados a él en 20 años. Sin embargo, el fragmento está diseñado de manera que una actualización de las reglas de consenso dará un significado diferente al fragmento. Linus da el ejemplo de un opcode OP_ZKP_VERIFY que, si se agrega a Bitcoin, permitirá a cualquier persona proporcionar una Prueba de Conocimiento Cero (ZKP) para un programa con un hash particular para reclamar los fondos.
Esto permitiría a las personas gastar BTC hoy en uno de estos scripts y utilizar la prueba de ese gasto para recibir una cantidad equivalente de BTC en una cadena lateral o cadena alternativa, llamada anclaje unidireccional. Los BTC en la otra cadena podrían gastarse repetidamente durante 20 años, hasta que expire el bloqueo de tiempo del script. Luego, el propietario actual de los BTC en la otra cadena podría generar una prueba ZKP de que lo posee y usar esa prueba para retirar el depósito bloqueado en la Bitcoin mainnet, creando un anclaje bidireccional. Con un buen diseño para el programa de verificación, el retiro sería simple y flexible, lo que permitiría retiros fungibles.

Los autores señalan que cualquier persona que se beneficie de esta construcción (por ejemplo, quienes reciben BTC en otra cadena) básicamente está apostando a que las reglas de consenso de Bitcoin cambiarán (por ejemplo, se agregará OP_ZKP_VERIFY). Esto les brinda un incentivo para abogar por el cambio, pero incentivar fuertemente a algunos usuarios a cambiar el sistema puede hacer que otros usuarios sientan que están siendo coaccionados. Hasta la fecha de esta escritura, la idea no ha recibido ninguna discusión en la lista de correo.
Esperando confirmación #7: Recursos de la red

Una serie limitada de publicaciones semanales 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.
Una publicación anterior trató sobre la protección de los recursos del nodo, que pueden ser únicos para cada nodo y, por lo tanto, a veces configurables. También presentamos nuestro argumento sobre por qué es mejor converger en una sola política, pero ¿qué debería ser parte de esa política? En esta publicación se discutirá el concepto de recursos de la red en toda la red, que son críticos para aspectos como la escalabilidad, la capacidad de actualización y la accesibilidad para iniciar y mantener un nodo completo.

Como se discutió en publicaciones anteriores, muchos de los objetivos ideológicos de la red de Bitcoin se encuentran en su estructura distribuida. La naturaleza peer-to-peer de Bitcoin permite que las reglas de la red surjan de un consenso aproximado de las elecciones de los operadores de nodos individuales y limita los intentos de adquirir influencia indebida en la red. Esas reglas luego son aplicadas por cada nodo al validar individualmente cada transacción. Una población diversa y saludable de nodos requiere que el costo de operar un nodo se mantenga bajo. Es difícil escalar cualquier proyecto con una audiencia global, pero hacerlo sin sacrificar la descentralización es como luchar con una mano atada a la espalda. El proyecto Bitcoin intenta este acto de equilibrio al proteger ferozmente sus recursos compartidos de red: el conjunto de UTXO, la huella de datos de la cadena de bloques y el esfuerzo computacional requerido para procesarlos, y los ganchos de actualización para evolucionar el protocolo Bitcoin.

No es necesario repetir toda la guerra del tamaño de bloque para darse cuenta de que es necesario limitar el crecimiento de la cadena de bloques para que sea asequible ejecutar su propio nodo. Sin embargo, el crecimiento de la cadena de bloques también se desalienta a nivel de políticas mediante el minRelayTxFee de 1 sat/vbyte, lo que garantiza un costo mínimo para expresar parte de la «demanda ilimitada de almacenamiento perpetuo altamente replicado».
Originalmente, el estado de la red se rastreaba manteniendo todas las transacciones que aún tenían salidas no gastadas. Esta parte mucho más grande de la cadena de bloques se redujo significativamente con la introducción del conjunto de UTXO como medio para realizar un seguimiento de los fondos. Desde entonces, el conjunto de UTXO ha sido una estructura de datos central. Especialmente durante IBD (descarga inicial de bloques), pero también en general, las búsquedas de UTXO representan una parte importante de todos los accesos a memoria de un nodo. Bitcoin Core ya utiliza una estructura de datos optimizada manualmente para la caché de UTXO, pero el tamaño del conjunto de UTXO determina cuánto de él no puede caber en la caché de un nodo. Un conjunto de UTXO más grande significa más fallos de caché, lo que ralentiza la validación de bloques, IBD y la velocidad de validación de transacciones. El límite de polvo es un ejemplo de una política que restringe la creación de UTXO, específicamente limitando los UTXO que posiblemente nunca se gasten porque su cantidad es inferior al costo de gastarlos. Aun así, «tormentas de polvo» con miles de transacciones ocurrieron tan recientemente como en 2020.

Cuando se hizo popular usar salidas de multisig sin formato para publicar datos en la cadena de bloques, se modificó la definición de transacciones estándar para permitir una sola salida OP_RETURN como alternativa. Las personas se dieron cuenta de que sería imposible evitar que los usuarios publiquen datos en la cadena de bloques, pero al menos esos datos no necesitarían permanecer en el conjunto de UTXO para siempre cuando se publicaran en salidas que nunca se podrían gastar. Bitcoin Core 0.13.0 introdujo una opción de inicio -permitbaremultisig que los usuarios pueden activar o desactivar para rechazar transacciones no confirmadas con salidas de multisig sin formato.
Si bien las reglas de consenso permiten que los scripts de salida sean de formato libre, solo se transmiten unos pocos patrones bien entendidos por los nodos de Bitcoin Core. Esto facilita el razonamiento sobre muchas preocupaciones en la red, incluidos los costos de validación y los mecanismos de actualización del protocolo. Por ejemplo, un script de entrada que contenga opcodes, una entrada P2SH con más de 15 firmas o una entrada P2WSH cuya pila de testigos tenga más de 100 elementos harían que una transacción no sea estándar. (Consulte esta descripción general de políticas para obtener más ejemplos de políticas y sus motivaciones).

Finalmente, el protocolo Bitcoin es un proyecto de software en constante evolución que deberá seguir desarrollándose para enfrentar desafíos futuros y satisfacer las necesidades de los usuarios. Con ese fin, se han dejado deliberadamente varios ganchos de actualización válidos en consenso pero no utilizados, como el anexo, las versiones de hojas de taproot, las versiones de testigos, OP_SUCCESS y varios opcodes sin operación. Sin embargo, al igual que los ataques se ven obstaculizados por la falta de puntos centrales de falla, las actualizaciones de software a nivel de red implican un esfuerzo coordinado entre decenas de miles de operadores de nodos independientes. Los nodos no transmitirán transacciones que hagan uso de ningún gancho de actualización reservado hasta que se haya definido su significado. Esta desalentación tiene como objetivo disuadir a las aplicaciones de crear de manera independiente estándares conflictivos, lo que haría imposible adoptar el estándar de una aplicación en el consenso sin invalidar el de otra. Además, cuando ocurre un cambio de consenso, los nodos que no se actualizan de inmediato, y por lo tanto no conocen las nuevas reglas de consenso, no pueden ser «engañados» para aceptar una transacción ahora inválida en sus mempools. La desalentación proactiva ayuda a que los nodos sean compatibles hacia el futuro y permite que la red actualice de manera segura las reglas de consenso sin requerir una actualización de software completamente sincronizada.

Podemos ver que el uso de políticas para proteger los recursos de red compartidos ayuda a proteger las características de la red y mantiene abiertos los caminos para el desarrollo futuro del protocolo. Mientras tanto, estamos viendo cómo la fricción de hacer crecer la red frente a un peso de bloque estrictamente limitado ha estado impulsando la adopción de mejores prácticas, un buen diseño técnico e innovación: la publicación de la próxima semana explorará la política del mempool como una interfaz para protocolos de capa secundaria y sistemas de contratos inteligentes.

Preguntas y respuestas seleccionadas de Bitcoin Stack Exchange

Bitcoin Stack Exchange es uno de los primeros lugares donde los colaboradores de Optech buscan respuestas a sus preguntas o cuando tenemos algunos momentos libres para ayudar a usuarios curiosos o confundidos. En esta sección mensual, destacamos algunas de las preguntas y respuestas más votadas publicadas desde nuestra última actualización.

● ¿Por qué los nodos de Bitcoin aceptan bloques que excluyen tantas transacciones? El usuario commstark se pregunta por qué un nodo acepta un bloque de mineros que excluye transacciones que se esperaban para ese bloque según la plantilla de bloque de ese nodo. Hay varias herramientas que muestran bloques esperados en comparación con bloques reales. Pieter Wuille señala que debido a la variabilidad inherente en las mempools de los diferentes nodos en relación con la propagación de transacciones, no es posible aplicar una regla de consenso que imponga el contenido de un bloque.

● ¿Por qué todos dicen que las bifurcaciones suaves (soft forks) restringen el conjunto de reglas existente? Pieter Wuille utiliza como ejemplo las reglas agregadas durante las activaciones de las bifurcaciones suaves (soft forks) de taproot y segwit, que implicaron el endurecimiento de las reglas de consenso:

Taproot agregó el requisito de que los gastos de la salida OP_1 <32 bytes> (taproot) se adhieran a las reglas de consenso de taproot.
Segwit agregó el requisito de que los gastos de la salida OP_{0..16} <2..40 bytes> (segwit) se adhieran a las reglas de consenso de segwit y también requiere datos de testigo vacíos para las salidas previas a segwit.

● ¿Por qué se establece el límite predeterminado del canal de Lightning Network en 16777215 sats? Vojtěch Strnad explica el historial del límite de 2^24 satoshis y la motivación detrás de los canales grandes (wumbo), y también proporciona un enlace al tema de Optech sobre canales grandes para obtener más información.

● ¿Por qué Bitcoin Core utiliza el puntaje del ancestro en lugar de simplemente la tarifa del ancestro para seleccionar transacciones? Sdaftuar explica que la optimización del rendimiento es la razón por la que el algoritmo de selección de transacciones en la plantilla de bloque de minería utiliza tanto la tarifa del ancestro como el puntaje del ancestro. (Consulte «Waiting for confirmation #2: Incentives»).

● ¿Cómo define el protocolo de pagos multipartes (MPP) de Lightning los montos por parte? Rene Pickhardt señala que los pagos multipath (multipath payments) no tienen un tamaño de parte especificado por el protocolo ni un algoritmo para elegir el tamaño de la parte, y menciona algunas investigaciones relevantes sobre la división de pagos.

Lanzamientos y candidatos a lanzamientos

Nuevos lanzamientos y candidatos a lanzamientos de proyectos populares de infraestructura de Bitcoin. Considere la posibilidad de actualizar a las nuevas versiones o ayudar a probar los candidatos a lanzamientos.
●BTCPay Server 1.10.3 es la última versión de este software de procesamiento de pagos autohospedado. Consulta su publicación en el blog para obtener un recorrido por las características principales de la rama 1.10.

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, Bitcoin Improvement Proposals (BIPs), Lightning BOLTs y Bitcoin Inquisition.

● Core Lightning #6303 agrega un nuevo comando RPC llamado setconfig que permite cambiar algunas opciones de configuración sin reiniciar el daemon.
● Eclair #2701 comienza a registrar tanto cuando se recibe un HTLC ofrecido como cuando se liquida. Esto permite hacer un seguimiento de cuánto tiempo estuvo pendiente el HTLC desde la perspectiva del nodo. Si muchos HTLC o algunos HTLC de alto valor están pendientes durante períodos prolongados, esto puede indicar un ataque de congestión del canal en progreso. El seguimiento de la duración del HTLC ayuda a detectar dichos ataques y puede contribuir a mitigarlos.
● Eclair #2696 cambia la forma en que Eclair permite a los usuarios configurar las tarifas de transacción. Anteriormente, los usuarios podían especificar qué tarifa de transacción usar con un objetivo de bloque, por ejemplo, un valor de «6» significaba que Eclair intentaría confirmar una transacción dentro de seis bloques. Ahora, Eclair acepta las opciones «lenta» (slow), «media» (medium) y «rápida» (fast), que se traducen en tarifas de transacción específicas utilizando constantes u objetivos de bloque.
● LND #7710 agrega la capacidad para que los complementos (o el propio daemon) recuperen datos recibidos anteriormente en un HTLC. Esto es necesario para el enmascaramiento de ruta (route blinding) y puede ser utilizado por diversas contramedidas contra ataques de congestión del canal, entre otras ideas para características futuras.
● LDK #2368 permite aceptar nuevos canales creados por un par que utilizan salidas de ancla, pero requiere que el programa controlador elija deliberadamente aceptar cada nuevo canal. Esto se hace porque liquidar correctamente un canal de ancla puede requerir que el usuario tenga acceso a uno o más UTXO con un valor suficiente. LDK, como una biblioteca que desconoce qué UTXO no pertenecientes a Lightning Network controla la billetera del usuario, utiliza esta indicación para brindar al programa controlador la oportunidad de verificar que tiene los UTXO necesarios.
● LDK #2367 permite que los canales de ancla sean accesibles para los consumidores regulares de la API.
● LDK #2319 permite a un par crear un HTLC que se compromete a pagar menos que la cantidad que el gastador original dijo que se debe pagar, lo que permite al par quedarse con la diferencia como una tarifa adicional. Esto es útil para la creación de canales JIT (just-in-time) donde un par recibe un HTLC para un receptor que aún no tiene un canal. El par crea una transacción en cadena que financia el canal y se compromete al HTLC dentro de ese canal, pero incurre en tarifas adicionales de transacción al crear esa transacción en cadena. Al tomar una tarifa adicional, se compensa por sus costos si el receptor acepta el nuevo canal y liquida el HTLC a tiempo.
● LDK #2120 agrega soporte para encontrar una ruta hacia un receptor que utiliza rutas enmascaradas (blinded paths).
● LDK #2089 agrega un controlador de eventos que facilita a las billeteras incrementar las tarifas de cualquier HTLC que necesite ser liquidado en cadena.
● LDK #2077 refactoriza una gran cantidad de código para facilitar en el futuro la adición de soporte para canales financiados de forma dual (dual funded channels).
● Libsecp256k1 #1129 implementa la técnica ElligatorSwift para introducir una codificación de clave pública de 64 bytes que es computacionalmente indistinguible de datos aleatorios. El módulo ellswift proporciona funciones para codificar y decodificar claves públicas en el nuevo formato, así como funciones de conveniencia para
generar claves aleatorias uniformes y realizar un intercambio de claves de difie-hellman elípticas (ECDH) en claves codificadas con ellswift. El ECDH basado en ellswift se utilizará para establecer conexiones en el protocolo de transporte encriptado P2P de la versión 2 (BIP324).