Bitcoin Optech – Boletín #234

0 0
Read Time:7 Minute, 52 Second




Boletín semanal de Bitcoin Optech 18 de enero de 2023 traducido por @copinmalin.


El boletín de esta semana describe una propuesta de nuevos códigos de operación específicos de la bóveda e incluye nuestras secciones habituales con resúmenes de actualizaciones interesantes de clientes y servicios, anuncios de nuevos lanzamientos y lanzamientos candidatos, y descripciones de cambios significativos en el popular software de infraestructura de Bitcoin.

Noticias

  • Propuesta de nuevos códigos de operación específicos de la bóveda: James O’Beirne publicó en la lista de correo de Bitcoin-Dev una propuesta para una bifurcación suave para agregar dos nuevos códigos de operación, OP_VAULT y OP_UNVAULT.
    • OP_VAULT aceptaría tres parámetros: un compromiso con una ruta de gasto altamente confiable, un período de demora y un compromiso con una ruta de gasto menos confiable.OP_UNVAULT también aceptaría tres parámetros. Cuando se usa para las bóvedas previstas por O’Beirne, sería el mismo compromiso con una ruta de gasto altamente confiable, el mismo período de demora y un compromiso con uno o más resultados para incluir en una transacción posterior.

    Para crear una bóveda, Alice elige una ruta de gasto altamente confiable, como la firma múltiple que requiere acceso a múltiples dispositivos de firma separados o billeteras de almacenamiento en frío en diferentes ubicaciones. También elige una ruta de gasto menos confiable, como una sola firma de su billetera caliente habitual. Finalmente, elige un período de retraso específico utilizando el mismo tipo de datos que BIP68, que puede determinar períodos que van desde unos pocos minutos hasta aproximadamente un año. Una vez que se selecciona su configuración, Alice crea una dirección de Bitcoin normal para recibir fondos en su bóveda, esta dirección se compromete a un script usando OP_VAULTPara gastar los fondos recibidos previamente en la dirección de su bóveda, Alice comienza determinando las salidas que finalmente desea pagar (p. ej., enviar un pago a Bob y devolver el cambio a su bóveda). En el uso típico, Alice cumple las condiciones de su ruta de gasto menos confiable, como proporcionar una firma de su billetera virtual, para crear una transacción que paga todos los fondos de la bóveda a una sola salida. Esta salida contiene OP_UNVAULT con la misma configuración para la ruta de gasto de confianza y el retraso. El tercer parámetro es un compromiso con los resultados que, en última instancia, Alice quiere pagar. Alice termina de crear la transacción, incluido el establecimiento de la tarifa mediante el patrocinio de tarifas, un tipo de salida ancla u otro mecanismo. Alice transmite su transacción y luego se incluye en un bloque. Esto permite que cualquier persona vea que se está realizando un intento de desbloqueo. El software de Alice detecta que se trata de un gasto de sus fondos guardados y verifica que el tercer parámetro de la salida OP_UNVAULT de la transacción confirmada coincide exactamente con el compromiso que Alice creó anteriormente. Suponiendo que esto coincida, Alice ahora espera a que expire el tiempo de espera, después de lo cual puede transmitir una transacción que gasta desde la UTXO. OP_UNVAULT a las salidas con las que se comprometió anteriormente (por ejemplo, Bob y una salida de cambio). Este sería un gasto exitoso de los fondos de Alice usando el camino menos seguro, como usar solo su billetera caliente. Sin embargo, imaginemos que el software de Alice ve el intento de desbloqueo confirmado y no lo reconoce. no. En este caso, su software tiene la posibilidad, durante el período de demora, de congelar los fondos. Crea una transacción gastando la salida. OP_UNVAULT a la dirección de confianza que fue objeto de compromisos anteriores. Siempre que esta transacción congelada se confirme antes de que finalice el período de demora, los fondos de Alice están protegidos para que no se vean comprometidos en su ruta de gasto menos confiable. Una vez que los fondos se han transferido a la ruta de gastos de gran confianza de Alice, Alice puede gastarlos en cualquier momento cumpliendo las condiciones de esa ruta (por ejemplo, usando sus billeteras frías). Además de ofrecer los nuevos códigos de operación, O’Beirne también describe la motivación de las bóvedas y analiza otras propuestas de bóvedas, incluidas las que están disponibles en Bitcoin ahora usando transacciones prefirmadas y las que dependerían de otras propuestas de bifurcaciones blandas con condiciones de gasto. . Varias ventajas descritas de la propuesta OP_VAULT incluir:

    • Galletas más pequeñas: Los términos de gastos flexibles propuestos, como los que usan el OP_CHECKSIGFROMSTACK propuesto, requerirían que las cookies de transacción para las transacciones desbloqueadas incluyan copias de una cantidad significativa de datos que ya están presentes en otra parte de la transacción, inflando el tamaño y el costo de las tarifas para estas transacciones. OP_VAULT requiere que se incluyan muchos menos datos de secuencias de comandos y cookies en la cadena.Menos pasos para los gastos: Las propuestas de términos de gasto menos flexibles y las bóvedas disponibles en la actualidad basadas en transacciones prefirmadas requieren que los fondos se retiren en una dirección predeterminada antes de que puedan enviarse a un destino final. Estas propuestas generalmente también requieren que cada producto recibido se gaste en una transacción separada de otros productos recibidos, lo que impide el uso de la agregación de pagos. Esto aumenta la cantidad de transacciones involucradas, lo que también infla el tamaño y el costo del gasto.OP_VAULT requiere menos transacciones cuando se gasta una sola salida en casos típicos y también admite la agrupación de transacciones cuando se gastan o congelan múltiples salidas, lo que potencialmente ahorra una gran cantidad de espacio y permite que las bóvedas reciban muchas más transacciones antes de que sus salidas deban consolidarse para razones de seguridad.

    Al discutir la idea, Greg Sanders propuso (como lo resumió O’Beirne) una construcción ligeramente diferente que «permitiría que todas las salidas en los ciclos de vida de la bóveda fueran compatibles con P2TR, por ejemplo, lo que ocultaría cómo funciona la bóveda, una característica muy buena. ” Además, Anthony Towns señala que la propuesta permite al usuario de una bóveda congelar sus fondos en cualquier momento simplemente gastando los fondos en la dirección de la ruta de gasto altamente confiable, lo que le permite al usuario descongelar sus fondos más adelante. safe encuentra su valor allí, porque no necesita acceso a claves especialmente seguras, como una billetera fría, para bloquear un intento de robo. Sin embargo, cualquier tercero que conozca la dirección también puede congelar los fondos del usuario (aunque tienen que pagar tarifas de transacción para hacerlo), lo cual es un inconveniente para el usuario. Dado que muchas billeteras livianas filtran sus direcciones a terceros para ubicar sus transacciones en cadena, las bóvedas construidas sobre estas billeteras podrían involuntariamente dar a terceros la capacidad de incomodar a los usuarios de las bóvedas Towns sugiere una construcción alternativa para la condición de congelación que requeriría proporcionar una pieza adicional de información no privada para iniciar una congelación, preservi ng los beneficios del esquema, pero también reduce el riesgo de que una billetera le dé innecesariamente a terceros la capacidad de congelar fondos y causar molestias al usuario. Towns también sugiere una posible mejora en el soporte para agregaciones de transacciones y patrones de raíz. Varias respuestas también mencionaron que OP_UNVAULT puede proporcionar muchas de las características de la propuesta OP_CHECKTEMPLATEVERIFY (CTV), incluidos los beneficios para los DLC descritos anteriormente en el Boletín n.º 185, aunque a un costo mayor para el canal que usar CTV directamente. La discusión seguía activa al momento de escribir este artículo.

Principales cambios en el código y la documentación.

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

  • Kraken anuncia el envío a direcciones taproot: En una publicación de blog reciente, Kraken anunció que admite el retiro (envío) a direcciones bech32m.
  • Anuncio de la biblioteca de cliente Whirlpool coinjoin rust: Samourai Whirlpool Client es una biblioteca oxidada para interactuar con la plataforma de unión de monedas Whirlpool
  • Ledger admite miniscript: La versión 2.1.0 del firmware Bitcoin de Ledger para sus dispositivos de firma de hardware admite miniscript, como se anunció anteriormente.
  • Liana Wallet ha sido lanzada: Se ha anunciado la primera versión de la billetera Liana. La billetera admite billeteras singlesig con una clave de recuperación con bloqueo de tiempo. Los planes futuros para el proyecto incluyen la implementación de taproot, billeteras de firmas múltiples y características de firmas múltiples que reducen el tiempo.
  • Electrum 4.3.3 ha sido actualizado: Electrum 4.3.3 contiene mejoras para Lightning, PSBT, claves de firma de hardware y el sistema de compilación.

Actualizaciones y versiones candidatas

Nuevos lanzamientos y lanzamientos candidatos para los principales proyectos de infraestructura de Bitcoin. Considere actualizar a nuevas versiones o ayudar a probar las versiones candidatas.

  • HWI 2.2.0 es una versión de esta aplicación que permite que las billeteras de software interactúen con dispositivos de firma de hardware. Agrega soporte para dependencias de ruta de acceso clave P2TR utilizando el dispositivo de firma de hardware BitBox02, entre otras funciones y correcciones de errores.

Principales cambios 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) y Lightning BOLT.










Consulte el artículo original sobre bitcoin.fr

Happy
Happy
0 %
Sad
Sad
0 %
Excited
Excited
0 %
Sleepy
Sleepy
0 %
Angry
Angry
0 %
Surprise
Surprise
0 %