BOLT 12

Bayangkan kafe yang ingin menaruh satu kode di meja untuk sumbangan sukarela. Membayar invoice BOLT 11 biasa yang sama berulang kali akan menimbulkan masalah. BOLT 12 menerbitkan offer sebagai gantinya. Dompet pelanggan mengirim invoice_request untuk meminta invoice sendiri, lalu penerima membalas dengan invoice baru. Barulah pembayaran dilakukan. Satu QR tercetak dapat melayani banyak orang tanpa semuanya memakai invoice yang sama. Mengambil invoice, misalnya melalui fetchinvoice, belum mengirim uang. Penawaran itu sendiri juga tidak memberi kafe izin mendebit pembayaran berikutnya dari dompet orang lain. [1] [3] [4]

Penawaran dapat menyebut harga dalam bitcoin atau mata uang lain. Kolom offer_currency memakai kode ISO 4217; jumlah USD, misalnya, dinyatakan dalam sen. Kuantitas dan konversi mata uang dapat diperhitungkan saat invoice diterbitkan. Namun, invoice_amount bitcoin akhirnya dinyatakan dalam millisatoshi, seperseribu satoshi: 1000 msat = 1 sat. Pembayar perlu mengetahui jumlah itu dan biayanya sebelum membayar, bukan hanya harga awal di papan. Jika permintaan menentukan invreq_amount yang tepat, invoice harus cocok. Jika tidak, dompet memeriksa rentang yang diizinkan dan seharusnya meminta persetujuan lagi bila jumlahnya di luar rentang. Konversi tidak boleh menjadi persetujuan tersembunyi atas sembarang harga. [1] [3]

Kode tercetak bisa tetap di meja, tetapi penawarannya sendiri dapat berakhir pada offer_absolute_expiry. Setiap invoice juga punya waktu pembuatan invoice_created_at dan masa berlaku invoice_relative_expiry. Jika durasi itu tidak ada, nilai bawaannya 7200 detik, atau dua jam. Invoice lama bukan kontak yang berlaku tanpa batas. Dompet juga harus memahami fitur wajib dalam pesan. Bit genap yang tidak dikenal berarti fitur yang diperlukan dan mengharuskan penolakan; bit ganjil yang tidak dikenal bersifat opsional dan dapat diabaikan. Ini untuk kompatibilitas yang aman, bukan hambatan yang harus dilewati pengguna dengan mengubah kode secara manual. [1]

Setelah membayar, simpan invoice dan hasil dari dompet. Bukti penyelesaian juga mencakup preimage, nilai rahasia yang diterima saat pembayaran selesai. Dompet menghitung hash, yaitu nilai untuk pemeriksaan, dari nilai rahasia itu lalu membandingkannya dengan hash pembayaran pada invoice. Bersama invoice, ini dapat menunjukkan bahwa pembayaran telah selesai, tetapi tidak dengan sendirinya mengidentifikasi orang yang membayar. Jika aplikasi terputus atau kehilangan jawaban, periksa status pembayaran sebelumnya sebelum mencoba lagi; invoice baru dapat memicu pembayaran lain. Periksa janji pembayaran berulang dengan kehati-hatian yang sama. Mendukung BOLT 12 tidak otomatis berarti mendukung semua ekstensi atau mengizinkan debit otomatis. Periksa terpisah apakah dompet menerima pembayaran melalui penawaran, membayar penawaran orang lain, dan izin apa yang diberikan kepada aplikasi terhubung. [1] [3]

Meminta invoice dan mentransfer dana memakai jaringan untuk tujuan berbeda. offer_paths mengarahkan pesan permintaan, sedangkan invoice_paths menyediakan rute pembayaran. BOLT 12 memakai blinded paths, rute yang menyembunyikan sebagian detail koneksi menuju penerima. Mengungkap lebih sedikit struktur jaringan membantu privasi, tetapi tidak menjanjikan anonimitas penuh. Rute tersembunyi juga tidak menjamin penerima tersedia atau likuiditas, yaitu cukup uang di sisi kanal yang diperlukan. Secara teknis, invoice saat ini harus memuat rute tersebut dan parameter invoice_blindedpay yang sesuai, bahkan untuk rute langsung ke penerima. Meminta invoice tidak membutuhkan server pembayaran HTTPS konvensional. [1] [2]

Saat pedagang ingin mengembalikan uang, arah negosiasi berbalik. Calon pembayar dapat menerbitkan invoice_request tanpa offer sebelumnya. Pelanggan yang kini menjadi penerima membalas dengan invoice miliknya untuk dibayar pedagang. Ini tidak menghapus atau membatalkan pembayaran awal; ini pembayaran baru ke arah sebaliknya. Pedagang harus memastikan invoice berasal dari penerima yang dimaksud, terkadang melalui komunikasi di luar protokol. Memindai permintaan saja tidak membuktikan hak pengembalian dana atau menyetujui transfer. Proses teknis memudahkan komunikasi, tetapi tidak menentukan kepada siapa uang harus dikembalikan. [1]

BOLT 12 menyimpan data sebagai TLV: setiap kolom menyebut tipe, panjang dan nilainya. Penawaran teks dimulai dengan lno, permintaan dengan lnr. Karakternya menyerupai Bech32, tetapi tanpa checksum di bagian akhir. Ini sendiri tidak menentukan siapa yang harus dibayar. Offer tidak ditandatangani. Tanda tangan digital BIP340 Schnorr mengautentikasi invoice dan permintaan biasa yang menanggapi penawaran. Permintaan mandiri yang dipublikasikan tanpa penawaran sebelumnya, misalnya untuk pengembalian dana, tidak memiliki tanda tangan. Tanda tangan terikat pada akar struktur Merkle, yaitu nilai pemeriksaan gabungan yang dihitung dari kolom terkait. Dengan begitu, kolom tertentu dapat dibuktikan tanpa selalu membuka semua detail. Ini tidak mengizinkan perubahan syarat bertanda tangan ataupun membuktikan identitas resmi pedagang. [1]

Dompet harus memastikan bahwa yang diterima adalah jawaban atas permintaannya, bukan sembarang invoice dengan tanda tangan sah. Ia membandingkan kolom invoice_request yang disalin ke invoice, serta jaringan, jumlah dan tanda tangan. Kunci publik invoice_node_id harus cocok dengan offer_issuer_id; jika penawaran memakai rute tersembunyi terkait tanpa pengenal itu, dompet memeriksa blinded_node_id terakhirnya. Ibarat memeriksa apakah tagihan milik meja Anda, bukan sekadar apakah capnya asli. Struktur Merkle mendukung bukti informasi terpilih, tetapi tidak membebaskan dompet dari memeriksa seluruh syarat yang diperlukan. Invoice sah milik orang lain tidak menjadi benar hanya karena tanda tangannya lolos pemeriksaan. [1]