BOLT 12

प्राप्तकर्ता offer प्रकाशित करता है; भुगतानकर्ता invoice_request भेजकर नया invoice पाता है। उसके बाद भुगतान हो सकता है। ऑफर कई लोगों या बार-बार भुगतान के लिए काम आता है। fetchinvoice से इनवॉइस लेना उसे चुकाना नहीं है; सार्वजनिक QR स्थायी कटौती की अनुमति नहीं देता। [BOLT 12 — Negotiation protocol] [Core Lightning — Fetching an invoice] [BOLT 12 — Project overview]

BOLT 12 फ़ील्ड TLV में रखता है। टेक्स्ट ऑफर का प्रिफिक्स lno और अनुरोध का lnr है; अक्षर-संग्रह Bech32 जैसा है, पर अंतिम checksum नहीं होता। Offer खुद हस्ताक्षरित नहीं होता। अनुरोध और इनवॉइस के BIP340 Schnorr हस्ताक्षर फ़ील्ड के Merkle root को सत्यापित करते हैं, व्यापारी की पहचान को नहीं। [BOLT 12 — Negotiation protocol]

वॉलेट invoice_request से invoice में कॉपी हुए फ़ील्ड, राशि, चेन और हस्ताक्षर की तुलना करता है। invoice_node_id को offer_issuer_id या उचित अंतिम blinded_node_id से मिलना चाहिए। असंबंधित वैध हस्ताक्षर काफी नहीं है। Merkle संरचना चुनिंदा फ़ील्ड के प्रमाण देती है, हस्ताक्षरित शर्तों में मनमाना बदलाव नहीं। [BOLT 12 — Negotiation protocol]

Bitcoin invoice_amount msat में है; 1000 msat एक satoshi है। offer_currency में ISO 4217 की दूसरी मुद्रा हो सकती है; जैसे USD में सेंट। वस्तुओं की संख्या और जारी करते समय विनिमय कीमत प्रभावित करते हैं। invreq_amount तय हो तो इनवॉइस मेल खाना चाहिए; नहीं तो अनुमत सीमा जाँची जाती है। [BOLT 12 — Negotiation protocol] [Core Lightning — Fetching an invoice]

offer_paths अनुरोध संदेश ले जाता है, invoice_paths भुगतान। मौजूदा invoice में blinded paths और उससे मेल खाता invoice_blindedpay होना चाहिए, सीधे प्राप्तकर्ता तक जाने पर भी। ब्लाइंडिंग नेटवर्क संरचना उजागर होना घटाती है, पर पूरी गुमनामी, उपलब्धता या तरलता नहीं देती। इनवॉइस माँगने के लिए सामान्य HTTPS भुगतान सर्वर आवश्यक नहीं। [BOLT 12 — Negotiation protocol] [BOLT 4 — Route blinding]

offer_absolute_expiry ऑफर के उपयोग को सीमित करता है। invoice_created_at और invoice_relative_expiry विशेष इनवॉइस को सीमित करते हैं; दूसरा फ़ील्ड न हो तो 7200 सेकंड लागू होते हैं। पुनः उपयोग वाला ऑफर इनवॉइस को हमेशा वैध नहीं बनाता। अज्ञात सम अनिवार्य बिट अस्वीकृत होते हैं; अज्ञात विषम बिट अनदेखे होते हैं। [BOLT 12 — Negotiation protocol]

रिफंड में पैसा भेजने वाला बिना offer का invoice_request प्रकाशित कर सकता है। पैसा पाने वाला अपना invoice लौटाता है; भुगतानकर्ता को इच्छित प्राप्तकर्ता सत्यापित करना चाहिए, जरूरत हो तो प्रोटोकॉल के बाहर। यह नया भुगतान है, पुराने का रद्द होना नहीं। अनुरोध स्कैन करना अधिकार या भुगतान स्वीकृति सिद्ध नहीं करता। [BOLT 12 — Negotiation protocol]

Invoice, भुगतान स्थिति और मेल खाता preimage रखें। Preimage इनवॉइस का निपटान सिद्ध करता है, अकेला यह नहीं बताता कि किस व्यक्ति ने भुगतान किया। उत्तर खोने पर दोबारा देने से पहले स्थिति जाँचें। ऑफर समर्थन हर विस्तार या स्वतः नियमित भुगतान का समर्थन नहीं है; प्राप्ति, भेजना और ऐप की अनुमति अलग-अलग जाँचें। [BOLT 12 — Negotiation protocol] [Core Lightning — Fetching an invoice]