LNURL

Bayangkan Anna memindai kode untuk mendukung penulis, lalu kode untuk mencairkan voucher, dan akhirnya kode untuk masuk ke situs. Cara memakai ponselnya sama, tetapi tindakan yang disetujuinya berbeda. LNURL membedakannya: payRequest untuk membayar, withdrawRequest untuk menarik dana, dan login untuk masuk. Dokumen LUD menjelaskan tiap prosedur. Ini merupakan kesepakatan opsional antaraplikasi, bukan perubahan aturan Bitcoin. Dukungan dompet untuk satu prosedur tidak otomatis mencakup semua prosedur lainnya. [1] [7]

Dalam payRequest, layanan memberikan deskripsi dan rentang jumlah yang diizinkan. Anna memeriksa domain—alamat web layanan—membaca deskripsi, lalu memilih jumlah dukungan. Setelah menyetujui ketentuannya, dompet meminta faktur Lightning BOLT 11 khusus dan mencocokkan jumlahnya dengan pilihan Anna sebelum membayar. Proses ini memakai alamat callback, batas minSendable dan maxSendable, serta deskripsi metadata; jumlah dikirim dalam amount dan faktur diterima dalam pr. Jumlah menggunakan msat, seperseribu satoshi: 1000 msat = 1 sat. Orang lain dapat memakai QR publik yang sama, tetapi memindainya bukan konfirmasi pembayaran. [3]

Pada withdrawRequest, arahnya terbalik. Anna ingin menarik saldo dari layanan, bukan membayarnya. Karena itu, dompet Anna membuat faktur penerimaan untuk dibayar oleh layanan. Layanan memberikan pengenal k1, alamat callback, serta batas minWithdrawable dan maxWithdrawable dalam msat; setelah disetujui, dompet mengirim faktur melalui pr. Jawaban OK berarti layanan menerima permintaan, bukan bahwa uang sudah diterima Anna. Dompet masih menunggu pembayaran masuk. Kode penarikan dapat berlaku seperti voucher yang bisa digunakan siapa pun yang memegangnya, jadi jangan memublikasikannya seperti kontak penerimaan pembayaran biasa. [4]

Di situs lain, Anna memilih LNURL-auth. Dompet menampilkan domain dan tujuan permintaan dengan tag login. Dengan persetujuannya, dompet menandatangani tantangan sekali pakai k1 menggunakan kunci privat khusus domain, linkingPrivKey. Dompet mengirim tanda tangan dan kunci publik pasangannya, linkingKey, agar layanan dapat memverifikasi tanda tangan. Kunci privat tidak dikirim. Layanan dapat mengenali pemilik kunci yang kembali, tetapi pemeriksaan itu saja tidak mengungkap identitas orang tersebut di dunia nyata. Dompet tidak mengirim seed, yaitu nilai rahasia awal untuk menurunkan kunci, ataupun Seed Phrase, yaitu kata-kata pemulihan, kepada layanan. Secara teknis, prosedur ini memakai tanda tangan ECDSA pada kurva secp256k1. Kolom action dapat meminta pendaftaran, login, pengaitan akun, atau otorisasi lain, sehingga seluruh konfirmasi perlu dibaca. Menandatangani tantangan ini sendiri bukan pembayaran Bitcoin. [5]

Permintaan, jawaban layanan, dan perpindahan uang yang nyata merupakan tahap berbeda. Jika koneksi terputus, Anna terlebih dahulu memeriksa pembayaran awal di dompetnya. Percobaan baru dengan faktur baru dapat menghasilkan pembayaran tambahan. Prosedur opsional LUD-21 menyediakan alamat verify untuk memeriksa faktur tertentu: settled true melaporkan penyelesaian, sedangkan settled false melaporkan bahwa faktur belum diselesaikan. OK saja tidak cukup. Jawaban dapat memuat preimage, nilai rahasia awal yang terkait dengan pembayaran. Dompet menghitung hash, yaitu nilai untuk pemeriksaan, dari rahasia tersebut, lalu membandingkannya dengan hash pembayaran pada faktur yang benar. Menerima sembarang nilai rahasia tidak cukup: nilainya harus cocok dengan pembayaran itu. Pemeriksaan hasil tidak menjamin ketersediaan layanan ataupun likuiditas masuk, yakni kapasitas untuk merutekan uang ke dompet penerima. [6] [3] [4]

HTTPS melindungi pengiriman data antara dompet dan layanan, bukan dari layanan itu sendiri. Layanan dapat mengamati permintaan, waktunya, dan penggunaan berulang. Untuk login, nama domain lengkap juga berpengaruh: perubahan subdomain dapat menghasilkan linkingKey berbeda sehingga situs melihat pengguna lain. Beralih ke dompet lain juga belum tentu memulihkan login yang sama, sebab aplikasi menurunkan kunci dengan cara berbeda. Sebelum perubahan penting, periksa cara memulihkan akses ke akun tersebut. LNURL sendiri tidak menentukan siapa yang memegang kunci bitcoin; itu bergantung pada dompet dan layanan. [2] [5]

LUD-01 dasar menyatakan URL HTTPS atau onion dalam Bech32. Ini adalah pengodean, bukan enkripsi alamat dan bukan faktur BOLT 11. Dompet membaca tag langsung dari tautan, atau mengirim permintaan web GET untuk mengambil data dan mengetahui operasi dari jawaban JSON. Format ini memberi nama dan struktur pada data agar dapat dibaca aplikasi. Jadi, gambar QR sendiri tidak membuktikan identitas penerima. Yang penting adalah isi tautan serta domain, tindakan, dan ketentuan yang kemudian ditampilkan. [2]

Dalam alur pembayaran, metadata adalah string teks yang memuat array JSON. Di dalamnya wajib ada deskripsi text/plain; jenis lainnya bersifat opsional. Dompet perlu menampilkan deskripsi bersama domain dan jumlah agar pengguna memahami persetujuannya. LNURL dasar menafsirkan isi jawaban JSON, bukan sekadar kode status HTTP. Server yang dapat dihubungi belum tentu berarti permintaan berhasil: jawabannya dapat berisi ERROR. Demikian pula, faktur yang baru diterima melalui pr belum dibayar. Aplikasi tidak seharusnya menyatukan informasi yang berbeda ini menjadi satu tanda centang hijau. [2] [3]