BOLT 11

Anna membeli buku elektronik. Alih-alih nomor rekening, toko menampilkan invoice Lightning yang dibaca oleh dompetnya. Anna tidak perlu memahami deretan karakter itu: sebelum menyetujui, ia memeriksa jumlah, tujuan dan biaya. Beberapa invoice membiarkan jumlahnya terbuka, misalnya untuk sumbangan sukarela. Pembayarlah yang mengisinya; jumlah yang tidak dicantumkan bukan berarti pembayaran nol. Untuk yang ingin tahu lebih jauh, lnbc menandai jaringan utama; lntb adalah testnet, lntbs signet dan lnbcrt regtest, yaitu lingkungan pengujian. Jumlah yang dikodekan memakai BTC dengan kemungkinan pengali m, u, n atau p, bukan langsung satoshi. Jika memakai p, angkanya harus berakhir dengan 0 agar menyatakan millisatoshi bulat: 1000 msat = 1 sat. [1]

Deskripsi menghubungkan permintaan teknis dengan tujuan yang bisa dipahami, seperti buku Anna. Invoice memuat teks di kolom d atau sidik jari digitalnya di h. Sidik jari ini dihitung dengan SHA256; dompet harus memeriksa apakah deskripsi yang diberikan terpisah menghasilkan nilai yang sama. Nilai pemeriksaan singkat yang dihitung dari teks ini disebut hash. Sidik jari saja tidak mengungkap isi pesanan. Tanda tangan yang sah mengikat deskripsi pada kunci penerima, tetapi tidak menjanjikan bahwa penjual akan mengirim bukunya. Pengembang aplikasi juga punya tanggung jawab: deskripsi adalah teks dari luar yang harus ditampilkan dengan aman sebagai data, tidak pernah dijalankan sebagai kode. [1]

Anna membiarkan pesanan terbuka dan kembali kemudian. Jika dompet menyatakan invoice sudah kedaluwarsa, ia perlu meminta yang baru. Batas waktunya dihitung dari waktu pembuatan timestamp dan durasi x. Tanpa x, durasi bawaan adalah 3600 detik, atau satu jam. Kedaluwarsa tidak membatalkan pembayaran yang sudah selesai. Kolom c, secara teknis min_final_cltv_expiry_delta, mengatur hal lain: cadangan waktu untuk pembayaran bersyarat HTLC terakhir di rute. HTLC mensyaratkan pemberian rahasia yang benar tepat waktu untuk menyelesaikan pembayaran. Cadangan ini diukur dalam blok, bukan detik masa berlaku invoice; tanpa c, pembayar memakai setidaknya 18 blok. Kedua ketentuan waktu ini tidak boleh tertukar. [1]

Pembayaran Lightning melewati kanal pembayaran. Di dalam kanal, dua pihak terus memperbarui pembagian dana tanpa mencatat setiap pembayaran biasa di blockchain utama Bitcoin. Agar berhasil, diperlukan rute yang dapat digunakan dan dana yang cukup di sisi kanal yang tepat, yaitu likuiditas. Kolom r dapat menyediakan routing hints, petunjuk untuk bagian akhir perjalanan. Petunjuk ini membantu menemukan penerima, tetapi bukan laporan langsung tentang kapasitas yang tersedia. Ia juga dapat mengungkap kunci publik node, pengenal kanal dan parameter biaya; jadi jangan menganggap seluruh invoice sebagai dokumen privat. Kolom opsional f dapat menawarkan alamat Bitcoin biasa sebagai alternatif. Pembayaran ke sana menggunakan rantai utama, dengan biaya dan konfirmasinya sendiri. Ini bukan sekadar tombol berbeda untuk cara pengiriman yang sama. [1] [2] [5]

Memindai QR atau menerima invoice bukan berarti memperoleh tanda terima. Setelah mengirim, periksa hasil di dompet: tertunda berbeda dengan selesai. Penyelesaian juga dibuktikan oleh preimage yang benar, nilai rahasia yang hash-nya harus cocok dengan hash pembayaran pada invoice. Keduanya dapat disimpan sebagai bukti pembayaran, bukan jaminan pengiriman barang. Jika aplikasi terputus atau kehilangan jawaban, periksa dahulu status pembayaran awal. Langsung meminta invoice baru atau memakai alamat alternatif dapat menyebabkan pembayaran kedua. Beberapa dompet mengenali percobaan ulang, tetapi format ini sendiri tidak menyediakan perlindungan universal lintas aplikasi dan cara pembayaran. [2] [4]

Deretan karakter panjang menggunakan pengodean Bech32. Checksum membantu mendeteksi kesalahan penyalinan; ini bukan enkripsi dan tidak menyembunyikan isi. Tanda tangan digital ECDSA pada secp256k1 punya tugas berbeda: memastikan data pembayaran terkait dengan kunci penerima dan tidak diubah sesudahnya. Ia tidak membuktikan identitas resmi atau kejujuran pemilik kunci. Berbeda dari alamat Bitcoin Bech32, BOLT 11 boleh melebihi 90 karakter. Huruf besar cocok untuk QR, tetapi deretan yang sah tidak boleh mencampur huruf besar dan kecil. Orang biasanya memindai atau menyalin, sementara dompet melakukan pemeriksaan tersebut. [1]

Payment hash adalah sidik jari digital dari nilai rahasia payment preimage, dihitung dengan SHA256 dan disimpan di p. Setelah penyelesaian berhasil, pembayar mengetahui preimage dan dapat mencocokkan sidik jarinya. Sebaliknya, kolom s berisi payment_secret. Pembayar sudah membacanya dari invoice dan menyerahkannya kepada penerima di bagian akhir rute pembayaran; ini membantu melindungi penerima dari upaya penjajakan node perantara. Secret bukan preimage ataupun seed dompet. Membacanya dari QR tidak membuktikan pembayaran dan tidak memberi kemampuan memulihkan dompet. BOLT 11 saat ini mewajibkan p dan s. Nama yang mirip menyimpan tugas berbeda: mengenali pembayaran, memberikan nilai yang diperlukan dan membuktikan penyelesaian. [1] [2]

Dompet juga harus mengetahui apakah ia mendukung pembayaran yang diminta. Kolom 9 memuat penanda fitur. Bit genap yang tidak dikenal berarti fitur wajib sehingga pembayaran harus ditolak; bit ganjil yang tidak dikenal bersifat opsional dan dapat diabaikan. Ketergantungan yang dikenal antarfitur juga harus dipenuhi. Contohnya, Basic MPP membagi satu pembayaran menjadi beberapa bagian yang digabungkan di penerima. Ini hanya boleh digunakan jika invoice menawarkan basic_mpp. Pembagian tidak menciptakan beberapa invoice terpisah atau alasan untuk membayar setiap bagian lagi. Bagi pemula, intinya sederhana: jangan mengakali pesan fitur tidak didukung dengan mengubah invoice secara manual; selesaikan kompatibilitas dompet terlebih dahulu. [1] [3]