El boletín Bitcoin Optech ofrece a los lectores una-Resumen a nivel de las noticias técnicas más importantes que suceden en Bitcoin, junto con recursos que les ayudan a aprender más. Para ayudar a nuestros lectores a mantenerse actualizados con Bitcoin, volvemos a publicar el último número de este boletín a continuación. Recuerde suscribirse para recibir este contenido directamente en su bandeja de entrada.
El boletín de esta semana incluye nuestras secciones regulares que describen cómo puede prepararse para la raíz principal, resumiendo los últimos lanzamientos y candidatos de lanzamiento, y enumerando cambios notables en la infraestructura popular de Bitcoin proyectos.
Noticias
No hay noticias importantes esta semana.
Preparándose para la raíz principal # 7: firmas múltiples
Una semana serie sobre cómo los desarrolladores y proveedores de servicios pueden prepararse para la próxima activación de la raíz principal a la altura del bloque 709,632.
En los 1,000 bloques recibidos antes de esta escritura, el 11% de todas las entradas de transacciones contenían un código de operación multisig. Dos de los beneficios más grandes e inmediatos de taproot se manifestarán si muchos de los usuarios y servicios que crean esas transacciones cambian de códigos de operación de múltiples firmas a sin script multifirmas .
El primer gran beneficio será la reducción del tamaño de la transacción. Las firmas múltiples basadas en scripts aumentan de tamaño a medida que se requieren más claves y firmas, pero las firmas múltiples tienen un tamaño pequeño constante. La política de firma múltiple efectiva más pequeña (1 de 2) requiere más espacio que una política de firma múltiple que puede involucrar a miles de firmantes. La disminución en el tamaño conduce a una reducción directa en las tarifas para los usuarios de múltiples firmas y una reducción indirecta en las tarifas para todos los usuarios, ya que la misma cantidad de demanda de transacciones confirmadas se puede satisfacer utilizando una cantidad menor de espacio en bloque.
El segundo gran beneficio es una mayor privacidad. Cada uso de multisigs se registra de manera distintiva en la cadena de bloques, donde los supervisores pueden usarlos para realizar conjeturas informadas sobre el historial de la billetera y el saldo actual de los usuarios individuales. Por ejemplo, al observar el bloque 692,039, podemos distinguir no solo los gastos de múltiples firmas de los gastos de firma única, sino también distinguir entre diferentes tamaños de conjuntos y umbrales para las múltiples firmas.
En comparación, un tercero que solo busca en la cadena de bloques, los datos no pueden decir que un gastador utilizó una firma múltiple. Cuando se utiliza una firma múltiple para un gasto de ruta clave, es indistinguible de los gastos de firma única. Si todos los de sigla única y multisig en el bloque anterior se cambiaran a gastos de ruta clave P2TR, solo unos pocos gastos exóticos se distinguirían por sus scripts (e incluso aquellos podrían usar gastos de ruta clave en el mejor de los casos).
Uso de firmas múltiples
Conocemos tres esquemas de firmas múltiples basados en schnorr diseñados específicamente para Bitcoin, todos miembros del objetivo Familia MuSig :
MuSig (también llamado MuSig1), que debería ser simple de implementar pero que requiere tres rondas de comunicación durante el proceso de firma. MuSig2, también simple de implementar. Elimina una ronda de comunicación y permite combinar otra ronda con el intercambio de claves. Eso permite usar un proceso de firma algo similar al que usamos hoy con multisig basado en script. Esto requiere almacenar datos adicionales y asegurarse de que su software o hardware de firma no pueda ser engañado para que repita sin saberlo parte de la sesión de firma. MuSig-DN (Deterministic Nonce), significativamente más complejo de implementar. Su comunicación entre los participantes no se puede combinar con el intercambio de claves, pero tiene la ventaja de que no es vulnerable al ataque repetido de la sesión.
Todos los firmantes deben acordar el protocolo a utilizar, por lo que puede haber un efecto de red donde muchas implementaciones optan por utilizar el mismo protocolo. Los autores de las propuestas de MuSig sugieren que será MuSig2 debido a su relativa sencillez y alta utilidad.
Existe un PR abierto y desarrollado activamente para proyecto libsecp256k1-zkp para agregar compatibilidad con MuSig2. Esperamos que el flujo de trabajo básico de varias firmas se parezca a lo siguiente:
La billetera de cada participante genera un BIP32 xpub que se comparte con todos los demás participantes a través de un descriptor del script de salida u otro método (lo mismo que se hace comúnmente ahora para multisigs). La billetera también genera un conjunto de nonces que también se comparten con los otros participantes. La billetera puede generar estos nonces utilizando la derivación reforzada BIP32. Nonces son 32 bytes y necesita dos de ellos por firma. Para carteras de uso poco frecuente, todos los nonces necesarios para toda la vida útil de la cartera se pueden compartir por adelantado. Para carteras de uso más frecuente (por ejemplo, nodos de enrutamiento LN), cada cartera puede enviar su firma para la transacción actual junto con sus nonces para la siguiente transacción.Cualquiera de las carteras puede generar una clave pública agregada combinando su clave pública en un determinado BIP32. profundidad con claves públicas a la misma profundidad de todas las demás carteras en la asociación de múltiples firmas. La clave pública agregada se puede usar para recibir pagos P2TR. Cuando una de las billeteras quiere gastar los fondos, usa un Flujo de trabajo basado en PSBT similar al que usaría con la función multigrupo basada en scripts. A diferencia de multisig, la billetera usa sus siguientes nonces y los siguientes nonces de todos los demás participantes para crear un nonce compartido de acuerdo con el algoritmo MuSig2; luego crea una firma parcial sobre ese nonce y la transacción. Cuando las otras carteras reciben el PSBT, utilizan el mismo procedimiento. Las firmas parciales luego se combinan para crear la firma final y la transacción se transmite.
Firma de umbral
Por sí mismos, la familia MuSig de esquemas de firmas múltiples solo le brinda firmas n-de-n: cada parte Quien aporta una clave a la clave pública agregada también debe contribuir con una firma parcial a la firma final. Eso funciona perfectamente como un reemplazo directo para algunos usos de la función multisig basada en scripts en la actualidad, como gastar salidas de financiamiento de 2 de 2 LN, pero es una desviación de otras políticas populares, como el script multisig 2 de 3 utilizado por muchos intercambios.
Varios desarrolladores están trabajando en esquemas de firma de umbral que traerá los mismos beneficios de eficiencia y privacidad de las firmas múltiples a escenarios de k-de-n, pero hay un truco simple que puede usarse hasta que esos esquemas estén disponibles.
En muchos casos de umbral, se sabe de antemano qué es más probable que los participantes firmen. Por ejemplo, en una situación de 2 de 3, se podría saber que normalmente Alice y Bob firmarán conjuntamente, mientras que Carol solo firmará si uno de los otros no está disponible. Para este conjunto de circunstancias, las claves primarias pueden usar una firma múltiple para el gasto de ruta de clave de raíz principal (por ejemplo, entre Alice y Bob) y los resultados adicionales (Alice y Carol, o Bob y Carol) pueden usar firmas múltiples con el código de operación OP_CHECKSIG en ramas separadas en un árbol de tapscripts .
En el caso normal, lo anterior tiene exactamente tanta eficiencia y privacidad como una transacción de firma única o firma múltiple. En el caso anormal, el gasto aún funciona como se esperaba y sigue siendo más eficiente y privado que publicar sus parámetros de múltiples firmas en la cadena.
Aunque los usuarios que desean tarifas mínimas y máxima privacidad pueden eventualmente cambiar a esquemas de firma de umbral puro, lo anterior
Versiones y candidatos de liberación
Nuevos lanzamientos y candidatos de lanzamiento para proyectos populares de infraestructura de Bitcoin. Considere actualizar a nuevas versiones o ayudar a probar versiones candidatas.
C-Lightning 0.10.1rc2 es un candidato de lanzamiento para una actualización que contiene una serie de funciones nuevas, varias correcciones de errores y algunas actualizaciones para los protocolos de desarrollo (incluido doble financiación y ofertas ).
Cambios notables en el código y la documentación
Cambios notables esta semana en Bitcoin Core , C-Lightning , Eclair , LND , Rust-Lightning , libsecp256k1 , Interfaz de billetera de hardware (HWI) , Rust Bitcoin , BTCPay Server , Propuestas de mejora de Bitcoin (BIP) y Lightning BOLTs .
Bitcoin Core # 22006 agrega documentación para el espacio de usuario, seguimiento definido estáticamente ( USDT) y los primeros tres puntos de seguimiento: soporte de compilación y macros para los cuales se agregaron en Bitcoin Core # 19866 . Los usuarios que construyen Bitcoin Core con el rastreo eBPF habilitado pueden conectarse a los puntos de rastreo con los ejemplos de scripts proporcionados o escribir sus propios scripts de seguimiento para una mayor observabilidad en el nodo cuando se conecta un nuevo bloque, se reciben mensajes P2P entrantes y se envían mensajes P2P salientes. La documentación también incluye ejemplos de uso y pautas para la adición de nuevos puntos de seguimiento. Eclair # 1893 permite configuración separada de tarifas para canales no anunciados , canales anunciados y trampolín mínimos de retransmisión. Este PR también establece diferentes tarifas de retransmisión predeterminadas para canales no anunciados (0.01%) en contraste con los canales anunciados (0.02%). Rust-Lightning # 967 agrega soporte para hacer pagos espontáneos al estilo keysend a través de la llamada a la función de pago espontáneo. Con este cambio, las cuatro implementaciones de LN que cubrimos serán compatibles con el envío de claves.
El autor también ha enviado documentación correspondiente (aún no fusionada) sobre pagos keysend como BLIP (Propuestas de mejora del relámpago de Bitcoin), una forma propuesta de documentar características y mejores prácticas que no pertenecen como parte de la especificación LN BOLTs
Busque el publicación original aquí.
Por favor suscríbase al boletín de Bitcoin Optech directamente para recibir este contenido directamente en su bandeja de entrada cada mes.
