No se encontraron resultados
La página solicitada no pudo encontrarse. Trate de perfeccionar su búsqueda o utilice la navegación para localizar la entrada.
BITCOIN OPTECH (20 de abril, 2022). Bitcoin Optech Newsletter #196 | Traducido al español por Mamifero.
La newsletter de esta semana resume un debate sobre cómo permitir el intercambio de claves con criptografía resistente a la computación cuántica (quantum-safe) en Bitcoin e incluye nuestras secciones habituales con descripciones de cambios significativos en servicios y aplicaciones, nuevas versiones y versiones candidatas, y el popular software de infraestructura de Bitcoin.
Intercambio de claves resistente a la computación cuántica: Erik Aronesty inició un hilo en la lista de correo de Bitcoin-Dev sobre la resistencia cuántica sobre como mantener Bitcoin seguro en caso de que se desarrolle una computadora cuántica. Se prevé que las computadoras cuánticas puedan generar firmas correspondientes a las claves públicas de Bitcoin sin conocer la clave privada original, lo que permitiría que alguien que posea una computadora cuántica gaste dinero que pertenece a otras personas. Pocos investigadores de seguridad creen que las computadoras cuánticas supongan una amenaza a corto plazo, pero puede merecer la pena examinar cualquier método que las descarte como una preocupación sin perturbar significativamente los usos existentes de Bitcoin.
Aronesty sugirió permitir que los usuarios reciban pagos a una clave pública asegurada por un algoritmo resistente a la computación cuántica, puede que asegurando también los bitcoins con una clave pública de Bitcoin ya existente, de modo que se tuviera que encontrar un problema explotable en ambos algoritmos antes de que se pudieran robar bitcoins como resultado de un fallo de la clave criptográfica. Esto requeriría un soft fork y probablemente reduciría la cantidad máxima de transacciones útiles por bloque; dado que las firmas quantum-safe ocupan más espacio que las firmas ECDSA y schnorr que se utilizan actualmente en Bitcoin.
Lloyd Fournier propuso, en su lugar, que se desarrolle un esquema estandarizado que permita que las salidas taproot se consoliden con claves públicas resistentes a la computación cuántica además de sus claves públicas schnorr habituales. Es posible que las claves públicas resistentes a la computación cuántica no se puedan gastar actualmente, pero si los usuarios de Bitcoin se preocuparan más por una inminente computadora cuántica, podrían optar por una bifurcación blanda en un cambio de consenso que requiriera el uso de rutas de gasto resistentes a la computación cuántica. Fournier también sugirió que los detalles sobre el problema y las posibles soluciones podrían describirse para los investigadores y desarrolladores actuales y futuros en BitcoinProblems.org.
Cambios en servicios y aplicaciones
En este artículo mensual, destacamos actualizaciones interesantes para carteras y servicios de Bitcoin.
Nuevas versiones y versiones candidatas para proyectos populares de infraestructura de Bitcoin. Por favor, considere la posibilidad de actualizar a las nuevas versiones o de ayudar a probar las versiones candidatas.
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 #5810 implementa la compatibilidad de envío para metadatos del pago. Si una factura incluye metadatos de pago, un remitente codificará esos datos como un registro TLV para el receptor. Se trata de un paso más hacia el desbloqueo de las facturas sin estado, que permite a un receptor renunciar a almacenar las facturas mostradas a los posibles remitentes, regenerándolas cuando llega un intento de pago al receptor.
LND # 6212 evita que los HTLC se envíen a través del interceptor HTLC a un proceso externo si aceptar el HTLC requiere que el canal onchain se cierre inmediatamente o en un breve período de tiempo. Esto puede suceder si el vencimiento del HTLC está cerca del bloque visto más recientemente.
LND #6024 agrega un parámetro de búsqueda de ruta ‘time_pref’ que se puede usar para cambiar la compensación entre el enrutamiento a través de canales que tengan más probabilidades de retransmitir el pago (más rápido) y aquellos que cobran menos tarifas.
LND #6385 elimina la opción de usar el formato de pago ‘onion’ del protocolo LN original al construir nuevos pagos, lo que requiere que el usuario cree ahora un formato ‘onion’de estilo TLV. Los ‘onion’ TLV se agregaron al protocolo en 2019 (ver Newsletter 55) y han sido las predeterminadas en todo el software de LN durante más de dos años. Otro software de LN ha realizado cambios similares para eliminar la compatibilidad con el formato onion más antiguo, como la actualización de Core Lightning publicada en la Newsletter 158.