BOLT 12

कल्पना कीजिए कि कैफ़े स्वैच्छिक योगदान के लिए काउंटर पर एक ही कोड रखना चाहता है। उसी सामान्य BOLT 11 इनवॉइस को बार-बार चुकाने से समस्याएँ होंगी। BOLT 12 उसकी जगह offer प्रकाशित करता है। ग्राहक का वॉलेट उसके आधार पर invoice_request भेजकर अपना इनवॉइस माँगता है और प्राप्तकर्ता नए invoice से जवाब देता है। उसके बाद ही भुगतान हो सकता है। इस तरह एक छपा QR कई लोगों के काम आता है, बिना सबके एक ही इनवॉइस इस्तेमाल किए। fetchinvoice जैसी सुविधा से इनवॉइस लेना अभी पैसा भेजना नहीं है। ऑफ़र अपने आप कैफ़े को किसी और के वॉलेट से आगे की रकम काटने का अधिकार भी नहीं देता। [1] [3] [4]

ऑफ़र में कीमत बिटकॉइन या दूसरी मुद्रा में हो सकती है। offer_currency फ़ील्ड ISO 4217 कोड इस्तेमाल करती है; उदाहरण के लिए USD की रकम सेंट में होती है। इनवॉइस बनाते समय वस्तुओं की संख्या और मुद्रा विनिमय का असर पड़ सकता है। लेकिन अंतिम बिटकॉइन invoice_amount, millisatoshi, यानी satoshi के हज़ारवें हिस्से में होता है: 1000 msat = 1 sat। भुगतान से पहले व्यक्ति को यह रकम और शुल्क जानना चाहिए, सिर्फ पुराना मूल्य-पट्ट नहीं। अनुरोध में सटीक invreq_amount तय हो तो इनवॉइस उससे मेल खाना चाहिए। अन्यथा वॉलेट को अधिकृत सीमा जाँचनी चाहिए और रकम उससे बाहर हो तो नई मंजूरी लेनी चाहिए। मुद्रा बदलना किसी भी कीमत की अनकही स्वीकृति नहीं बनना चाहिए। [1] [3]

छपा कोड काउंटर पर रह सकता है, लेकिन ऑफ़र खुद offer_absolute_expiry पर समाप्त हो सकता है। हर इनवॉइस का अलग निर्माण समय invoice_created_at और अवधि invoice_relative_expiry भी है। अवधि न हो तो सामान्य मान 7200 सेकंड, यानी दो घंटे है। पुराना इनवॉइस हमेशा वैध रहने वाला संपर्क नहीं है। वॉलेट को संदेशों में बताई अनिवार्य सुविधाएँ भी समझनी होंगी। अज्ञात सम बिट जरूरी सुविधा बताता है और अस्वीकृति का कारण बनता है; अज्ञात विषम बिट वैकल्पिक है और छोड़ा जा सकता है। यह सुरक्षित अनुकूलता है, ऐसी बाधा नहीं जिसे उपयोगकर्ता को कोड हाथ से बदलकर पार करना चाहिए। [1]

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

इनवॉइस माँगना और धन भेजना नेटवर्क का अलग उद्देश्य से उपयोग करते हैं। offer_paths अनुरोध संदेश का रास्ता है, जबकि invoice_paths भुगतान के रास्ते देता है। BOLT 12 में blinded paths हैं, जो प्राप्तकर्ता तक पहुँच के कुछ विवरण छिपाते हैं। नेटवर्क की कम जानकारी खुलने से निजता में मदद मिलती है, लेकिन पूरी गुमनामी की गारंटी नहीं। छिपा रास्ता प्राप्तकर्ता की उपलब्धता या तरलता, यानी चैनलों के जरूरी पक्षों में पर्याप्त धन, भी सुनिश्चित नहीं करता। तकनीकी रूप से मौजूदा invoice में ये रास्ते और उनसे जुड़े invoice_blindedpay भुगतान पैरामीटर होने चाहिए, भले रास्ता सीधे प्राप्तकर्ता तक जाता हो। इनवॉइस माँगने के लिए सामान्य HTTPS भुगतान सर्वर जरूरी नहीं है। [1] [2]

दुकानदार ग्राहक को पैसा लौटाना चाहे तो बातचीत की दिशा उलट जाती है। जो भुगतान करेगा वह पिछली offer के बिना invoice_request प्रकाशित कर सकता है। ग्राहक, अब प्राप्तकर्ता के रूप में, अपना invoice भेजता है, जिसे दुकानदार चुकाता है। इससे मूल भुगतान मिटता या रद्द नहीं होता; विपरीत दिशा में नया भुगतान होता है। दुकानदार को सुनिश्चित करना होगा कि इनवॉइस इच्छित प्राप्तकर्ता का है, कभी-कभी प्रोटोकॉल के बाहर बात करके। अनुरोध स्कैन करना न वापसी का अधिकार साबित करता है, न हस्तांतरण की मंजूरी। तकनीकी प्रक्रिया संवाद आसान करती है, पर यह नहीं तय करती कि पैसा किसे लौटना चाहिए। [1]

BOLT 12 डेटा को TLV में रखता है: हर फ़ील्ड अपना प्रकार, लंबाई और मान बताती है। टेक्स्ट ऑफ़र lno से, अनुरोध lnr से शुरू होता है। अक्षरों का समूह Bech32 जैसा है, लेकिन उसका अंतिम चेकसम नहीं है। इससे अकेले तय नहीं होता कि किसे भुगतान मिलना चाहिए। Offer खुद हस्ताक्षरित नहीं है। BIP340 Schnorr डिजिटल हस्ताक्षर इनवॉइस और किसी ऑफ़र के जवाब में भेजे गए सामान्य अनुरोध की पुष्टि करते हैं। पहले से कोई ऑफ़र न होने पर अलग से प्रकाशित अनुरोध, जैसे पैसा लौटाने के लिए दिया गया अनुरोध, हस्ताक्षरित नहीं होता। हस्ताक्षर Merkle संरचना के रूट से जुड़ा होता है, यानी संबंधित फ़ील्डों से मिलाकर निकाला गया एक जाँच-मान। इससे हर बार पूरी जानकारी खोले बिना चुनी हुई फ़ील्ड साबित की जा सकती हैं। इसका अर्थ हस्ताक्षरित शर्तें बदलने की छूट या दुकानदार की कानूनी पहचान का प्रमाण नहीं है। [1]

वॉलेट को सुनिश्चित करना होता है कि उसे अपने अनुरोध का जवाब मिला है, सिर्फ कोई सही हस्ताक्षर वाला इनवॉइस नहीं। वह invoice_request से invoice में आई फ़ील्डों के साथ नेटवर्क, रकम और हस्ताक्षर की तुलना करता है। invoice_node_id सार्वजनिक कुंजी को offer_issuer_id से मेल खाना चाहिए; अगर ऑफ़र इस पहचान के बिना संबंधित छिपा रास्ता इस्तेमाल करता है तो उसके अंतिम blinded_node_id की जाँच होती है। यह देखने जैसा है कि बिल आपकी मेज का है, न कि सिर्फ उसकी मुहर असली है। Merkle संरचना चुनिंदा जानकारी का प्रमाण देती है, पर वॉलेट को भुगतान की जरूरी शर्तें पूरी जाँचने से मुक्त नहीं करती। किसी और का वैध इनवॉइस सिर्फ हस्ताक्षर जाँच पास करके सही नहीं बन जाता। [1]