Bitcoin Optech Newsletter #197

BITCOIN OPTECH (27 de abril, 2022). Bitcoin Optech Newsletter #197 | Traducido al español por IT4Bitcoin.

 

Boletín Bitcoin Optech #197

Abr 27, 2022

El boletín de esta semana resume la discusión sobre la activación de OP_CHECKTEMPLATEVERIFY e incluye nuestras secciones regulares que destacan las principales preguntas y respuestas de Bitcoin Stack Exchange, y por último  las nuevas versiones de software infraestructura de Bitcoin y sus release candidates (candidato a próximo lanzamiento), se adjuntan los cambios y correcciones  respecto a su actual versión.

Noticia

• ● Discusión sobre la activación de CTV: Jeremy Rubin publicó en la lista de correo de Bitcoin-Dev su plan para lanzar un software que permitirá a los mineros comenzar a señalar si tienen la intención de hacer cumplir  las reglas BIP119 para el  código operativo OP_CHECKTEMPLATEVERIFY (CTV) propuesto. Si el 90% de los bloques señalan positivamente durante cualquiera de los próximos períodos de ajuste de dificultad de 2.016 bloques (dos semanas), cualquiera que use el software de Rubin comenzará a hacer cumplir las reglas de CTV a partir de principios de noviembre.

Rubin describió en detalle múltiples razones según las cuales los usuarios de Bitcoin podrían desear activar CTV:

• ● Consistencia: CTV tiene una especificación e implementación estables
• ● Popularidad: una serie de personas y organizaciones que son bien conocidas por la comunidad Bitcoin apoyan a CTV
• ● Viabilidad: no parece haber ninguna objeción que afirme que CTV viola las propiedades altamente deseadas de Bitcoin
• ● Conveniencia: CTV proporciona las características que los usuarios desean, como covenans (convenios) y vaults (bovedas).

Más de una docena de personas respondieron en la lista de correo, ya sea directamente al correo electrónico de Rubin o en otros hilos. No podemos resumir todas las respuestas notables, pero sí algunos de los comentarios que encontramos particularmente interesantes:

• ● Anthony Towns analizó las transacciones CTV en la signtet. Casi todos parecían haber sido construidas con el mismo software (Sapio), lo que posiblemente indica una pobre muestra de la interoperativilidad de CTV con los softwares actuales. Además, señaló que cambiar las reglas de consenso para agregar una nueva característica crea riesgos para todos los usuarios de Bitcoin, incluso para las personas que no planean usar la nueva función. Finalmente concluye que es importante proporcionar a los no adoptantes evidencia clara de que  BIP119  será lo suficientemente beneficioso para el conjunto del ecosistema y que eso “justifica el riesgo». Después de esta publicación, se realizó una experimentación adicional en la red Signet.
•  Matt Corallo también argumentó que cambiar el consenso puede crear fricciones significativas, por lo que solo debemos intentar soft forks cuando estamos seguros de que una propuesta optimiza su alcance. En el caso de los convenants, Corallo quiere ver «un diseño más flexible, más útil y, con suerte, más privado». Más tarde dijo: «por lo que he visto, no ha quedado claro que CTV sea realmente una buena opción».
• ● Russell O’Connor señaló en #bitcoin-wizards IRC que una de las formas propuestas de usar CTV no lograba interactuar debidamente con ciertos formatos de dirección de Bitcoin existente como base58check, bech32 o bech32m. Ese método de usar CTV a través de bare script (un script que aparece directamente en un scriptPubKey) requeriría que los desarrolladores de carteras solo usen bare CTV con sus propias direcciones o escriban herramientas especiales para lograr incorporar direcciones no propias. Alternativamente, las carteras que desean usar CTV para algunas aplicaciones (como bóvedas) podrían recibir pagos a una dirección P2TR que se sea compatible para usar bare CTV más tarde.
• La discusión de O’Connor sobre la limitación de direcciones fue mencionada en la lista por Towns. O’Connor respondió con detalles adicionales y también señaló que, si el soporte para bare CTV no fuera parte de la especificación BIP119 de CTV, abogaría por un diseño diferente que sea más simple y más componible (más fácil de combinar con otros opcodes para producir scripts útiles), aunque, más allá de eso, preferiría el diseño de OP_TXHASH más general  (ver Boletín # 185). Rubin respondió con varios contrapuntos.
• ● David Harding transmitió la preocupación de que CTV podría no recibir mucho uso a largo plazo, ya sea por falta de adopción o porque los usuarios elijan alternativas por afuera de la capa de consenso. Esto dejaría a los desarrolladores de código de consenso con la carga perpetua de mantener el código CTV que no estaría aportando valor pero que todavía debería ser analizado en sus posibles interacciones con los cambios de consenso propuestos posteriormente. Harding sugirió agregar temporalmente CTV a Bitcoin durante cinco años, recopilar datos durante ese tiempo sobre cómo la gente lo usó y luego deshabilitarlo automáticamente a menos que los usuarios de Bitcoin dentro de cinco años decidieran que valía la pena mantenerlo. Ningún encuestado estaba a favor de este enfoque, y la mayoría de ellos argumentaban que los costos de este enfoque eran demasiado altos o que los beneficios eran demasiado bajos. También se señaló que cualquier persona en el futuro que quisiera validar completamente los bloques creados mientras CTV estaba activo seguiría necesitando el código de validación de CTV, por lo que el código de CTV podría necesitar mantenerse a perpetuidad incluso si el código para utilizarlo se deshabilitara después de cinco años.
• ● Antoine «Darosior» Poinsot solicitó activar una versión ligeramente modificada de BIP118 SIGHASH_ANYPREVOUT (APO) en lugar de CTV, o al menos antes de la activación de CTV. La modificación a APO le permitiría emular las capacidades de CTV, aunque a un costo mayor para algunas aplicaciones. La activación de APO también lo haría disponible para su uso originalmente previsto de habilitar la  capa Eltoo propuesta  para LN, lo que permitiría actualizaciones de estado de canal LN más eficientes y posiblemente más seguras.
• ● James O’Beirne sugirió que su diseño simple-vault (bóveda simple) basado en CTV  podría usarse como punto de referencia para evaluar diferentes diseños de convenants debido a su simplicidad y su capacidad, en su opinión, para mejorar significativamente la seguridad de muchos usuarios de Bitcoin si fuera utilizable en producción. Darosior fue el primero en aceptar el desafío, portando el código de bóveda simple de CTV a una implementación de SIGHASH_ANYPREVOUT.

La discusión se mantuvo muy activa en la lista de correo en el momento en que se estaba escribiendo este resumen. Varias conversaciones interesantes sobre CTV y tecnología de pacto también aparecieron en Twitter, IRC, chats de Telegram y en otros lugares. Alentamos a los participantes en esas conversaciones a compartir cualquier información importante con la lista de correo de Bitcoin-Dev.

Después de las discusiones resumidas anteriormente, Jeremy Rubin anunció que no lanzará inmediatamente compilaciones binarias del software para permitir la activación de CTV. En su lugar, evaluará los comentarios recibidos y trabajará con otros partidarios de CTV para posiblemente proponer un plan de activación revisado. Optech proporcionará actualizaciones sobre el tema en futuros boletines.

Preguntas y respuestas seleccionadas de Bitcoin Stack Exchange

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

• ● ¿Cómo se eligió el punto G del generador en la curva secp256k1?  Pieter Wuille señala que, si bien la razón exacta detrás de la elección del punto G del generador constante no se conoce públicamente, una propiedad inusual puede insinuar su construcción.
• ● ¿Cuál es el tamaño máximo y realista de la carga útil del mensaje P2P?  0xb10c pregunta si hay un mensaje P2P válido de MAX_SIZE (32MB). Pieter Wuille explica que MAX_PROTOCOL_MESSAGE_LENGTH (4 MB, aumentado de 2 MB como parte de segwit) es lo que realmente restringe el tamaño de los mensajes entrantes para evitar ataques de denegación de servicio.
• ● ¿Hay evidencia que prueba la supuesta infrecuencia actual de los “stale blocks” (bloques obsoletos)?  Lightlike hace referencia a un gráfico histórico de los tiempos de propagación de bloques del  sitio web de estadísticas de KIT y señala  el compact block relay (BIP152), implementado inicialmente en # 8068, como un factor significativo a la disminución de la  frecuencia de bloques obsoletos a  lo largo del tiempo.

● ¿El campo de entrada de una transacción de coinbase tiene un campo VOUT?  Pieter Wuille describe los requisitos para la entrada de una transacción de coinbase: el hash de prevout debe ser      00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

Lanzamientos y candidatos a lanzamiento

Nuevos lanzamientos y candidatos de lanzamiento para proyectos populares de infraestructura de Bitcoin. Considere la posibilidad de actualizar a nuevas versiones o ayudar a probar los candidatos a versiones.

• ● Bitcoin Core 23.0 es la próxima versión principal de este software de nodo completo predominante. Las notas de la versión enumeran múltiples mejoras, incluidas  los descriptors de forma predeterminada para las nuevas carteras. Tambien la recepción de direcciones bech32m utilizando taproot.
• ● Core Lightning 0.11.0 es el lanzamiento de la próxima versión principal de este popular software de nodo LN. Entre otras características y correcciones de errores se incluye la admisión de múltiples canales activos al mismo nodo y el pago de facturas sin invoice.
• ● Rust-Bitcoin 0.28 es la última versión de esta biblioteca de Bitcoin. El cambio más significativo es agregar soporte para taproot y mejorar las API relacionadas, como las de PSBT. Otras mejoras y correcciones de errores se describen en sus notas de la versión.

Cambios notables 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 (BIPs) y Lightning BOLTs.

• ● LND #5157 agrega una opción de inicio –addpeer que abre una conexión del mismo nivel con el nodo proporcionado.
• ● LND #6414 comienza el soporte publicitario para pagos espontáneos de keysend  cuando está habilitado. LND ha admitido keysend desde 2019, pero inicialmente se implementó sin forma de que los nodos anunciaran que lo admitían. Las implementaciones de keysend en otro software de nodo LN anunciaron soporte en sus anuncios de nodos y este PR fusionado para LND replica eso.