Show HN: Timelock.dev – टाइमलॉक एन्क्रिप्शन का उपयोग करके एक रहस्य को भविष्य में भेजें

Timelock.dev / drand-आधारित दृष्टिकोण

• सेवा संगठनों के एक वितरित समूह (“League of Entropy”) का उपयोग करती है, जो threshold cryptography वाले नोड्स चलाते हैं: निर्धारित राउंड पर रहस्य जारी करने के लिए एक उपसमुच्चय को सहयोग करना होता है।
• यह एक मौजूदा सार्वजनिक randomness / threshold-signature सिस्टम (drand) का पुन: उपयोग करती है; timelock मूल डिज़ाइन लक्ष्य नहीं, बल्कि एक अनुप्रयोग है।
• initialization के बाद के मान deterministic होते हैं; प्रारंभिक randomness स्रोत (जैसे lava lamps) केवल सिस्टम को seed करते हैं।

Trust, decentralization, और incentives

• कई टिप्पणियों में कहा गया कि यह trustless नहीं है: उपयोगकर्ताओं को भरोसा करना होगा कि कई संगठन आपस में collude नहीं करेंगे, keys जल्दी leak नहीं करेंगे, या offline नहीं हो जाएंगे।
• यदि नेटवर्क भंग हो जाता है, तो operators keys delete करने की योजना रखते हैं, जिससे हालिया ciphertexts स्थायी रूप से undecryptable हो जाएंगे; इसे privacy बनाम availability tradeoff के रूप में प्रस्तुत किया गया है।
• कुछ लोग तर्क देते हैं कि आज पूरी तरह decentralized algorithmic timelock मौजूद नहीं है; अन्य असहमत हैं, लेकिन crypto venues में publication सुझाने के अलावा कोई concrete विकल्प नहीं देते।
• वित्तीय incentives (bonds, penalties, whistleblowers) वाले विचारों पर चर्चा होती है, लेकिन bribery, coordination, और trust को whistleblowers की ओर स्थानांतरित करने की चिंताएँ उठाई जाती हैं।

वैकल्पिक timelock mechanisms

• शास्त्रीय time-lock तरीकों पर चर्चा की जाती है:
  • “भविष्य में तोड़ना” RSA/ECC या weak crypto के माध्यम से, जो भविष्य की computing या quantum advances पर निर्भर करता है।
  • Rivest–Shamir–Wagner time-lock puzzles: sequential modular squaring, जिसे non-parallelizable माना जाता है, और वास्तविक दुनिया के उदाहरण single core पर वर्षों लेते हैं।
  • Hash-chain approaches और verifiable delay functions (VDFs), जहाँ decryption के लिए निश्चित मात्रा में sequential work चाहिए; आलोचना यह है कि specialized hardware इन्हें बहुत तेज़ कर सकता है।
• Ethereum/smart-contract और HTLC-शैली के approaches को खराब विकल्प माना जाता है: वे transactions का timing लागू कर सकते हैं, लेकिन validators से data छिपा नहीं सकते।

भौतिकी और भौतिक timelock प्रस्ताव

• कई thought experiments भौतिक बाधाओं का उपयोग करते हैं:
  • private keys ले जाने वाले spacecraft को बहुत दूर रखना (जैसे Neptune orbit या solar escape) ताकि speed-of-light latency decryption time पर न्यूनतम सीमा लागू करे।
  • सरल analogues में shipping containers, buried keys, खतरनाक स्थान, और “geocache” शैली की puzzles शामिल हैं।
• इन्हें सैद्धांतिक रूप से रोचक लेकिन आर्थिक रूप से संदिग्ध और फिर भी hardware तथा प्रक्रियाओं पर भरोसा करने वाला माना गया है।

Use cases और open problems

• सुझाए गए उपयोगों में posthumous messages, dead-person switches, digital self-control (खुद को accounts से lock out करना), और DeFi mechanisms शामिल हैं।
• संदेह करने वाले पूछते हैं कि बाद में key स्वयं क्यों न जारी की जाए, या सरल intermediaries (जैसे notary) का उपयोग क्यों न किया जाए।
• कई टिप्पणियाँ एक गहरी अनसुलझी समस्या पर जोर देती हैं: elapsed time पर securely और trustlessly सहमति कैसे बनाई जाए, जबकि सभी मौजूदा schemes या तो trusted parties पर या भविष्य की computation संबंधी assumptions पर निर्भर करती हैं।