El boletín de Bitcoin Optech proporciona a los lectores un resumen de alto nivel de las noticias técnicas más importantes que ocurren 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 resume una discusión sobre un nuevo código de operación propuesto y enlaces a una página wiki actualizada para rastrear el soporte de bech32m. También se incluyen nuestras secciones regulares con aspectos destacados de una reunión del Club de revisión de relaciones públicas de Bitcoin Core, sugerencias sobre cómo prepararse para la raíz principal y descripciones de cambios notables en proyectos de infraestructura de Bitcoin populares.
Noticias
Solicitud de diseño OP_CHECKSIGFROMSTACK sugerencias: Jeremy Rubin publicado en el correo de Bitcoin-Dev enumerar un borrador de especificación para un OP_CHECKSIGFROMSTACK código de operación y solicitar comentarios a los desarrolladores que prefieran una alternativa diseño. Se discutieron algunas alternativas, pero el hilo también se dividió en una discusión sobre si un OP_CAT el código de operación debe introducirse al mismo tiempo. OP_CAT y OP_CSFS permitirían la introspección de transacciones arbitrarias: la capacidad de recibir bitcoins en un script que podría verificar casi cualquier parte de la transacción que luego gasta esos bitcoins. Esto puede habilitar muchas funciones avanzadas (incluidas las versiones 1 de otros actualizaciones propuestas como SIGHASH_ANYPREVOUT y OP_CHECKTEMPLATEVERIFY ), pero OP_CAT también permite crear convenios que podrían restringir permanentemente la posibilidad de gastar cualquier bitcoins comprometido con el convenio. Algunas personas han objetado a permitir convenios en Bitcoin, pero varios argumentos eran hecho en el sentido de que los peores problemas de casos de convenios recursivos ya existen en Bitcoin hoy en día, por lo que No debería preocuparse por habilitar OP_CAT o un código de operación similar. A pesar de la discusión, Rubin decidió que quería mantener su propuesta OP_CSFS independiente de cualquier propuesta para agregar OP_CAT, argumentando que OP_CSFS es lo suficientemente útil por sí solo. Seguimiento de la compatibilidad con bech32m: la página Wiki de Bitcoin para adopción de bech32 se ha actualizado para realizar un seguimiento de qué software y servicios respaldan el gasto o recibir direcciones de bech32m para taproot. Bitcoin Core PR Review Club
En esta sección mensual, resumimos una reunión reciente del Bitcoin Core PR Review Club , destacando algunas de las preguntas importantes y respuestas. Haga clic en una de las preguntas siguientes para ver un resumen de la respuesta de la reunión.
Utilice los ayudantes de script_util para crear P2 {PKH, SH , WPKH, WSH} scripts es un PR de Sebastian Falbesoner que sustituye la creación manual de scripts con llamadas a las funciones auxiliares script_util en pruebas funcionales y corrige un error en la función get_multisig (). La reunión del club de revisión desglosó la terminología y cada uno de los tipos de salida de script utilizados en el PR. ¿Qué hacen key_to_p2pkh_script, script_to_p2sh_script, key_to_p2wpkh_scriptand script_to_p2wsh_script en script_util.py hacer?
Estas son funciones auxiliares para construir objetos CScript para Pay to Public Key Hash , Pay to Script Hash, Pay to Witness Public Key Hash y Pay to Witness Script Hash scripts de claves públicas y scripts. ➚ Defina scriptPubKey, scriptSig y testigo.
scriptPubKey y scriptSig son campos en la salida y entrada de una transacción, respectivamente, para especificar y satisfacer las condiciones de gasto. El testigo es un campo adicional para el mismo propósito introducido con Testigo segregado. Los requisitos de gasto están comprometidos en el scriptPubKey de una salida y la entrada que lo gasta debe ir acompañada de datos que satisfagan esas condiciones en el scriptSig y/o en el testigo. ➚ Defina el guión de canje y el guión de testigo. ¿Cuál es la relación entre ellos?
Los tipos de salida P2SH y P2WSH se comprometen con un hash de script en scriptPubKey. Cuando se gasta la salida, el gastador debe proporcionar el script en sí, junto con las firmas u otros datos necesarios para que se apruebe. El guión se denomina redeemScript cuando está incluido en el scriptSig y un guión de testigo cuando está en el testigo. En ese sentido, son análogos; un redeemScript es para una salida P2SH lo que un script testigo es para una salida P2WSH. Sin embargo, no son mutuamente excluyentes, ya que una transacción que gasta una salida P2SH-P2WSH contiene ambos. ➚ Para enviar monedas a alguien con condiciones de gasto codificadas en un script, lo que se incluye en el scriptPubKey de ¿La salida? ¿Qué se debe proporcionar en la entrada cuando se gasta la moneda?
El scriptPubKey incluye el hash del script y los códigos de operación para verificar una coincidencia: OP_HASH160 OP_PUSHBYTES_20
La motivación principal como se indica en BIP16 es crear un forma genérica de financiar transacciones arbitrariamente complejas mientras se coloca la carga de proporcionar las condiciones de gasto en quien redime los fondos. Los participantes también mencionaron que mantener el script fuera de scriptPubKeys significa que sus tarifas asociadas no se pagan hasta el canje y resulta en un conjunto de UTXO más pequeño. ➚ Cuando un nodo que no es segwit valida una entrada P2SH-P2WSH, ¿qué hace? ¿Qué hace un nodo habilitado para segwit además del procedimiento realizado por un nodo no segwit?
El nodo no segwit nunca ve al testigo; simplemente hace cumplir las reglas P2SH verificando que redeemScript coincida con el hash comprometido en el scriptPubKey. Un nodo segwit reconoce estos datos como un programa testigo y utiliza los datos del testigo y el scriptCode apropiado para hacer cumplir las reglas segwit. ➚ ¿Cuál es el problema con el script P2SH-P2WSH en el get_multisig () función?
Utiliza el script de testigo en lugar de su hash en el script de canje P2SH-P2WSH. ➚ Preparación para la raíz principal n. ° 4: de P2WPKH a P2TR de un solo signo
Una serie semanal sobre cómo los desarrolladores y proveedores de servicios pueden prepararse para la próxima activación. de raíz principal a una altura de bloque 709,632.
Para billeteras que ya admiten recibir y gastar salidas v0 segwit P2WPKH, la actualización a v1 segwit P2TR para single-sig debería ser fácil. Estos son los pasos principales: Use una nueva ruta de derivación de clave BIP32: no necesita cambiar su BIP32 Código jerárquico determinista (HD) y sus usuarios no necesitan cambiar sus semillas. 2 Sin embargo, le recomendamos encarecidamente que utilice una nueva ruta de derivación para sus claves públicas P2TR (como la definida por BIP86 ); si no lo hace, existe un posible ataque que puede ocurrir si usa las mismas claves con ECDSA y firmas schnorr .Dbilite su clave pública por su hash: aunque técnicamente no es necesario para single-sig, especialmente cuando todas sus claves se derivan de una semilla BIP32 elegida al azar, BIP341 recomienda hacer que tu clave se confirme en un árbol de script que no se puede usar. Esto es tan simple como usar una operación de suma de curva elíptica que sume su clave pública con el punto de la curva del hash de esa clave. Las ventajas de cumplir con esta recomendación son que podrá utilizar el mismo código si luego agrega multifirma sin script. soporte o si agrega soporte para descriptores tr () .Cree sus direcciones y controle su búsqueda: use bech32m para crear sus direcciones. Los pagos se enviarán al scriptPubKey OP_1
Lanzamientos y candidatos de lanzamiento
Nuevos lanzamientos y candidatos de lanzamiento para proyectos populares de infraestructura de Bitcoin. Considere actualizar a nuevas versiones o ayudar a probar versiones candidatas. LND 0.13.1-beta.rc2 es una versión de mantenimiento con pequeñas mejoras y correcciones de errores para las funciones introducidas en 0.13.0-beta.
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 cartera de hardware (HWI) , Rust Bitcoin , BTCPay Server , Propuestas de mejora de Bitcoin (BIP) y Lightning BOLTs . C-Lightning # 4625 actualiza su implementación de ofertas de LN para coincidir con los últimos cambios de especificación . En particular, ya no es necesario que las ofertas contengan una firma. Esto acorta significativamente la cadena codificada para las ofertas, lo que mejora el reconocimiento del código QR. Eclair # 1746 agrega soporte para replicar datos en una base de datos PostsgreSQL en paralelo a la base de datos primaria SQLite. La función está destinada a facilitar las pruebas para los servidores que desean realizar una eventual transición de backend. El año pasado, el ingeniero de Suredbits Roman Taranchenko describió la personalización de Eclair para uso empresarial con un backend de PostgreSQL en un campo Optech informe . LND # 5447 agrega un documento que describe cómo configurar varios nodos LND en un clúster con una base de datos alternativa que se replica entre los los nodos del clúster y que permite la conmutación por error automática. Los lectores interesados tal vez deseen contrastar esto con el enfoque adoptado por Eclair y descrito en Boletín n. ° 128 . Libsecp256k1 n. ° 844 realiza varias actualizaciones a la API para firmas schnorr . Lo más notable es un commit que permite firmar y verificar mensajes de cualquier largo. Todos los usos actuales de firmas en Bitcoin firman un hash de 32 bytes, pero permitir la firma de datos de longitud variable podría ser útil para aplicaciones fuera de Bitcoin o para habilitar un nuevo código de operación como OP_CHECKSIGFROMSTACK a verificar firmas creadas para sistemas que no son Bitcoin. Se espera que la especificación BIP340 de firmas schnorr para Bitcoin sea actualizado para describir la firma segura de datos de longitud variable. BIP # 943 actualizaciones BIP118 para construir sobre taproot y tapscript que pronto se activarán en lugar de SegWit v0. Además, esta revisión cambia el nombre del título a SIGHASH_ANYPREVOUT de SIGHASH_NOINPUT para reflejar que ahora se hace referencia a la bandera sighash. a como”ANYPREVOUT”dado que, si bien cualquier salida anterior puede potencialmente usarse con la firma, algunos aspectos de la entrada aún están comprometidos. BTCPay Server # 2655 indica a los navegadores web que no deben enviar el campo de referencia HTTP cuando el usuario hace clic en un enlace a una transacción en un explorador de bloques . Esto evita decirle al explorador de bloques de qué servidor BTCPay proviene el usuario; esa información es una fuerte evidencia de que el servidor originó o recibió la transacción que se ve en el explorador de bloques. Incluso con este cambio, los usuarios que deseen una privacidad sólida deben evitar buscar sus propias transacciones en exploradores de bloques de terceros. Notas al pie Uso de OP_CHECKSIGFROMSTACK (OP_CSFS) para implementar la función principal de propuestas como BIP118 SIGHASH_ANYPREVOUT o OP_CHECKTEMPLATEVERIFY de BIP119 requeriría más espacio de bloque que las propuestas optimizadas si se gasta en la ruta de script se utiliza. El argumento a favor de OP_CSFS es que permite comenzando con una construcción genérica y probando que las personas realmente usarán la función antes de que se use un cambio de consenso para agregar una implementación más eficiente. Además, con la introducción de taproot keypath gastados, cualquier script se puede resolver con el uso mínimo de bloquear el espacio en alguna situación, posiblemente reduciendo la necesidad de construcciones específicas que ahorren espacio en situaciones no óptimas. ↩ Cuando Electrum se actualizó a segwit v0, fue necesario que quería recibir direcciones bech32 para generar nuevas semillas. Esto no era un requisito técnico, pero permitió a los autores de Electrum introducir algunas nuevas funciones en su método de derivación de semillas personalizado. Una de esas características era la capacidad de un número de versión inicial para especificar con qué secuencias de comandos se debe utilizar una semilla. Esto permite la desaprobación segura de scripts antiguos (por ejemplo, es posible que se publique una versión futura de Electrum que ya no admita la recepción de direcciones P2PKH heredadas).
Casi al mismo tiempo que los desarrolladores de Electrum estaban implementando sus semillas versionadas, los desarrolladores de Bitcoin Core comenzaron utilizando descriptores de secuencias de comandos de salida para resolver el mismo problema de permitir la desaprobación de secuencias de comandos (además para resolver otros problemas). La siguiente tabla compara las semillas versionadas de Electrum y los descriptores de Bitcoin Core con el método de scripts implícitos previamente utilizado por ambas carteras y que todavía es de uso común entre la mayoría de las otras carteras.
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.
