Lightning Watchtower भुगतान चैनल के उपयोगकर्ता की ओर से Bitcoin की श्रृंखला पर नजर रखने वाली सेवा है। दूसरा पक्ष रद्द स्थिति प्रकाशित करे, तो यह पहले से तैयार धन-वापसी लेनदेन प्रसारित कर सकती है। नोड बंद होने पर इससे सुरक्षा मिलती है, लेकिन सही डेटा, कनेक्शन और समय पर पुष्टि जरूरी हैं। नोड वह प्रोग्राम है जो चैनल संभालता है और Lightning भुगतान प्रोसेस करता है; कनेक्शन कटने पर वह दूसरे प्रतिभागियों से संपर्क नहीं कर सकता।
आना और पावेल का एक भुगतान चैनल है: पैसा Bitcoin में साथ लॉक है और Lightning भुगतान से उसका बँटवारा बदलता है। पावेल आना को भुगतान करता है, दोनों नए बैलेंस स्वीकार करते हैं और पुरानी स्थिति रद्द कर देते हैं। इसके बाद आना का इंटरनेट बंद हो जाता है। पावेल पुरानी स्थिति प्रकाशित करे, तो वह पहले खर्च कर चुका पैसा वापस लेने की कोशिश कर सकता है। इस परिस्थिति के लिए आना Lightning Watchtower की मदद ले सकती है। उसका नोड रद्द स्थितियों की सुरक्षा के लिए एन्क्रिप्टेड डेटा पहले ही भेज देता है। सेवा श्रृंखला में संबंधित लेनदेन पहचान ले, तो आना के ऑनलाइन आए बिना धन-वापसी लेनदेन प्रसारित कर सकती है। वह आना की ओर से भुगतान नहीं करती और उसके नोड का कनेक्शन भी ठीक नहीं करती। [1] [8]
पैसे के हर सहमत बँटवारे की एक commitment transaction होती है: हस्ताक्षरित लेनदेन, जिससे Bitcoin की श्रृंखला पर चैनल बंद किया जा सकता है। स्थिति बदलते समय दोनों पक्ष ऐसी जानकारी साझा करते हैं जिससे पिछली, अब रद्द स्थिति प्रकाशित करने पर दंड लागू किया जा सके। यहाँ हम इसी दंड-आधारित चैनल मॉडल की बात कर रहे हैं। पावेल वर्तमान वैध स्थिति इस्तेमाल करे, तो आना के ऑफलाइन रहते भी एकतरफा चैनल बंद कर सकता है। Watchtower का काम उस बंद होने को रोकना नहीं है। वह किसी खास रद्द स्थिति पर कार्रवाई करता है, चाहे पावेल ने उसे जानबूझकर प्रकाशित किया हो या पुराने बैकअप से गलती से। निर्णायक बात स्थिति का रद्द होना है, लेनदेन का पुराना होना नहीं। [1] [8]
Seed Phrase शब्दों के रूप में लिखा बैकअप है, जिससे भुगतान पर हस्ताक्षर करने वाली निजी कुंजियाँ बहाल की जा सकती हैं। LND, Lightning नोड चलाने वाले प्रोग्रामों में से एक है। आना सेवा को अपनी Seed Phrase या पूरे वॉलेट की निजी कुंजियाँ नहीं देती। वह किसी खास कार्रवाई के लिए सीमित डेटा और हस्ताक्षर देती है; LND में इस पैकेट का नाम JusticeKit है। धन-वापसी लेनदेन, जिसे justice transaction कहते हैं, पहले से तैयार शर्तों के अनुसार सुरक्षित पैसा लौटाता है। इससे Watchtower को आना के दूसरे सिक्के मनमाने ढंग से खर्च करने का अधिकार नहीं मिलता। सेवा को इनाम न देने वाले मॉडल में सुरक्षित राशि से Bitcoin लेनदेन की फीस काटी जाती है। कोड में टावर को इनाम देने वाले प्रकार भी हैं, लेकिन केवल उनका होना यह नहीं दिखाता कि कोई खास संचालक सशुल्क सेवा देता है। [3] [4] [5]
Watchtower तभी मदद कर सकता है जब जरूरी डेटा सचमुच उसे मिला हो। सेटिंग में उसका पता भरना या भेजने की कतार में काम दिखना पर्याप्त नहीं है। क्लाइंट को, यानी आना के नोड के उस हिस्से को जो टावर से संपर्क करता है, यह पुष्टि मिलनी चाहिए कि टावर को अपडेट प्राप्त हुआ है। कनेक्शन टूट सकता है, session कहलाने वाले भंडारण समझौते की क्षमता भर सकती है या बैकअप अस्वीकार हो सकता है। इसलिए आना को न पहुँचे अपडेट और त्रुटियाँ भी देखनी चाहिए। स्वीकार किए गए डेटा से भी सफलता की गारंटी नहीं मिलती: टावर सही श्रृंखला देखता रहे और उसकी प्रतिक्रिया समय पर किसी ब्लॉक में पुष्ट होनी चाहिए। [6] [8]
आना अपना उपकरण खो दे, तो उसे Watchtower से बहाल नहीं करेगी। सेवा रद्द स्थितियों के दुरुपयोग पर नजर रखती है; वह वॉलेट बहाल नहीं करती और चोरी हुई कुंजियों की समस्या नहीं सुलझाती। LND चैनल रिकवरी के लिए Static Channel Backup (SCB) इस्तेमाल करता है। वॉलेट के seed के साथ यह चैनल बंद करके पैसा वापस पाने में मदद करता है, न कि नोड जहाँ रुका था वहीं से ठीक उसी स्थिति में चलाने में। SCB हर अपडेट की प्रति या टावर को भेजा गया एन्क्रिप्टेड पैकेट नहीं है। सही रिकवरी प्रक्रिया के बिना पुराना channel.db डेटाबेस चलाना खास तौर पर खतरनाक है: नोड अपनी ही रद्द स्थिति प्रकाशित कर सकता है। अपने वॉलेट और उसके खास संस्करण के दस्तावेज के अनुसार बैकअप तैयार करो। [7]
लेनदेन का आउटपुट राशि और उसे खर्च करने की शर्तें तय करता है। सुरक्षा इसलिए काम करती है क्योंकि अपनी चैनल स्थिति प्रकाशित करने वाला पक्ष अपने विलंबित आउटपुट को तुरंत खर्च नहीं कर सकता। BOLT 3 में इस आउटपुट का नाम to_local और प्रतीक्षा अवधि का नाम to_self_delay है। CSV वह नियम है जो आउटपुट की पुष्टि से यह देरी ब्लॉकों में गिनता है। सही revocation कुंजी, यानी रद्द स्थिति पर कार्रवाई की कुंजी, रखने वाला दूसरा पक्ष इस प्रतीक्षा के बिना दंड वाला रास्ता अपना सकता है। इससे Watchtower को पहले कार्रवाई करने का समय मिलता है। देरी पूरी होने पर दंड वाला रास्ता खत्म नहीं होता, लेकिन अब दूसरा पक्ष भी वही पैसा खर्च कर सकता है। नतीजा इस पर निर्भर करता है कि परस्पर विरोधी खर्चों में से किसकी वैध पुष्टि होती है। इसलिए सिर्फ धन-वापसी लेनदेन प्रसारित करना पर्याप्त नहीं, और ब्लॉकों की संख्या घंटों की निश्चित संख्या नहीं है। [1] [9]
सेवा चुनने से पहले देखो कि वह वास्तव में किसकी रक्षा करती है। HTLC सशर्त भुगतान हैं जो चैनल में अभी लंबित हो सकते हैं; बैलेंस की निगरानी से उनकी सुरक्षा साबित नहीं होती। यहाँ Dust उस आउटपुट को कहते हैं जो संबंधित लेनदेन में शामिल करने के लिए बहुत छोटा है। LND v0.21.3-beta का सत्यापित backupTask रद्द commitment के मौजूद, गैर-dust to_local और to_remote आउटपुट तैयार करता है। इसमें सभी HTLC आउटपुट की सामान्य सुरक्षा शामिल नहीं; संबंधित दस्तावेज इसे भविष्य का विस्तार बताते हैं। Bitcoin Script आउटपुट खर्च करने की शर्तें लिखने की भाषा है। दंड वाले रास्ते से आउटपुट खर्च किया जा सकना यह साबित नहीं करता कि किसी खास टावर को जरूरी डेटा मिल गया है या वह यह सुरक्षा लागू कर सकता है। [3] [5]
एन्क्रिप्टेड पैकेट के कारण टावर को आना के सभी बैलेंस लगातार पढ़ने की जरूरत नहीं होती। वह छोटे पहचान चिह्न से मिलान खोजता है और पहचाने गए लेनदेन की जानकारी से डेटा खोलता है। आगे किसी खास LND संस्करण का तकनीकी संदर्भ है; txid लेनदेन का पहचानकर्ता और blob डेटा का पैकेट है। LND v0.21.3-beta में BreachHint बाइनरी txid के SHA-256 के पहले 16 बाइट हैं। BreachKey उसी बाइनरी txid को स्वयं के साथ जोड़कर SHA-256 लगाने से बनता है। यह प्रदर्शित txid के पहले 16 अक्षर या उसका सीधे लिया गया पहला आधा हिस्सा नहीं है। क्लाइंट JusticeKit एन्क्रिप्ट करता है; संबंधित लेनदेन ज्ञात होने पर कुंजी निकाली और डेटा डिक्रिप्ट किया जा सकता है। [2] [3]
दूसरों के लिए टावर चलाना और अपने चैनलों की निगरानी करवाना अलग काम हैं। ये सेटिंग LND संचालकों के लिए हैं; RPC वह इंटरफेस है जिससे प्रोग्राम कमांड प्राप्त करता है। LND सर्वर के watchtower.active को क्लाइंट के wtclient.active से अलग रखता है। केवल सर्वर चालू करने से अपने चैनलों का दूसरे टावर पर बैकअप सेट नहीं होता। lncli tower info सर्वर के pubkey, listeners और uris दिखाता है; lncli wtclient add क्लाइंट के लिए टावर पंजीकृत करता है। टावर की सार्वजनिक कुंजी Lightning नोड की कुंजी से अलग है। नेटवर्क, पते तक पहुँच और प्रयुक्त बिल्ड में RPC समर्थन जाँचो। [5]
कार्रवाई को Bitcoin ब्लॉक में जगह की फीस देनी होती है। satoshi बिटकॉइन की सबसे छोटी इकाई है। वर्चुअल बाइट लेनदेन के अलग-अलग हिस्सों को दिए गए अलग भार को ध्यान में रखकर उसका आकार मापता है। दर लेनदेन के प्रति वर्चुअल बाइट satoshi में है, सुरक्षित पैसे के प्रतिशत में नहीं। LND v0.21.3-beta में policy और session का sweep_sat_per_vbyte फ़ील्ड sat/vB में दर बताता है। फीस लौटाई गई राशि घटाती है। backupTask बहुत कम मूल्य या अनुपयुक्त session मापदंड वाली स्थिति अस्वीकार कर सकता है; हर तैयार कार्य पात्र बैकअप नहीं है। बाद में सेटिंग बदलना पहले हस्ताक्षरित लेनदेन बदलने का प्रमाण नहीं, और अपर्याप्त दर प्रतिक्रिया को देर करा सकती है। [3] [6]
पहला टावर बंद हो तो दूसरा तभी मदद कर सकता है जब उसे खुद जरूरी डेटा मिला हो। स्वतंत्रता में अलग कनेक्शन और संचालक भी आते हैं, केवल सेवा का अलग नाम नहीं। कई स्वतंत्र टावर और स्वयं की निगरानी एक विफलता का असर घटा सकते हैं। पर जाँचो कि हर टावर को कौन से अपडेट सच में मिले हैं; कई पंजीकृत पते अपने आप सभी स्थितियों की प्रतिकृति का प्रमाण नहीं हैं। अलग मशीन, नेटवर्क और स्थान साझा विफलताएँ घटाते हैं। एन्क्रिप्टेड blob और प्रमाणित संपर्क शेष राशि की दृश्यता सीमित करते हैं, लेकिन मेटाडेटा, अपडेट की आवृत्ति का खुलासा या सहसंबंध का जोखिम खत्म नहीं करते। [5] [8]
जाँच में भेजे गए अपडेट और सचमुच प्राप्त अपडेट का अंतर देखो। आगे के कमांड और फ़ील्ड LND प्रशासकों के लिए विस्तृत संदर्भ हैं; टावर की बैकअप प्राप्ति-पावती, ब्लॉक में लेनदेन की पुष्टि नहीं है। lncli wtclient towers, lncli wtclient tower, lncli wtclient stats और lncli wtclient policy इस्तेमाल करो। LND v0.21.3-beta में num_backups और num_pending_backups अलग हैं; दूसरा फ़ील्ड टावर की प्राप्ति स्वीकृति की प्रतीक्षा वाले बैकअप गिनता है। stats उत्तर में num_failed_backups असफल बैकअप गिनता है जिनकी प्राप्ति की पुष्टि नहीं हुई। आँकड़े क्लाइंट चालू होने के बाद की अवधि के हैं। active_session_candidate भंडारण सत्र बनाने के लिए संभावित टावर को दर्शाता है, पूर्ण सुरक्षा का प्रमाण नहीं। [6]
सही सेटिंग शुरुआत है। परीक्षण में रद्द स्थिति की पहचान से लेकर सुरक्षित धन की वापसी तक पूरा क्रम जाँचना चाहिए; अपने असली पैसे से ऐसा प्रयोग मत करो। क्लाइंट और टावर के विशिष्ट रिलीज, समर्थित चैनल और session प्रकार, डेटा की नवीनता, फीस और श्रृंखला सिंक्रनाइज़ेशन जाँचो। प्रतिक्रिया का कार्यात्मक परीक्षण अलग परीक्षण वातावरण में करो; सामान्य एकतरफा बंद करना (force close) रद्द स्थिति पर कार्रवाई का प्रमाण नहीं है। रद्द स्थिति का प्रकाशन (breach), पुनर्निर्मित justice transaction और उसके पुष्ट आउटपुट परिणाम का प्रमाण हैं। सफल प्रदर्शन भविष्य की उपलब्धता की गारंटी नहीं देता और Lightning के सभी जोखिम नहीं मिटाता। [1] [3] [6]
पूरी तस्वीर के लिए इस प्रविष्टि के साथ यह भी पढ़ें Lightning Network, Payment Channel, स्व-अभिरक्षा. इस प्रविष्टि का उल्लेख यहाँ भी है Payment Channel.