BITCOIN OPTECH (25 de Mayo, 2022). Bitcoin Optech Newsletter #201 | Traducción al español de ConociendoCripto

 

Boletín Bitcoin Optech #201

25 de mayo de 2022

El boletín de esta semana resume un borrador de BIP para la retransmisión de paquetes y proporciona una descripción general de la inquietud sobre el Valor Extraíble del Minero (MEV) para el diseño de los convenios en Bitcoin. También se incluyen nuestras secciones regulares con el resumen de las principales preguntas y respuestas de Bitcoin Stack Exchange, anuncios de nuevos lanzamientos y candidatos a lanzamientos, y los cambios notables en el software de infraestructura de Bitcoin.

Noticias

• ● Propuesta de retransmisión de paquetes: Gloria Zhao publicó en la lista de correo de Bitcoin-Dev, un borrador de BIP para la retransmisión de paquetes. Esta es una característica que puede hacer que el aumento de tarifas de CPFP sea mucho más confiable para garantizar que una transacción secundaria pueda contribuir con tarifas para que se confirme su matriz. Varios protocolos de contrato, incluido LN, ya requieren un aumento de tarifas CPFP confiables, por lo que la retransmisión de paquetes mejoraría su seguridad y facilidad de uso. El borrador de BIP propone agregar cuatro nuevos mensajes al protocolo Bitcoin P2P:
• sendpackages permite que dos pares negocien las funciones de aceptación de paquetes que admiten.
• getpckgtxns solicita transacciones que se anunciaron previamente como parte de un paquete.
• pckgtxns proporciona transacciones que forman parte de un paquete.
• pckginfo1 proporciona información sobre un paquete de transacciones, incluido el número de transacciones, el identificador de cada transacción (wtxid), el tamaño total (peso) de las transacciones y las tarifas totales de la transacción. La tarifa del paquete se puede calcular dividiendo las tarifas por el peso.
• Además, los mensajes existentes inv y getdata se actualizan con un nuevo tipo de inventario (inv) MSG_PCKG1, que permite que un nodo le diga a sus pares que está dispuesto a enviar un mensaje tipo pckginfo1 sobre una transacción y que estos pares pueden usarla para solicitar ese mensaje tipo pckginfo1 para una determinada transacción.
  Usando estos mensajes, un nodo puede usar un mensaje tipo inv(MSG_PCKG1) para decirles a sus pares que podrían estar interesados ​​en recibir un pckginfo1 sobre una transacción. Por ejemplo,  como es una tarifa alta heredada de una transacción principal no confirmada de tarifa baja, los pares podrían ignorarla de otra manera. Si algún par solicita el mensaje tipo pckginfo1, puede usar la información en el mensaje para determinar si realmente está interesado en el paquete y conocer los wtxid de cualquier transacción que necesite descargar para validar la tarifa alta heredada. Las transacciones reales pueden solicitarse con el mensaje getpckgtxns y recibirse en el mensaje pckgtxins.
• Aunque el borrador del BIP se enfoca solo en el protocolo, el correo electrónico de Zhao brinda contexto adicional, describe brevemente los diseños alternativos que se encontraron deficientes y vincula a una presentación con detalles adicionales.

• Debate sobre el valor extraíble del minero: el desarrollador /dev/fd0 publicó en la lista de correo de Bitcoin-Dev un resumen de la novena reunión del IRC sobre OP_CHECKTEMPLATEVERIFY (CTV). Entre otros temas discutidos durante esa reunión, Jeremy Rubin enumeró varias preocupaciones que escuchó a la gente expresar sobre convenios recursivos (que CTV no habilita). Una de esas preocupaciones era crear  el Valor Extraíble del Minero (MEV) significativamente más allá de la cantidad disponible al ejecutar un algoritmo de selección de transacciones simple como el proporcionado por Bitcoin Core.
  MEV se ha convertido en una preocupación particular en Ethereum y los protocolos relacionados, donde el uso de protocolos de negociación pública en cadena permite a los mineros adelantar operaciones. Por ejemplo, imagine que las siguientes dos transacciones no confirmadas están disponibles para minar en el siguiente bloque:

• Alice vende el activo x a Bob por 1 ETH
• Bob vende x a Carol por 2 ETH (Bob obtiene 1 ETH en ganancias)

Si esos dos intercambios se realizan utilizando un protocolo de intercambio en cadena pública, un minero puede eliminar a Bob de la transacción. Por ejemplo:

• Alice vende activo x a Miner Mallory por 1 ETH
• Miner Mallory vende x a Carol por 2 ETH (Mallory obtiene 1 ETH en ganancias; Bob no obtiene ganancias)

Obviamente esto es un problema para Bob, pero también crea varios problemas para la red. El primer problema es que los mineros necesitan encontrar oportunidades para el MEV. Eso es trivial en el ejemplo simple anterior, pero solo se pueden encontrar oportunidades más complejas a través de algoritmos computacionalmente intensivos. La cantidad de valor que se puede encontrar mediante una cierta cantidad de cómputo es independiente del hashrate de cada minero, por lo que dos mineros pueden unirse para reducir a la mitad la cantidad de dinero que necesitan gastar en cómputo para capturar el MEV, lo que produce una economía de escala que fomenta centralización de la minería y que puede dejar la red más vulnerable a la censura de transacciones. Un informe por BitMex Research afirma que un servicio centralizado que negocia este tipo de transacciones de MEV estaba siendo utilizado por el 90% del hashrate de Ethereum en el momento en que se escribió el informe. Para obtener los máximos rendimientos, ese servicio podría cambiarse para desalentar las transacciones mineras competidoras, otorgándole efectivamente el poder de censurar transacciones si fue utilizado por el 100 % de los mineros (o si fue utilizado por más del 50 % de los mineros y se le permitió participar en la reorganización de la cadena de bloques).
Un segundo problema es que, incluso si Mallory produce un bloque que captura el 1 ETH de MEV, cualquier otro minero puede producir un bloque alternativo que capture el MEV por sí mismo. Esta presión para volver a minar bloques exacerba la presión las tarifas de los francotiradores (fee sniping) que, en el peor de los casos, puede hacer que los puntajes de confirmación sean inútiles para determinar la finalidad de la transacción, eliminando la capacidad de usar la prueba de trabajo para proteger la red.
El uso de UTXO por parte de Bitcoin en lugar de cuentas de estilo Ethereum hace que sea más difícil implementar los tipos de protocolos que son particularmente vulnerables a MEV. Sin embargo, en la reunión de CTV, Jeremy Rubin señaló que los convenios recursivos facilitan la implementación de sistemas basados ​​en cuentas además de los UTXO de Bitcoin y, por lo tanto, aumentan la posibilidad de que MEV se convierta en una preocupación futura importante para el diseño del protocolo de Bitcoin.
En respuesta al resumen de /dev/fd0 para la lista de correo, el desarrollador ZmnSCPxj sugirió que solo adoptemos mecanismos que fomenten protocolos diseñados para la máxima privacidad en la cadena. Esa privacidad negaría a los mineros la información necesaria para realizar el MEV. Al momento de escribir este boletín, no se recibieron más comentarios en la lista de correo pero, a partir de menciones en Twitter y en otros lugares, vemos evidencia de que los desarrolladores están considerando cada vez más el impacto del MEV en el diseño del protocolo Bitcoin.

Preguntas y respuestas seleccionadas de Bitcoin Stack Exchange

Bitcoin Stack Exchange es uno de los primeros lugares en los que los contribuyentes de Optech buscan respuestas a sus preguntas, o cuando tenemos unos momentos libres para ayudar a los usuarios curiosos o confundidos. En esta sección mensual, destacamos algunas de las preguntas y respuestas más votadas publicadas desde nuestra última actualización.

• ● ¿Cuánta entropía se pierde al alfabetizar tus mnemónicos? HansBKK se pregunta cuánta entropía se pierde si se ordenan alfabéticamente frases semilla de 12 o 24 palabras. Pieter Wuille desglosa una serie de métricas que incluyen el número de posibilidades, la entropía y el número medio de intentos de fuerza bruta en 12 y 24 palabras y también señala consideraciones para la repetición de palabras.
• ● Firma Taproot con PSBT: ¿Cómo determinar el método de firma? Guggero enumera tres formas de proporcionar una firma Schnorr válida en taproot: un gasto de ruta de clave con compromiso BIP86 , un gasto de ruta de clave con un compromiso con la raíz del árbol de secuencias de comandos y un gasto de ruta de secuencia de comandos. Andrew Chow confirma que el esquema de Guggero, de cómo se indica, cada método de firma está dentro de un PSBT .
• ● ¿Cómo podrían los bloques más rápidos causar la centralización de la minería? Murch se centra en por qué los tiempos de bloque más cortos provocarían reorganizaciones más frecuentes y cómo beneficiarían a los mineros más grandes en el contexto de la latencia de propagación de bloques.
• ● ¿Qué significa «métrica de desperdicio» en el contexto de la selección de monedas? Murch explica que, al gastar, Bitcoin Core utiliza una heurística de métrica de desperdicio como una «medida de las tarifas para la entrada establecida en la tarifa actual en comparación con gastar las mismas entradas en la tarifa hipotética a largo plazo». Esta heurística se utiliza para evaluar los candidatos de selección de monedas que resultan de los algoritmos Branch and Bound (BnB), Single Random Draw (SRD) y de mochila.
• ● ¿Por qué no es OP_CHECKMULTISIG compatible con la verificación por lotes de firmas Schnorr? Pieter Wuille señala que dado OP_CHECKMULTISIG que no indica qué firmas van con qué claves públicas, es incompatible con la verificación por lotes y que motivó el nuevo código de operación de BIP342 OP_CHECKSIGADD.

Lanzamientos y candidatos a lanzamientos

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

• ● Core Lightning 0.11.1 es una versión con corrección de errores que elimina un problema que causaba que las transacciones de cierre de canales unilaterales se transmitieran innecesariamente y un problema apartado que provocaba el bloqueo del nodo C-Lightning.
• ● LND 0.15.0-beta.rc3 es una versión candidata para la próxima versión principal de este popular nodo LN.

Cambios notables en el código y en 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 .

• ● Bitcoin Core n.° 20799 elimina la compatibilidad con la versión uno de la retransmisión de bloques compactos , lo que permitía una retransmisión de bloques y transacciones más rápida y con mayor eficiencia de ancho de banda a pares que no admitían segwit. La versión dos permanece habilitada y permite una transmisión rápida y eficiente a los pares compatibles con segwit.
• ● LND #6529 agrega un constrainmacaroon comando que permite restringir los privilegios de un macaroon ya creado (token de autenticación). Anteriormente, cambiar los privilegios requería crear un nuevo macaroon.
• ● LND #6524 aumenta el número de versión del esquema de copia de seguridad aezeed de LND de 0 a 1. Esto le indicará al futuro software que recupere fondos de una copia de seguridad aezeed que deben buscar los resultados taproot recibidos en la billetera.

Agradecimientos

Además de nuestros contribuyentes habituales del boletín, agradecemos en particular a Jeremy Rubin esta semana por proporcionar detalles adicionales sobre MEV. Seguimos siendo los únicos responsables de cualquier error u omisión.