BOLT 11

अन्ना एक ई-बुक खरीद रही है। दुकान बैंक खाते की जगह Lightning इनवॉइस दिखाती है, जिससे उसका वॉलेट भुगतान का विवरण पढ़ता है। अन्ना को लंबी स्ट्रिंग समझने की जरूरत नहीं; पुष्टि से पहले वह रकम, उद्देश्य और शुल्क जाँचती है। कुछ इनवॉइस में रकम तय नहीं होती, जैसे स्वैच्छिक योगदान में। तब भुगतान करने वाला रकम भरता है; रकम न होने का अर्थ शून्य भुगतान नहीं है। थोड़ा गहराई में जाएँ तो lnbc मुख्य नेटवर्क, lntb testnet, lntbs signet और lnbcrt regtest को दर्शाते हैं; बाद वाले परीक्षण परिवेश हैं। लिखी गई रकम BTC में होती है, जरूरत के अनुसार m, u, n या p गुणक के साथ, सीधे satoshi में नहीं। p होने पर संख्या का अंत 0 से होना चाहिए, ताकि वह पूर्ण millisatoshi हो: 1000 msat = 1 sat। [1]

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

अन्ना ऑर्डर खुला छोड़कर बाद में लौटती है। अगर वॉलेट बताता है कि इनवॉइस की समय-सीमा खत्म हो गई, तो उसे नया माँगना चाहिए। समाप्ति का समय निर्माण समय timestamp और अवधि x से निकलता है। x न हो तो सामान्य अवधि 3600 सेकंड, यानी एक घंटा है। समय-सीमा खत्म होने से पूरा हो चुका भुगतान वापस नहीं होता। c फ़ील्ड, जिसका तकनीकी नाम min_final_cltv_expiry_delta है, अलग बात तय करती है: रास्ते के अंतिम सशर्त भुगतान HTLC के लिए समय का अंतराल। HTLC में निपटारे के लिए सही गुप्त मान समय पर देना जरूरी है। यह अंतराल ब्लॉक में मापा जाता है, इनवॉइस की वैधता वाले सेकंड में नहीं; c न हो तो भुगतानकर्ता कम-से-कम 18 ब्लॉक रखता है। दोनों समय-सीमाओं को मिलाना नहीं चाहिए। [1]

Lightning भुगतान पेमेंट चैनलों से गुजरता है। चैनल के भीतर दो पक्ष धन का बँटवारा अपडेट करते हैं, बिना हर सामान्य भुगतान को Bitcoin की मुख्य ब्लॉकचेन पर दर्ज किए। सफलता के लिए उपलब्ध रास्ता और चैनलों के उचित पक्षों में पर्याप्त धन, यानी तरलता, चाहिए। r फ़ील्ड में routing hints हो सकते हैं: रास्ते के अंतिम हिस्से के संकेत। वे प्राप्तकर्ता तक पहुँचने में मदद करते हैं, लेकिन उपलब्ध क्षमता की लाइव जानकारी नहीं देते। वे नोड की सार्वजनिक कुंजियाँ, चैनल पहचान और शुल्क की शर्तें भी खोल सकते हैं, इसलिए पूरे इनवॉइस को निजी दस्तावेज न समझें। वैकल्पिक f फ़ील्ड सामान्य Bitcoin पता दे सकती है। उस पर भुगतान मुख्य चेन से होता है, जिसके अपने शुल्क और पुष्टियाँ हैं। यह उसी भेजने के तरीके का बस दूसरा बटन नहीं है। [1] [2] [5]

QR स्कैन करना या इनवॉइस मिलना रसीद नहीं है। भेजने के बाद वॉलेट में परिणाम देखें: लंबित और पूरा हो चुका अलग स्थितियाँ हैं। सफल निपटारे का प्रमाण सही preimage भी है, वह गुप्त मान जिसका हैश इनवॉइस के भुगतान हैश से मेल खाना चाहिए। इनवॉइस और उस मान को भुगतान के प्रमाण के रूप में रखा जा सकता है, लेकिन सामान मिलने की गारंटी के रूप में नहीं। ऐप का कनेक्शन टूटे या जवाब खो जाए, तो पहले मूल भुगतान की स्थिति जाँचें। तुरंत नया इनवॉइस माँगना या वैकल्पिक पते पर भेजना दोबारा भुगतान करा सकता है। कुछ वॉलेट दोहराई गई कोशिश पहचानते हैं, पर यह प्रारूप अपने आप अलग ऐप और भुगतान मार्गों में सार्वभौमिक सुरक्षा नहीं देता। [2] [4]

लंबी स्ट्रिंग Bech32 एन्कोडिंग में होती है। उसका चेकसम लिखने या कॉपी करने की गलती पकड़ने में मदद करता है; वह एन्क्रिप्शन नहीं है और सामग्री छिपाता नहीं। secp256k1 पर ECDSA डिजिटल हस्ताक्षर का काम अलग है: जाँचना कि भुगतान विवरण प्राप्तकर्ता की कुंजी से जुड़ा है और बाद में बदला नहीं गया। वह उस कुंजी के पीछे व्यक्ति की कानूनी पहचान या ईमानदारी प्रमाणित नहीं करता। Bitcoin के Bech32 पतों के उलट, BOLT 11 में 90 से अधिक अक्षर हो सकते हैं। QR के लिए बड़े अक्षर उपयोगी हैं, पर मान्य स्ट्रिंग में बड़े और छोटे अक्षर मिलाए नहीं जा सकते। व्यक्ति आम तौर पर स्कैन या कॉपी करता है, और ये जाँच वॉलेट करता है। [1]

Payment hash एक गुप्त payment preimage का डिजिटल फिंगरप्रिंट है, जो SHA256 से बनकर p फ़ील्ड में रखा जाता है। सफल निपटारे पर भुगतानकर्ता को preimage मिलता है और वह फिंगरप्रिंट मिला सकता है। दूसरी ओर s फ़ील्ड में payment_secret होता है। भुगतानकर्ता इसे इनवॉइस से पहले ही पढ़ लेता है और रास्ते के अंतिम हिस्से में प्राप्तकर्ता को देता है। यह बीच के नोड द्वारा टोह लेने से प्राप्तकर्ता की रक्षा में मदद करता है। Secret न preimage है, न वॉलेट का seed। QR से इसे पढ़ लेना न भुगतान का प्रमाण है, न वॉलेट बहाल करने का अधिकार। मौजूदा BOLT 11 में p और s दोनों चाहिए। मिलते-जुलते नामों के पीछे अलग काम हैं: भुगतान पहचानना, जरूरी मान देना और निपटारा साबित करना। [1] [2]

वॉलेट को यह भी समझना होता है कि वह माँगा गया भुगतान कर सकता है या नहीं। फ़ील्ड 9 में सुविधा-संकेत होते हैं। अज्ञात सम बिट अनिवार्य सुविधा बताता है, इसलिए भुगतान अस्वीकार करना होता है; अज्ञात विषम बिट वैकल्पिक है और छोड़ा जा सकता है। सुविधाओं की ज्ञात निर्भरताएँ भी पूरी होनी चाहिए। उदाहरण के लिए Basic MPP एक भुगतान को हिस्सों में बाँटता है, जो प्राप्तकर्ता के पास जुड़ते हैं। इसका उपयोग तभी हो सकता है जब इनवॉइस basic_mpp दे। हिस्से बनने से कई स्वतंत्र इनवॉइस नहीं बन जाते और हर हिस्सा फिर चुकाने की जरूरत नहीं होती। नए पाठक के लिए बात सीधी है: असमर्थित सुविधा का संदेश हटाने के लिए इनवॉइस हाथ से न बदलें; पहले वॉलेट की अनुकूलता का समाधान करें। [1] [3]