BOLT 11 adalah standar invoice Lightning bertanda tangan dengan pengodean Bech32. Isinya payment hash, informasi penerima dan syarat pembayaran; ini permintaan, bukan bukti pembayaran berhasil.
Bech32 memiliki checksum untuk kesalahan penyalinan; bukan enkripsi. Tanda tangan ECDSA pada secp256k1 melindungi isi dan mengikatnya ke kunci penerima, bukan orang terverifikasi. Berbeda dari alamat Bech32, BOLT 11 tidak dibatasi 90 karakter. QR boleh memakai huruf besar; campuran huruf besar dan kecil tidak valid. [BOLT 11 — Invoice protocol]
lnbc berarti mainnet, lntb testnet, lntbs signet dan lnbcrt regtest. Jumlah memakai BTC dengan pengali m, u, n atau p. Untuk p, digit terakhir harus 0 agar menjadi msat bulat; 1000 msat adalah satu satoshi. Jika jumlah tidak ada, pembayar mengisinya; bukan pembayaran nol. [BOLT 11 — Invoice protocol]
Kolom p memuat payment hash: SHA256 dari payment preimage. Kolom s memuat payment_secret yang diminta penerima pada bagian terakhir pembayaran terarah. Secret bukan preimage maupun seed dompet. BOLT 11 saat ini mewajibkan keduanya; membaca secret dari invoice tidak membuktikan pembayaran. [BOLT 11 — Invoice protocol] [BOLT 4 — Onion routing]
Invoice memuat tepat satu pilihan: teks d atau hash h dari deskripsi eksternal. Untuk h, dompet harus memeriksa SHA256 deskripsi yang diterima; hash saja tidak menjelaskan pembelian. Tanda tangan mengikat isi dengan kunci, bukan membuktikan janji pedagang. Teks hasil dekode harus ditampilkan secara aman sebagai data. [BOLT 11 — Invoice protocol]
Timestamp ditambah x menentukan kedaluwarsa; tanpa x durasi bawaan adalah 3600 detik. Kolom c ialah min_final_cltv_expiry_delta HTLC terakhir dalam blok, bukan masa berlaku lain dalam detik; jika tidak ada, berlaku setidaknya 18 blok. Kedaluwarsa tidak membatalkan pembayaran yang telah selesai. [BOLT 11 — Invoice protocol]
Kolom 9 menunjukkan fitur wajib dan opsional. Bit genap tak dikenal harus ditolak; bit ganjil tak dikenal diabaikan. Ketergantungan fitur yang dikenal harus dipenuhi. Basic MPP hanya boleh dipakai jika basic_mpp ditawarkan. Membagi pembayaran tidak menciptakan beberapa invoice independen. [BOLT 11 — Invoice protocol] [BOLT 9 — Assigned feature flags]
Kolom r menambah routing hints ke penerima dan dapat mengungkap kunci node, identitas kanal serta parameter biaya. Ini bukan bukti likuiditas terkini. Kolom opsional f dapat memberi alamat on-chain, metode berbeda dengan biaya dan konfirmasinya sendiri. Invoice bukan kontak privat atau kontak yang dapat digunakan ulang selamanya. [BOLT 11 — Invoice protocol] [BOLT 4 — Onion routing]
Setelah mengirim, bedakan tertunda dari selesai. Simpan invoice dan preimage yang cocok sebagai bukti penyelesaian, bukan hanya gambar QR. Jika jawaban hilang, periksa dahulu status dompet. Invoice baru atau metode lain dapat menimbulkan pembayaran tambahan; format sendiri tidak memberi perlindungan universal terhadap pengulangan. [BOLT 4 — Onion routing] [Core Lightning — Payment result]
Untuk gambaran yang lebih utuh, baca entri ini bersama Lightning Network, HTLC, BOLT 12, Nostr Wallet Connect, Satoshi. Entri ini juga dirujuk dari Nostr Wallet Connect, BOLT 12, LNURL, Lightning Address.