Visite el artículo original *
http://bitcoinmagazine.com/.image/c_limit,cs_srgb,fl_progressive,h_1200,q_auto:good,w_1200/MTc5Mjk3NzgyODU1NTc1MTkx/bitcoin-optech-bridges-gap-for-development.jpg
El boletín de esta semana cubre el progreso de la activación de la raíz principal, una reunión del Bitcoin Core PR Review Club y más.
El boletín de Bitcoin Optech proporciona a los lectores un resumen de las principales noticias técnicas en Bitcoin, así como recursos para ayudarlos a aprender más. Para ayudar a nuestros lectores a mantenerse actualizados sobre Bitcoin, publicamos la última edición de este boletín a continuación. Recuerde registrarse para recibir este contenido directamente en su bandeja de entrada.
El boletín de esta semana resume los avances recientes en el código de activación de la raíz principal e incluye nuestras secciones regulares que describen una reunión reciente del Bitcoin Core PR Review Club y cambios notables en el popular software de infraestructura de Bitcoin.
noticias
- Discusión sobre la activación de la raíz principal: Desde nuestra última actualización sobre los métodos de activación de la bifurcación suave de la raíz principal en el Boletín No. 139, la sugerencia de una prueba rápida ha sido el foco de atención de los interesados en la activación. Los PR se abrieron a dos variantes de esto: PR # 21377 usando una variación de BIP9 y PR # 21392 usando una modificación que se convirtió en parte de BIP8. La principal diferencia técnica entre estos RP es cómo se determinaron sus puntos de inicio y finalización. PR # 21377 usa la mediana del tiempo pasado (MTP); PR # 21392 usa la altura del bloque actual.
MTP suele ser aproximadamente coherente entre la red principal de Bitcoin y sus diversas redes de prueba, como B. Testnet, el logotipo estándar y varios logotipos independientes. Esto permite que varias redes compartan un único conjunto de parámetros de activación, incluso si tienen alturas de bloque muy diferentes. Esto minimiza el esfuerzo de mantener a los usuarios de estas redes sincronizados con los cambios de consenso de la red principal.
Desafortunadamente, MTP puede ser manipulado fácilmente por una pequeña cantidad de mineros en pequeñas formas y por gran parte de la tasa de hash en grandes formas. También puede revertir accidentalmente a un momento anterior durante una reorganización de blockchain. En comparación, las alturas solo pueden disminuir en reorgia excepcional.1 Esto permite a los revisores en general hacer la suposición simplificadora de que la altura solo aumenta, lo que hace que sea más fácil analizar los mecanismos de activación basados en la altura que los mecanismos MTP.
Estas compensaciones entre las dos propuestas crearon, entre otras cosas, un callejón sin salida que algunos desarrolladores creían que impedía a las relaciones públicas obtener revisiones adicionales y, en última instancia, resultó en que una de ellas se fusionara con Bitcoin Core. Este impasse se resolvió a satisfacción de algunos participantes en la discusión de activación cuando los autores de los dos RP acordaron un compromiso:
- Usar MTP durante el tiempo en que los nodos comienzan a contar bloques que señalan la bifurcación suave, comenzando a contar al comienzo del siguiente período de retarget de 2,016 bloques después de la hora de inicio. Esto es idéntico a la forma en que los bits de la versión BIP9 y BIP148-UASF comenzaron a contar bloques para las bifurcaciones suaves que activaron.
- Utilice MTP también para el tiempo en el que los nodos ya no cuentan la señalización de bloque para una bifurcación suave que aún no se ha bloqueado. Sin embargo, a diferencia de BIP9, el tiempo de parada de MTP solo se verifica al final de los períodos de retarget en los que se llevó a cabo el recuento. Esto elimina la capacidad de que un intento de activación pase directamente del inicio al error, lo que simplifica el análisis y garantiza que haya al menos un período de bloqueo completo de 2,016 para que los mineros señalen la activación.
- Utilice la altura para el parámetro mínimo de activación. Esto simplifica aún más el análisis y sigue siendo compatible con el objetivo de que varias redes de prueba puedan compartir parámetros de activación. Si bien la altura puede ser diferente en estas redes, todas pueden usar una altura de activación mínima de 0 para activar dentro de la ventana definida por el MTP.
Club de revisión de relaciones públicas de Bitcoin Core
En esta sección mensual resumimos uno reciente Club de revisión de relaciones públicas de Bitcoin Core Reunión, destacando algunas preguntas y respuestas clave. Haga clic en una de las preguntas siguientes para ver un resumen de la respuesta de la reunión.
Implementación Introducción El estado de implementación es un PR (# 19438) de Anthony Towns que sugiere tres funciones auxiliares para facilitar el entierro de implementaciones futuras sin cambiar ninguna ruta de código que verifique el estado de activación de una bifurcación suave: DeploymentEnabled para probar si una implementación puede ser active, DeploymentActiveAt para verificar si una implementación debe forzarse en el bloque especificado, y DeploymentActiveAfter para saber si una implementación debe forzarse en el siguiente bloque. Los tres funcionan con implementaciones de bits enterradas y de versión.
La discusión del club de revisión se centró en comprender el cambio y sus posibles beneficios.
- ¿Cuáles son los beneficios de un PIB90 uso enterrado sobre un PIB9 ¿Provisión de bits de versión?
- Una implementación enterrada simplifica la lógica de implementación al reemplazar la prueba que gobierna la aplicación con simples verificaciones de altura, lo que reduce la deuda técnica asociada con la implementación de estos cambios de consenso.
- ¿Cuántos despliegues enterrados enumera este PR?
- Quinto: Altura en Coinbase, CLTV (CHECKLOCKTIMEVERIFY), firmas DER estrictas, CSV (OP_CHECKSEQUENCEVERIFY) y Segwit. Se enumeran en el enumerador de despliegues enterrados propuesto por el RP en src / sensus / params.h # L14-22. Se podría argumentar que las bifurcaciones blandas de la era Satoshi también están enterradas.
- ¿Cuántas disposiciones de bits de versión están definidas actualmente?
- Si la bifurcación suave de la raíz principal está activada y queremos enterrar este método de activación más adelante, ¿qué cambios tendrían que realizarse en Bitcoin Core cuando se fusione este PR?
- El cambio principal se simplificaría mucho en comparación con el código actual: mueva la línea DEPLOYMENT_TAPROOT del enumerador DeploymentPos al enumerador BuriedDeployment. Lo más importante es que no es necesario cambiar ninguna lógica de validación.
Cambios notables en el código y la documentación
Cambios notables esta semana en Bitcoin Core, C-flash, eclair, LND, Rayo de óxido, libsecp256k1, Interfaz de cartera de hardware (HWI), Bitcoin óxido, Servidor BTCPay, Sugerencias de mejora de Bitcoin (BIP), y Relámpagos.
- Bitcoin Core # 21594 agrega un campo de red al RPC getnodeaddresses para identificar nodos en diferentes redes (por ejemplo, IPv4, IPv6, I2P, cebolla). El autor también ha sugerido que esto forma la base de un parche futuro para getnodeaddresses, que toma un argumento de una red específica y solo devuelve direcciones en esa red.
- Bitcoin Core # 21166 mejora la transacción de firma con Wallet RPC y permite la firma de entradas en transacciones con otras entradas firmadas que no están en posesión de la billetera. Si se envió previamente una transacción al RPC que firmó entradas que no estaban en posesión de la billetera, los testigos de esas entradas se romperían en la transacción devuelta. Firmar entradas en transacciones con otras entradas firmadas puede ser útil en una variedad de situaciones, incluida la adición de entradas / salidas para aumentar la tarifa de transacción.
- LND # 5108 proporciona soporte para pagos Atomic Multipath sobre la marcha (también conocidos como AMP originales) utilizando Sendtoroute RPC de bajo nivel. Los AMP originales son intrínsecamente no interactivos (o espontáneos) ya que el donante selecciona todos los modelos a seguir. La selección del modelo de donante también forma parte de los pagos sobre la marcha de estilo keysend que se utilizaron para los pagos de ruta única sobre la marcha. Se espera que los RP de seguimiento pongan a disposición pagos reutilizables espontáneos para el RPC de envío de pagos principal.
- LND # 5047 permite que la billetera importe claves públicas mejoradas BIP32 (xpubs) y las use para recibir pagos a la billetera en cadena de LND. Combinado con el soporte recientemente actualizado de LND para PSBT (consulte el Boletín No. 118), LND puede actuar como una mera billetera para sus fondos fuera del canal. Por ejemplo, Alice puede importar el xpub de su billetera fría, depositar dinero en esa billetera con una dirección especificada por LND, pedirle a LND que abra un canal, firmar un PSBT que abre ese canal con su billetera fría, y luego LND cobra automáticamente Get devuelto a su billetera fría cuando el canal está cerrado. Esta última parte, devolver los fondos del canal cerrado a una billetera fría, puede requerir pasos adicionales, especialmente en canales cerrados que no cooperan. Sin embargo, este cambio da como resultado que LND sea en gran medida totalmente compatible con carteras de hardware y carteras frías compatibles con PSBT.
Notas al pie
- Si cada bloque de la cadena de bloques tuviera la misma prueba de trabajo individual (PoW), la cadena válida con el PoW más agregado también sería la cadena más larga, la cadena cuyo último bloque tuviera la mayor altura hasta la fecha. Sin embargo, el protocolo Bitcoin ajusta la cantidad de PoW que los nuevos bloques deben contener cada 2.016 bloques y aumenta o disminuye el trabajo que debe demostrarse para mantener el tiempo promedio entre bloques en alrededor de 10 minutos. Esto significa que una cadena con menos bloques puede tener más PoW que una cadena con más bloques.
Los usuarios de Bitcoin usan la cadena con más PoW, no más bloques, para ver si han recibido dinero. Si los usuarios ven una variación válida en esta cadena donde algunos de los bloques han sido reemplazados por otros bloques al final, usarán esta cadena reorganizada si contiene más PoW que su cadena actual. Debido a que la cadena Reorg puede tener menos bloques a pesar de más PoW acumulativo, la altura de la cadena puede disminuir.
Si bien este es un problema teórico, generalmente no es un problema práctico. Una disminución en la altura solo es posible si una reorganización cruza al menos uno de los límites de la reorientación entre un conjunto de 2,016 bloques y otro conjunto de 2,016 bloques. También requiere una reorganización con una gran cantidad de bloques o un cambio sustancial reciente en la cantidad de PoW requerido (lo que indica un aumento o disminución importante reciente en la tasa de hash, o una manipulación observable por parte de los mineros). En el contexto de BIP8, no creemos que un Reorg que está disminuyendo en altura tendrá más impacto en los usuarios durante una activación que un Reorg más típico. ↩
Usted puede encontrar el articulo original aquí.
Suscríbase directamente al boletín de Bitcoin Optech para recibir este contenido directamente en su bandeja de entrada todos los meses.
