Show HN: Timelock.dev – Envía un secreto al futuro usando cifrado de temporizador

Artículo original ↗ Discusión en Hacker News ↗

Timelock.dev / enfoque basado en drand

  • El servicio usa un conjunto distribuido de organizaciones (“League of Entropy”) que ejecutan nodos con criptografía de umbral: un subconjunto debe cooperar para liberar secretos en rondas especificadas.
  • Reutiliza un sistema público existente de aleatoriedad / firmas de umbral (drand); el timelock es una aplicación más que el objetivo de diseño principal.
  • Los valores después de la inicialización son deterministas; las fuentes iniciales de aleatoriedad (por ejemplo, lámparas de lava) solo siembran el sistema.

Confianza, descentralización e incentivos

  • Varios comentarios señalan que esto no es trustless: los usuarios deben confiar en que muchas organizaciones no coludan, no filtren claves antes de tiempo o no se desconecten.
  • Si la red se disuelve, los operadores planean borrar las claves, haciendo que los cifrados recientes sean permanentemente indecifrables; esto se presenta como una compensación entre privacidad y disponibilidad.
  • Algunos sostienen que hoy no existe un algoritmo de timelock completamente descentralizado; otros discrepan pero no ofrecen una alternativa concreta más allá de sugerir su publicación en revistas de criptografía.
  • Se discuten ideas que involucran incentivos financieros (fianzas, penalizaciones, denunciantes), pero surgen preocupaciones sobre sobornos, coordinación y el traslado de la confianza a los denunciantes.

Mecanismos alternativos de timelock

  • Se comentan métodos clásicos de time-lock:
    • “Romper en el futuro” mediante RSA/ECC o criptografía débil, confiando en avances futuros de cómputo o en la computación cuántica.
    • Rompecabezas de time-lock de Rivest–Shamir–Wagner: cuadrado modular secuencial, considerado no paralelizable, con ejemplos reales que tardan años en un solo núcleo.
    • Enfoques de cadenas hash y funciones de retardo verificable (VDF), donde la descodificación requiere una cantidad fija de trabajo secuencial; se critican porque hardware especializado puede acelerarlos enormemente.
  • Los enfoques con Ethereum/contratos inteligentes y estilo HTLC se consideran poco adecuados: pueden imponer el momento de las transacciones, pero no pueden ocultar datos a los validadores.

Física y propuestas de timelock físico

  • Varias ideas usan restricciones físicas:
    • Naves espaciales que transportan claves privadas y se sitúan muy lejos (por ejemplo, en órbita de Neptuno o en escape solar) para que la latencia de la velocidad de la luz imponga un límite inferior al tiempo de descifrado.
    • Analogías más simples incluyen contenedores de envío, claves enterradas, lugares peligrosos y acertijos estilo “geocache”.
  • Se reconoce que son teóricamente interesantes, pero económicamente dudosas y aún dependientes de confiar en el hardware y los procedimientos.

Casos de uso y problemas abiertos

  • Entre los usos sugeridos están los mensajes póstumos, los interruptores de persona muerta, el autocontrol digital (bloquearse a uno mismo el acceso a cuentas) y mecanismos DeFi.
  • Los escépticos preguntan por qué no simplemente auto-liberar una clave más tarde, o usar intermediarios más simples (por ejemplo, un notario).
  • Varios comentarios enfatizan un problema más profundo sin resolver: acordar de forma segura y sin confianza el tiempo transcurrido, dado que todos los esquemas actuales dependen de partes de confianza o de supuestos sobre el cómputo futuro.