Lightning Routing

आना कॉफ़ी का भुगतान करना चाहती है, लेकिन कैफ़े के साथ उसका चैनल नहीं है। उसका पावेल के साथ चैनल है और पावेल का कैफ़े के साथ दूसरा चैनल है। इसलिए भुगतान पावेल से होकर जा सकता है: पहले चैनल में बैलेंस का कुछ हिस्सा आना से पावेल के हिस्से में आता है, और दूसरे में पावेल से कैफ़े के हिस्से में जाता है। एक ही सिक्का चैनलों के बीच नहीं घूमता; उनके बैलेंस जुड़े हुए चरणों में बदलते हैं। इसलिए पावेल के पास उस तरफ़ अपना इस्तेमाल करने योग्य धन होना चाहिए, जहाँ से वह कैफ़े को भुगतान करता है। भेजने वाले का वॉलेट या नोड प्राप्तकर्ता तक का रास्ता चुनता है और हर चरण के लिए निर्देश तैयार करता है। प्राप्तकर्ता ज़रूरी डेटा और समर्थित सुविधाएँ बताता है; वह अंतिम गैर-सार्वजनिक हिस्से की जानकारी भी दे सकता है। बीच के नोड निर्देशों के अनुसार भुगतान आगे भेजते हैं। वे हर बार अपने स्तर पर मंज़िल तक का पूरा रास्ता नहीं खोजते। [1] [4]

Gossip नोड के बीच जानकारी फैलाने का तरीका है। BOLT #7 चैनलों की घोषणाएँ और हर दिशा के अपडेट बताता है: आधार शुल्क, राशि के अनुपात में शुल्क, CLTV समाप्ति-समय का अंतर, न्यूनतम और अधिकतम राशि तथा उपलब्धता का संकेत। घोषित शर्तों से यह साबित नहीं होता कि दूसरा नोड अभी ऑनलाइन है या उसके पास पर्याप्त धन है। यहाँ CLTV का मतलब Bitcoin की चेन में ब्लॉक के क्रमांक, यानी ब्लॉक ऊँचाई, से तय समय-सीमा है, घड़ी का कोई सटीक समय नहीं। समय-सीमाओं के बीच का अंतर मध्यस्थ को कार्रवाई का समय देता है, यदि भुगतान आगे बढ़ना रुक जाए। [2]

चैनल की कुल क्षमता यह नहीं बताती कि उसके दोनों पक्ष अभी कितना भेज सकते हैं। भेजने वाला अपने चैनलों को जानता है, लेकिन दूसरे चैनलों के लिए अनुमान और सफल-असफल कोशिशों का इतिहास इस्तेमाल करता है। इसलिए सॉफ़्टवेयर शुल्क के साथ भुगतान गुज़रने की संभावना भी देखता है। इस बीच कोई दूसरा भुगतान तरलता बदल सकता है, यानी वह धन जिसे ज़रूरी दिशा में भेजा जा सकता है। [4] [5]

इन चरणों को HTLC जोड़ते हैं। ये शर्तों वाले भुगतान हैं, जिन्हें पूरा करने के लिए संबंधित गुप्त मान प्रकट करना होता है। भुगतान पूरा न हो तो समय-सीमा बीतने के बाद धन वापस लिया जा सकता है। गणना प्राप्तकर्ता को मिलने वाली राशि से शुरू होकर पीछे की ओर बढ़ती है। हर मध्यस्थ को अगले नोड के लिए राशि और अपना शुल्क मिलना चाहिए। आने वाले HTLC की समाप्ति, जाने वाले HTLC से आवश्यक CLTV अंतर के अनुसार पर्याप्त देर बाद होनी चाहिए। लंबा रास्ता लागत और समस्या होने पर धन फँसा रहने की अवधि बढ़ा सकता है। [1] [2]

BOLT #4 का onion routing, Sphinx संरचना इस्तेमाल करता है: हर चरण के निर्देश अलग से एन्क्रिप्ट होते हैं। मध्यस्थ को अपने पिछले और अगले साथी तथा अपने निर्देश पता होते हैं। केवल पैकेट से पूरा रास्ता, उसकी लंबाई या उसमें नोड की सटीक स्थिति नहीं खुलती। फिर भी संचार के विश्लेषण या कई नोड के सहयोग से गोपनीयता कम हो सकती है। [1]

चैनल अस्थायी रूप से विफल हो सकता है, शुल्क कम हो सकता है, CLTV गलत हो सकता है या अगला साथी उपलब्ध अथवा ज्ञात नहीं हो सकता। भेजने वाले को त्रुटि की सीमित जानकारी ही मिलती है। उसका सॉफ़्टवेयर रास्ते की रेटिंग घटा सकता है, नया हिसाब लगाकर फिर कोशिश कर सकता है। यह नोड को दिया जाने वाला जुर्माना नहीं है, और एक नतीजा भरोसेमंदी का स्थायी आकलन नहीं होता। [1] [4]

केवल कनेक्शन मिलना काफ़ी नहीं है: हर चरण को HTLC स्वीकार करना होता है और ज़रूरी दिशा में पर्याप्त इस्तेमाल करने योग्य धन चाहिए। बैलेंस का कुछ हिस्सा आरक्षित हो सकता है या अधूरे भुगतानों में बँधा हो सकता है। तकनीकी फ़ील्ड htlc_minimum_msat और htlc_maximum_msat उस दिशा में एक HTLC की राशि की न्यूनतम और अधिकतम सीमा भी तय करते हैं। msat एक सातोशी का हज़ारवाँ हिस्सा है; सातोशी Bitcoin की चेन पर राशि की सबसे छोटी इकाई है। घोषित सीमा ऊँची होने से भी यह साबित नहीं होता कि ज़रूरी तरलता अभी उपलब्ध है। इसलिए एक अनुपयुक्त चैनल पूरे रास्ते को रोक सकता है। [2]

यदि प्राप्तकर्ता basic MPP, यानी एक भुगतान को कई हिस्सों में बाँटने की सुविधा का समर्थन करता है, तो भेजने वाला प्रोटोकॉल में total_msat के नाम से दी गई कुल राशि को कई रास्तों में बाँट सकता है। प्राप्तकर्ता आवश्यक हिस्सों का इंतज़ार करता है और उनका निपटान एक साथ करता है। इससे अलग-अलग चैनलों में मौजूद तरलता इस्तेमाल हो सकती है, लेकिन MPP नई तरलता नहीं बनाता। HTLC और कोशिशों की संख्या बढ़ती है; शुल्क भी बढ़ सकता है। [1]

BOLT #11 के route hints, अंतिम अघोषित चरणों की जानकारी भेजने वाले को दे सकते हैं। इसके बजाय BOLT #12 में प्रयुक्त route blinding, प्रवेश नोड यानी introduction point के ज़रिए रास्ते का एन्क्रिप्ट किया हुआ अंतिम हिस्सा देता है। भेजने वाले को फिर भी उस बिंदु तक उपयोग योग्य रास्ता खोजना और कुल शुल्क तथा CLTV की शर्तें पूरी करनी होती हैं। बेहतर गोपनीयता भुगतान पहुँचने की गारंटी नहीं है। [3] [6] [1]

रोज़मर्रा के भुगतान में रास्ता वॉलेट ढूँढ़ता है। आगे के विवरण मुख्यतः नोड चलाने वालों और बार-बार आने वाली समस्याओं का कारण जाँचने में काम आते हैं। सॉफ़्टवेयर और उसका संस्करण, राशि, शुल्क और CLTV की अधिकतम सीमा, कोशिशों की संख्या, इस्तेमाल किए रास्ते, पूरा होने का समय और विफलता का सटीक कारण दर्ज करें। उसी नोड-जोड़ी की तुलना आस-पास के समय में करें। सफलता किसी विशेष नेटवर्क स्थिति में एक विशेष भुगतान का वर्णन करती है, हमेशा लागू रहने वाला वैश्विक स्कोर नहीं। [4] [5]