Bitcoin Optech Newsletter #198

BITCOIN OPTECH (04 de Mayo, 2022). Bitcoin Optech Newsletter #198 | Traducido al español por IT4Bitcoin.

 

Boletín Bitcoin Optech #198

4 de mayo de 2022

El boletín de esta semana resume una publicación sobre la implementación de MuSig2, transmite la divulgación responsable de un problema de seguridad que afecta a algunas implementaciones de Lightning Network (LN) más antiguas, discute una propuesta para medir el soporte para los cambios de consenso a través de la señalización de transacciones y examina el efecto de la limitar  la velocidad del sistema de comunicación “gossip” en LN. También se incluyen nuestras secciones regulares que resumen los nuevos lanzamientos de software y los candidatos a lanzamientos, además de cambios notables en los proyectos más populares de infraestructura de Bitcoin.

Noticia

• ● Notas de implementación de MuSig2: Olaoluwa Osuntokun respondió al borrador de BIP para MuSig2 mencionado en  el Boletín # 195 con notas de las implementaciones en las que él y otros han trabajado para btcd y LND:
• ● Interacción con BIP86: las claves creadas por una billetera BIP32 HD que implementa BIP86 siguen la  recomendación de BIP341 para crear keypath-only ajustando la clave mediante un hash de sí misma. Esto ayuda a evitar que la clave se use en una multisignature, lo que podría permitir a un participante incluir en secreto una opción de gasto de scriptpath que controlan, dándoles la capacidad de robar todos los fondos. Sin embargo, si los participantes de múltiples firmas desean deliberadamente incluir una opción de gasto de scriptpath, deben compartir las versiones sin ajustar de sus claves entre sí.

Osuntokun recomienda que las implementaciones de BIP86 devuelvan tanto la clave original (internal key) como la clave ajustada (output key) para que la función de llamada pueda usar la que sea apropiada para su contexto.

• ● Interacción con scriptpath spends: las claves destinadas a ser utilizadas con scriptpath spends tienen un problema relacionado: para usar el scriptpath, el gastador debe conocer la internal key. Una vez más, esto sugiere que las implementaciones devuelven la internal key para que esté disponible para ser utilizada en otro código que la necesite.
• ● Acceso directo para final signer: Osuntokun también solicitó aclaraciones sobre una sección en el BIP que describe cómo el firmante final (y solo el firmante final) puede usar la aleatoriedad determinista o una fuente de aleatoriedad de menor calidad para generar su firma nonce. Brandon Black respondió para describir la situación que había motivado la sección: tenían un firmante que tendría dificultades para administrar de manera segura una sesión regular de firma de MuSig2, pero que en su lugar siempre pudieron usar como firmante final.
• ● Medición del apoyo de los usuarios a los cambios de consenso: Keagan McClelland publicó en la lista de correo de Bitcoin-Dev una propuesta similar a  las propuestas anteriores para que las transacciones indiquen si apoyaron o no  un esfuerzo particular para cambiar las reglas de consenso. En el hilo, también se discutieron varias ideas de medición de sentimientos relacionadas, pero todas parecían tener problemas, como desafíos técnicos, reduciendo significativamente  la  privacidad del usuario, favoreciendo ciertas partes de la economía de Bitcoin sobre otras, o penalizando a los votantes anticipados sobre aquellos que esperaban para participar en la formación de consenso.

Al igual que en ocasiones anteriores en las que se ha discutido este tema, no parecía que ninguno de los métodos sugeridos produjera un resultado que fuera suficientemente respetado por la mayoría de los participantes en la discusión cuando se trataba de informar sus decisiones sobre el cambio de las reglas de consenso de Bitcoin.

• ● Problema de seguridad “LN anchor outputs”: Bastien Teinturier publicó en la lista de correo de Lightning-Dev el anuncio de un problema de seguridad que previamente había revelado responsablemente a los mantenedores de implementación de LN. El problema afectó a versiones anteriores de Core Lightning (con características experimentales habilitadas) y LND. Cualquiera que todavía use las versiones mencionadas en la publicación de Teinturier se recomienda encarecidamente que actualice.

Antes de la implementación de anchor outputs (salidas ancladas), las transacciones HTLC revocadas contenían un solo resultado, por lo que muchas implementaciones solo intentaron reclamar ese único resultado. El nuevo diseño de salidas de anclaje para LN permite combinar múltiples salidas HTLC revocadas en una sola transacción, pero esto solo es seguro si las implementaciones reclaman todas las salidas relevantes en la transacción. Cualquier fondo que no haya sido reclamado en el momento en que expire el bloqueo de tiempo HTLC puede ser robado por la parte que transmitió el HTLC revocado. La implementación de Teinturier de anchor outputs para Eclair le permitió probar las otras implementaciones de LN y descubrir la vulnerabilidad.

Al igual que con un ataque anterior relacionado con las salidas ancladas (consulte el boletín # 115), el problema parece estar relacionado con la adición de soporte para firmar con SIGHASH_SINGLE| SIGHASH_ANYONECANPAY sin dejar de conservar el soporte heredado para firmar con SIGHASH_ALL.

• ● Limitación de la tasa de Gossip sobre LN: Alex Myers publicó en la lista de correo de Lightning-Dev sobre su investigación sobre el uso de  la reconciliación de conjuntos basada en minisketch para reducir la cantidad de ancho de banda utilizado por los nodos para aprender sobre las actualizaciones del gráfico de canales de LN. Su método asume que todos los pares tienen casi toda la misma información sobre casi todos los mismos canales públicos. Un par puede generar un minisketch a partir de su gráfico completo de la red pública y enviarlo a todos sus pares, que pueden usar el minisketch para encontrar cualquier actualización de la red desde su última reconciliación. Esto es diferente al uso propuesto de minisketch para la red P2P de Bitcoin a través del protocolo erlay donde solo se envían actualizaciones (nuevas transacciones no confirmadas) de los últimos segundos.

Uno de los desafíos de la reconciliación en todos los canales públicos es que requiere que todos los nodos LN mantengan la misma información. Cualquier filtrado que produzca una diferencia persistente en la vista del gráfico de canales entre nodos dará lugar a una sobrecarga de ancho de banda o a un fallo del protocolo. Matt Corallo sugirió que esto podría abordarse aplicando el modelo erlay a LN: si solo se sincronizara nueva información, no habría una preocupación por las diferencias persistentes, aunque las grandes variaciones en las criterios de filtrado aún podrían resultar en un desperdicio de ancho de banda o una falla de reconciliación. Myers estaba preocupado por la cantidad de información de seguimiento de estado requerido de actualizaciones: un nodo Bitcoin Core mantiene un estado separado para cada uno de sus pares con el fin de evitar reenviar actualizaciones enviadas previamente al nodo. La alternativa de conciliar en todos los canales elimina la necesidad de un estado por pares, simplificando en gran medida la implementación de la gestión de gossip.

La discusión sobre las compensaciones implícitas en cada uno de estos enfoques estaba en curso mientras se escribía este resumen.

Lanzamientos y candidatos a lanzamiento

Nuevos lanzamientos y candidatos de lanzamiento para proyectos populares de infraestructura de Bitcoin. Considere la posibilidad de actualizar a nuevas versiones o ayudar a probar los candidatos a versiones.

• ● BTCPay Server 1.5.1 es una nueva versión de este popular software de procesamiento de pagos autohospedado que incluye un nuevo panel de control de la página principal, una nueva  función de procesamientos de pagos y la capacidad de permitir que los pagos y reembolsos se aprueben automáticamente.
• ● BDK 0.18.0 es una nueva versión de esta biblioteca para carteras. Incluye una solución de seguridad crítica de una de sus dependencias, la biblioteca rust-miniscript. También incluye varias mejoras y correcciones de errores menores.

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 (BIPs) y Lightning BOLTs.

• ● Bitcoin Core # 18554 evita que el mismo archivo de la cartera Bitcoin Core (wallet.dat) se use en múltiples cadenas de bloques (signet, testnet, etc) de forma predeterminada. Cuando Bitcoin Core escanea un nuevo bloque en busca de transacciones que afecten a una de sus carteras, registra el hash del encabezado de ese bloque. Este PR comprueba si dicho bloque desciende del mismo bloque génesis o no. Si no es así, se devuelve un error a menos que se establezca la nueva  opción de configuración -walletcrosschain. Esto evita que una cartera         destinada a su uso con una red (por ejemplo, red principal) se use con otra red (por ejemplo, testnet), lo que reduce el riesgo de pérdida accidental de dinero o pérdida de privacidad. Esto solo afecta a los usuarios de la cartera interna de Bitcoin Core; otro software de billetera Bitcoin no se ve afectado.
• ● Bitcoin Core # 24322 es parte de un esfuerzo mayor para isolar un motor de consenso mediante la creación de una biblioteca para usar el código de consenso de Bitcoin Core tal como está, luego podar gradualmente los módulos para hacer que la biblioteca sea minimalista. A saber, este PR presenta una biblioteca libbitcoinkernel que delinea todos los archivos fuente contra los que el  ejecutable bitcoin-chainstate (introducido en Bitcoin Core # 24304) necesita vincular. La lista incluye archivos que pueden no parecer lógicamente relacionados con el consenso, lo que ilustra las dependencias actuales del motor de consenso de Bitcoin Core. El trabajo futuro modularizará el consenso del resto de la base de código, eliminando estos archivos de la lista de fuentes de libbitcoinkernel.
• ● Bitcoin Core # 21726 agrega la capacidad de mantener un índice coinstats incluso en nodos pruneados. Coinstats incluye el resumen MuHash del estado UTXO en cada bloque, lo que permite validar los estados assumeUTXO. Anteriormente, solo se garantizaba que esto estuviera disponible en nodos completos de archivo, aquellos que almacenan todos los bloques. Este PR combinado también hace que la información esté disponible para los nodos completos prunned (aquellos que eliminan bloques algún tiempo después de validarlos) cuando la opción de configuración -coinstatsindex está habilitada.
• ● BDK # 557 agrega el primer algoritmo de selección de monedas más antiguo. Ahora hay cuatro algoritmos de selección de monedas: Branch and Bound (BnB), Single Random Draw (SRD), Oldest First y Largest First. De forma predeterminada, BDK usará BnB con SRD como respaldo si BnB no encontró ninguna solución.
• ● LDK # 1425 agrega soporte para canales grandes («canales wumbo»), que son canales que admiten pagos de alto valor.
• ● LND #6064 agrega nuevas opciones de configuración de bitcoind.config y bitcoind.rpccookie para especificar rutas no predeterminadas para los archivos de cookies de configuración y RPC.
• ● LND #6361 actualiza el método signrpc para poder crear firmas utilizando el  algoritmo MuSig2. Consulte la documentación agregada en este PR combinado para obtener más detalles. Tenga en cuenta que el soporte para MuSig2 es experimental y puede cambiar, especialmente si hay cambios importantes en el BIP propuesto para MuSig2 (consulte el Boletín # 195).
• ● BOLTs #981 elimina de la especificación la capacidad de comprimir consultas y resultados sobre el gráfico de red LN. Se cree que la compresión no se estaba utilizando y la eliminación del soporte reduce la complejidad y el número de dependencias para las implementaciones de LN.