BOLT 11

Bech32 का checksum नकल की गलतियाँ पकड़ता है; यह एन्क्रिप्शन नहीं है। secp256k1 पर ECDSA हस्ताक्षर सामग्री की रक्षा करके उसे प्राप्तकर्ता की कुंजी से जोड़ता है, सत्यापित व्यक्ति से नहीं। Bech32 पतों के विपरीत BOLT 11 में 90 वर्णों की सीमा नहीं है। QR में बड़े अक्षर चल सकते हैं; बड़े और छोटे अक्षरों का मिश्रण अमान्य है। [BOLT 11 — Invoice protocol]

lnbc mainnet, lntb testnet, lntbs signet और lnbcrt regtest को दर्शाते हैं। राशि BTC में होती है, जिसमें m, u, n या p गुणक लग सकता है। p के साथ अंतिम अंक 0 होना चाहिए ताकि पूरे msat बनें; 1000 msat एक satoshi है। राशि न होने पर भुगतानकर्ता उसे देता है; इसका अर्थ शून्य भुगतान नहीं। [BOLT 11 — Invoice protocol]

फ़ील्ड p में payment hash होता है: payment preimage का SHA256। फ़ील्ड s में payment_secret होता है, जिसे प्राप्तकर्ता मार्ग वाले भुगतान के अंतिम भाग में मांगता है। Secret न preimage है, न वॉलेट seed। मौजूदा BOLT 11 दोनों फ़ील्ड मांगता है; इनवॉइस से secret पढ़ लेना भुगतान सिद्ध नहीं करता। [BOLT 11 — Invoice protocol] [BOLT 4 — Onion routing]

इनवॉइस में ठीक एक विकल्प होता है: टेक्स्ट d या बाहरी विवरण का हैश h। h के लिए वॉलेट को दिए गए विवरण का SHA256 सत्यापित करना चाहिए; अकेला हैश खरीद नहीं समझाता। हस्ताक्षर सामग्री को कुंजी से जोड़ता है, व्यापारी के वादे की सच्चाई से नहीं। डिकोड किया टेक्स्ट सुरक्षित रूप से डेटा की तरह दिखाना चाहिए। [BOLT 11 — Invoice protocol]

Timestamp में x जोड़ने से समाप्ति तय होती है; x न हो तो सामान्य अवधि 3600 सेकंड है। फ़ील्ड c अंतिम HTLC का min_final_cltv_expiry_delta ब्लॉकों में है, सेकंड में दूसरी वैधता अवधि नहीं; न होने पर कम से कम 18 ब्लॉक लगते हैं। समाप्ति पहले से पूरा भुगतान वापस नहीं करती। [BOLT 11 — Invoice protocol]

फ़ील्ड 9 आवश्यक और वैकल्पिक सुविधाएँ बताता है। अज्ञात सम बिट पर अस्वीकार करना चाहिए, अज्ञात विषम बिट अनदेखा होता है; ज्ञात निर्भरताएँ पूरी होनी चाहिए। Basic MPP केवल basic_mpp उपलब्ध होने पर इस्तेमाल होता है। हिस्सों में बाँटने से कई स्वतंत्र इनवॉइस नहीं बनते। [BOLT 11 — Invoice protocol] [BOLT 9 — Assigned feature flags]

फ़ील्ड r प्राप्तकर्ता तक routing hints जोड़ता है; इससे नोड कुंजियाँ, चैनल पहचान और शुल्क के मान उजागर हो सकते हैं। यह वर्तमान तरलता का प्रमाण नहीं। वैकल्पिक f on-chain पता दे सकता है, जो अपने शुल्क और पुष्टियों वाला दूसरा भुगतान तरीका है। पूरा इनवॉइस निजी या हमेशा पुनः उपयोग होने वाला संपर्क नहीं है। [BOLT 11 — Invoice protocol] [BOLT 4 — Onion routing]

भेजने के बाद लंबित और पूर्ण में फर्क करें। केवल QR की तस्वीर नहीं, इनवॉइस और मेल खाता preimage निपटान के प्रमाण के रूप में रखें। उत्तर खोने पर पहले वॉलेट में स्थिति जाँचें। नया इनवॉइस या दूसरा तरीका अतिरिक्त भुगतान कर सकता है; प्रारूप अकेला दोहराव से सार्वभौमिक सुरक्षा नहीं देता। [BOLT 4 — Onion routing] [Core Lightning — Payment result]