Show HN: Timelock.dev – Envie um segredo para o futuro usando criptografia timelock
Timelock.dev / abordagem baseada em drand
- O serviço usa um conjunto distribuído de organizações (“League of Entropy”) executando nós com criptografia de limiar: um subconjunto precisa cooperar para liberar segredos em rodadas especificadas.
- Ele reaproveita um sistema público existente de aleatoriedade / assinatura de limiar (drand); timelock é uma aplicação, não o objetivo central do design.
- Os valores após a inicialização são determinísticos; fontes de aleatoriedade iniciais (por exemplo, lâmpadas de lava) apenas inicializam o sistema.
Confiança, descentralização e incentivos
- Vários comentários observam que isso não é trustless: os usuários precisam confiar em muitas organizações para não coludirem, vazarem chaves antecipadamente ou ficarem offline.
- Se a rede se desfizer, os operadores planejam apagar as chaves, tornando os ciphertexts recentes permanentemente indecifráveis; isso é apresentado como uma troca entre privacidade e disponibilidade.
- Alguns argumentam que hoje não existe um algoritmo timelock totalmente descentralizado; outros discordam, mas não apresentam uma alternativa concreta além de sugerir a publicação em veículos de criptografia.
- Ideias envolvendo incentivos financeiros (garantias, penalidades, whistleblowers) são discutidas, mas surgem preocupações sobre suborno, coordenação e deslocamento da confiança para whistleblowers.
Mecanismos alternativos de timelock
- Métodos clássicos de time-lock são discutidos:
- “Quebrar no futuro” via RSA/ECC ou criptografia fraca, dependendo de avanços futuros em computação ou quântica.
- Time-lock puzzles de Rivest–Shamir–Wagner: multiplicações modulares sequenciais, consideradas não paralelizáveis, com exemplos reais levando anos em um único núcleo.
- Abordagens com hash chains e verifiable delay functions (VDFs), em que a decriptação requer uma quantidade fixa de trabalho sequencial; criticadas porque hardware especializado pode acelerar isso enormemente.
- Abordagens com Ethereum/contratos inteligentes e do tipo HTLC são consideradas inadequadas: podem impor o timing de transações, mas não conseguem ocultar dados dos validadores.
Física e propostas físicas de timelock
- Vários experimentos mentais usam restrições físicas:
- Naves espaciais carregando chaves privadas colocadas muito longe (por exemplo, em órbita de Netuno ou em fuga do Sol) para que a latência da velocidade da luz imponha um limite inferior ao tempo de decriptação.
- Análogos mais simples incluem contêineres de transporte, chaves enterradas, locais perigosos e quebra-cabeças no estilo “geocache”.
- Reconhece-se que são teoricamente interessantes, mas economicamente duvidosos e ainda dependentes de confiança em hardware e procedimentos.
Casos de uso e problemas em aberto
- Entre os usos sugeridos estão mensagens póstumas, dead-person switches, autocontrole digital (bloquear o próprio acesso a contas) e mecanismos de DeFi.
- Céticos questionam por que não simplesmente liberar uma chave mais tarde por conta própria, ou usar intermediários mais simples (por exemplo, um notário).
- Vários comentários destacam um problema mais profundo e ainda não resolvido: concordar de forma segura e trustless sobre o tempo decorrido, dado que todos os esquemas atuais dependem de partes confiáveis ou de suposições sobre computação futura.