BITCOIN OPTECH (01 de Junio, 2022). Bitcoin Optech Newsletter #255 | Traducción al español de IT4Bitcoin

 

Boletín Bitcoin Optech #255

junio 15, 2023

En el boletín de esta semana se resume una discusión sobre permitir el reenvío de transacciones que contienen datos en el campo anexo de taproot, así como un enlace a un borrador de BIP para pagos silenciosos. También se incluye otra entrada en nuestra serie semanal limitada sobre políticas de mempool, además de nuestras secciones regulares que resumen una reunión del Bitcoin Core PR Review Club, anuncian nuevos lanzamientos de software y candidatos a lanzamientos, y describen cambios destacados en el popular software de infraestructura de Bitcoin.

Noticias

Discusión sobre el anexo de taproot: Joost Jager publicó en la lista de correo de Bitcoin-Dev una solicitud para un cambio en la política de retransmisión de transacciones y minería de Bitcoin Core para permitir el almacenamiento de datos arbitrarios en el campo anexo de taproot. Este campo es una parte opcional de los datos de testigo para transacciones de taproot. Si está presente, las firmas en taproot y tapscript deben comprometerse con sus datos (lo que hace imposible que un tercero los agregue, elimine o cambie), pero actualmente no tiene otro propósito definido, ya que está reservado para futuras actualizaciones del protocolo, especialmente para bifurcaciones suaves.

Aunque ha habido propuestas anteriores para definir un formato para el anexo, estas no han tenido una aceptación e implementación generalizadas. Jager propuso dos formatos (1, 2) que podrían utilizarse para permitir que cualquier persona agregue datos arbitrarios al anexo de una manera que no complique significativamente los futuros esfuerzos de estandarización que podrían incluirse con un softfork.

Greg Sanders respondió preguntando qué datos específicamente Jager quería almacenar en el anexo y describió su propio uso del anexo al probar el protocolo LN-Symmetry con la propuesta de softfork SIGHASH_ANYPREVOUT utilizando Bitcoin Inquisition (consulte el Boletín #244). Sanders también describió un problema con el anexo: en un protocolo de varias partes (como una coinjoin), cada firma solo se compromete con el anexo para la entrada que contiene esa firma, no los anexos de otras entradas en la misma transacción. Esto significa que si Alice, Bob y Mallory firman una coinjoin juntos, no hay forma de que Alice y Bob puedan evitar que Mallory transmita una versión de la transacción con un anexo grande que retrase su confirmación. Debido a que Bitcoin Core y otros nodos completos actualmente no retransmiten transacciones que contienen anexos, esto no es un problema en la actualidad. Jager respondió que desea almacenar firmas de claves efímeras para un tipo de bóveda que no requiere una bifurcación suave, y sugirió que algunos trabajos anteriores en Bitcoin Core podrían abordar posiblemente el problema con la retransmisión de anexos en algunos protocolos de varias partes.

Esperando la confirmación n. ° 5: Política para la protección de los recursos del nodo

Una serie semanal limitada sobre retransmisión de transacciones, inclusión en mempool y selección de transacciones mineras, incluyendo 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 la manera más efectiva.

Comenzamos nuestra serie afirmando que gran parte de la privacidad y resistencia a la censura de Bitcoin se deriva de la naturaleza descentralizada de la red. La práctica de que los usuarios ejecuten sus propios nodos reduce los puntos centrales de fallos, vigilancia y censura. Sigue que uno de los principales objetivos de diseño del software del nodo de Bitcoin es la alta accesibilidad de ejecutar un nodo. Requerir que cada usuario de Bitcoin compre hardware costoso, use un sistema operativo específico o gaste cientos de dólares al mes en costos operativos muy probablemente reduciría el número de nodos en la red.

Además, un nodo en la red de Bitcoin es una computadora con conexiones a entidades desconocidas que pueden lanzar un ataque de denegación de servicio (DoS) mediante la creación de mensajes que hacen que el nodo se quede sin memoria y se bloquee, o que gasten sus recursos computacionales y ancho de banda en datos sin sentido en lugar de aceptar nuevos bloques. Dado que estas entidades son anónimas por diseño, los nodos no pueden predecir si un par será honesto o malicioso antes de conectarse, y no pueden prohibirlos de manera efectiva incluso después de observar un ataque. Por lo tanto, no es solo un ideal implementar políticas que protejan contra DoS y limiten el costo de ejecutar un nodo completo, sino un imperativo.

Las protecciones generales contra DoS están incorporadas en las implementaciones de nodos para evitar el agotamiento de recursos. Por ejemplo, si un nodo de Bitcoin Core recibe muchos mensajes de un solo par, solo procesa el primero y agrega el resto a una cola de trabajo para procesar después que los mensajes de otros pares. Un nodo también suele descargar primero el encabezado de un bloque y verificar su Prueba de Trabajo (PoW) antes de descargar y validar el resto del bloque. Por lo tanto, cualquier atacante que desee agotar los recursos de este nodo a través de la retransmisión de bloques primero debe gastar una cantidad desproporcionadamente alta de sus propios recursos calculando una PoW válida. La asimetría entre el enorme costo de cálculo de PoW y el costo trivial de verificación proporciona una forma natural de construir resistencia a DoS en la retransmisión de bloques. Esta propiedad no se extiende a la retransmisión de transacciones no confirmadas.

Las protecciones generales contra DoS no proporcionan suficiente resistencia a los ataques para permitir que el motor de consenso de un nodo esté expuesto a la entrada de la red peer-to-peer. Un atacante que intente crear una transacción válida desde el punto de vista computacionalmente intensivo puede enviar una transacción como la «megatransacción» de 1 MB en el bloque n. ° 364.292, que tardó un tiempo anormalmente largo en validarse debido a la verificación de firmas y la función de hash de firmas cuadráticas. Un atacante también puede hacer que todas las firmas, excepto la última, sean válidas, lo que hace que el nodo pase minutos en su transacción, solo para descubrir que es basura. Durante ese tiempo, el nodo retrasaría el procesamiento de un nuevo bloque. Se puede imaginar que este tipo de ataque se dirige a mineros competidores para obtener una «ventaja inicial» en el siguiente bloque.

En un esfuerzo por evitar trabajar en transacciones muy costosas desde el punto de vista computacional, los nodos de Bitcoin Core imponen un tamaño estándar máximo y un número máximo de operaciones de firma (o «sigops») en cada transacción, más restrictivo que el límite de consenso del bloque. Los nodos de Bitcoin Core también imponen límites tanto en los tamaños de paquetes ascendentes como descendentes, lo que hace que la producción de plantillas de bloque y los algoritmos de eliminación sean más efectivos y restringen la complejidad computacional de la inserción y eliminación de transacciones en la mempool, que requieren actualizar los conjuntos de transacciones ascendentes y descendentes. Si bien esto significa que algunas transacciones legítimas pueden no ser aceptadas o retransmitidas, se espera que esas transacciones sean raras.

Estas reglas son ejemplos de políticas de retransmisión de transacciones, un conjunto de reglas de validación además del consenso que los nodos aplican a las transacciones no confirmadas.

Por defecto, los nodos de Bitcoin Core no aceptan transacciones por debajo de la tarifa de retransmisión mínima de 1 sat/vB («minrelaytxfee»), no verifican ninguna firma antes de verificar este requisito y no retransmiten transacciones a menos que sean aceptadas en sus mempools. En cierto sentido, esta regla de tarifa establece un «precio» mínimo para la validación y retransmisión en la red. Un nodo que no mina nunca recibe tarifas; estas solo se pagan al minero que confirma la transacción. Sin embargo, las tarifas representan un costo para el atacante. Alguien que «desperdicia» recursos de la red enviando una cantidad extremadamente alta de transacciones eventualmente se queda sin dinero para pagar las tarifas.

La política «Replace by Fee (RBF)» implementada por Bitcoin Core requiere que la transacción de reemplazo pague una tarifa más alta que cada transacción con la que entra en conflicto directamente, pero también requiere que pague una tarifa total más alta que todas las transacciones que desplaza. Las tarifas adicionales divididas por el tamaño virtual de la transacción de reemplazo deben ser al menos de 1 sat/vB. En otras palabras, independientemente de las tarifas de las transacciones original y de reemplazo, la nueva transacción debe pagar tarifas «nuevas» para cubrir el costo de su propio ancho de banda a 1 sat/vB. Esta política de tarifas no se preocupa principalmente por la compatibilidad de incentivos. Más bien, esto incurre en un costo mínimo para las reemplazos de transacciones repetidas para limitar los ataques que desperdician ancho de banda, por ejemplo, agregando solo 1 satoshi adicional a cada reemplazo.

Un nodo que valida completamente bloques y transacciones requiere recursos, incluyendo memoria, recursos computacionales y ancho de banda de red. Debemos mantener los requisitos de recursos bajos para que sea accesible ejecutar un nodo y defenderlo contra la explotación. Las protecciones generales contra ataques de denegación de servicio (DoS) no son suficientes, por lo que los nodos aplican políticas de transmisión de transacciones además de las reglas de consenso al validar transacciones no confirmadas. Sin embargo, como la política no es parte del consenso, dos nodos pueden tener políticas diferentes y aún así estar de acuerdo en el estado actual de la cadena. El próximo artículo de la próxima semana discutirá la política como una elección individual.

Club de Revisión de PR de Bitcoin Core:

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

«Permitir conexiones entrantes whitebind para desalojar de manera más agresiva a pares cuando los espacios están llenos» es un PR de Matthew Zipkin (pinheadmz) que mejora la capacidad de un operador de nodo para configurar los pares deseados para el nodo en ciertos casos. Específicamente, si el operador del nodo ha incluido en la lista blanca un posible par entrante (por ejemplo, un cliente ligero controlado por el operador del nodo), entonces sin este PR, y dependiendo del estado de los pares del nodo, es posible que el nodo rechace el intento de conexión de este cliente ligero.

Este PR hace que sea mucho más probable que el par deseado pueda conectarse a nuestro nodo. Lo hace desalojando a un par entrante existente que, sin este PR, no habría sido elegible para desalojo.

    ¿Por qué este PR solo se aplica a solicitudes de pares entrantes?
    ¿Cuál es el impacto del parámetro «force» (forzar) de SelectNodeToEvict() en el valor de retorno?
    ¿Cómo cambia la firma de la función EraseLastKElements() en este PR?
    EraseLastKElements solía ser una función con plantillas, pero este PR elimina los dos argumentos de plantilla. ¿Por qué? ¿Existen desventajas en este cambio?
    Supongamos que pasamos un vector de 40 candidatos a desalojo a SelectNodeToEvict(). Antes y después de este PR, ¿cuál es el máximo teórico de nodos Tor que pueden estar protegidos contra el desalojo?

Versiones y candidatos a versión:

Nuevas versiones y candidatos a versión para proyectos populares de infraestructura de Bitcoin. Por favor, considera actualizar a nuevas versiones o ayudar a probar los candidatos a versión.

    Core Lightning 23.05.1 es una versión de mantenimiento para esta implementación de Lightning Network (LN). Sus notas de lanzamiento dicen: «esta es una versión que soluciona errores y repara varios bloqueos reportados en el campo. Se recomienda actualizar para cualquier persona en la v23.05».

Cambios destacados en código y 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 (BIP), Lightning BOLTs y Bitcoin Inquisition.

    Bitcoin Core #27501 agrega un RPC (Remote Procedure Call) getprioritisedtransactions que devuelve un mapa de todos los cambios de tarifas creados por el usuario con prioritisetransaction, indexados por txid. El mapa también indica si cada transacción está presente en el mempool. Consulta también el Boletín #250.
    Core Lightning #6243 actualiza el RPC listconfigs para colocar toda la información de configuración en un solo diccionario y también pasa el estado de todas las opciones de configuración a los complementos reiniciados.
    Eclair #2677 aumenta el valor predeterminado de max_cltv de 1.008 bloques (aproximadamente una semana) a 2.016 bloques (aproximadamente dos semanas). Esto extiende el número máximo permitido de bloques hasta que un intento de pago caduque. El cambio está motivado por los nodos en la red que han aumentado su ventana de tiempo reservada para abordar un HTLC que está por caducar (cltv_expiry_delta) en respuesta a tasas de tarifas altas en la cadena. Cambios similares se han fusionado en LND y CLN.
    Rust Bitcoin #1890 agrega un método para contar el número de operaciones de firma (sigops) en scripts que no son de tapscript. El número de sigops está limitado por bloque y el código de selección de transacciones de Bitcoin Core para minería trata a las transacciones con una alta proporción de sigops por tamaño (peso) como si fueran transacciones más grandes, lo que reduce efectivamente su tarifa. Esto significa que es importante que los creadores de transacciones utilicen un método como este nuevo para verificar el número de sigops que están utilizando.