Lightning Address

Anna ingin menerima dukungan untuk podcast-nya. Daripada mengirim invoice panjang yang baru kepada setiap pendengar, ia menerbitkan Lightning Address. Contoh anna@example.com mudah diingat: bagian sebelum @ menunjukkan penerima di layanan tersebut, sedangkan bagian sesudahnya adalah domain yang menjawab dompet. Bentuknya sengaja menyerupai email, tetapi uang tidak dikirim lewat email. Alamat email yang sudah ada tidak otomatis menjadi Lightning Address, dan nama saja tidak membuktikan siapa pemiliknya. Jadi, periksa alamat itu melalui kreator yang ingin Anda dukung. [1] [6]

Pendengar memasukkan nama ke dompet yang kompatibel. Dompet mengambil keterangan pembayaran dan rentang jumlah yang diizinkan dari layanan. Setelah pengguna memeriksa domain, keterangan, dan jumlah pilihan, dompet meminta invoice BOLT 11 tertentu lalu memeriksa jumlahnya sebelum membayar. Memperoleh invoice belum berarti membayar. Proses ini disebut LNURL-pay. Layanan mengembalikan callback, alamat untuk meminta invoice, metadata berisi keterangan, serta batas minSendable dan maxSendable. amount dinyatakan dalam msat, seperseribu satoshi: 1000 msat = 1 sat. Invoice diterima dalam kolom pr. [2] [3]

Anna bisa memakai layanan yang mengelola dompetnya atau menghubungkan nama ke node Lightning miliknya, perangkat lunak yang menangani pembayarannya. Bentuk alamat tidak memperlihatkan perbedaannya. Endpoint web, tempat server menjawab dompet, bisa meminta invoice dari node melalui server perantara. Perantara ini belum tentu menyimpan dana; itu bergantung pada susunan sistem dan izin yang diberikan. Namun, kendali atas jawaban server tetap penting: pihak yang bisa menggantinya dapat menyodorkan invoice lain kepada pembayar. Memiliki domain sendiri tidak otomatis menjamin self-custody, yaitu mengendalikan kunci sendiri. [3] [4]

Dompet bisa mengirim ke Lightning Address tanpa memberikan alamat penerimaan pribadi kepada pengguna. Penerimaan juga memerlukan layanan web yang tersedia, pembuatan invoice, dan kemampuan menerima pembayaran di Lightning Network. Pembayaran melewati kanal, yaitu hubungan antarpeserta tempat pembagian dana pada kedua sisi berubah saat pembayaran dilakukan. Salah satunya adalah Inbound Liquidity: dana di sisi lain kanal yang dapat berpindah ke penerima saat pembayaran berlangsung. Nama yang mudah diingat tidak menciptakan likuiditas masuk itu. Jika alamat terbuka tetapi pembayaran gagal, penyebabnya belum tentu nama. Bedakan jawaban situs, invoice yang diperoleh, dan dana yang dipastikan sudah diterima. [3] [5]

Dengan domain sendiri, Anda bisa mengganti server pembayaran sambil mempertahankan nama yang dikenal pendengar. Dokumentasi BTCPay memperlihatkan pengalihan endpoint melalui HTTP 301: permintaan web menuju tempat lain, tanpa memindahkan koin. Nama pada domain milik pihak lain belum tentu memberi kendali tersebut. Seed Phrase, kata-kata pemulihan dompet, tidak dengan sendirinya menjamin pulihnya akses ke akun layanan. Seed Phrase juga tidak mencadangkan akses pengelolaan domain atau pengaturan DNS, sistem yang menentukan ke mana domain mengarah. Setelah perubahan, periksa invoice yang benar dan pembayaran percobaan yang benar-benar diterima, bukan hanya apakah alamat bisa dibuka. Kontak lama tidak otomatis mengetahui nama baru. [5] [3]

LUD-16 menjelaskan perubahan nama menjadi permintaan web GET, yaitu permintaan data. Dompet menghubungi domain pada jalur /.well-known/lnurlp/username, dengan mengganti username memakai nama pengguna. Web biasa menggunakan HTTPS, sedangkan domain onion menggunakan HTTP. Jawaban payRequest meneruskan proses sesuai LUD-06. HTTPS melindungi koneksi dari perubahan di tengah perjalanan, tetapi tidak membuktikan kejujuran layanan itu sendiri. Layanan memproses permintaan dan tahu penerima yang dibuatkan invoice. Karena itu, nama yang mudah dibaca tidak dengan sendirinya menambah anonimitas. [1] [2]

LUD-16 mengizinkan huruf kecil a-z, angka 0-9, dan -_. pada nama pengguna; email biasa mengizinkan lebih banyak karakter. Bentuk singkat opsional @domain menunjuk penerima bawaan _@domain pada jalur /.well-known/lnurlp/_, tetapi dompet atau layanan boleh tidak mendukungnya. Tambahan +tag juga tidak universal. Layanan yang mendukungnya bisa membedakan tujuan kontribusi dan mencantumkannya sebagai text/tag. Ini bukan kunci privat baru atau jaminan privasi. Untuk pemakaian sehari-hari, salin nama persis seperti yang diterbitkan penerima. [1]

Metadata adalah informasi tambahan yang dipertukarkan dompet dan layanan dalam format terstruktur JSON. Pada LNURL-pay, isinya mencakup text/plain, keterangan singkat pembayaran. LUD-16 menambahkan text/identifier untuk mengaitkannya dengan nama, atau text/email jika nama itu merupakan alamat email sungguhan. Informasi ini membantu dompet menampilkan tujuan pembayaran. Namun, sumbernya tetap layanan, bukan pemeriksaan independen atas identitas nyata Anna. Memeriksa alamat yang semula diperoleh, domain, dan jumlah tetap menjadi bagian dari membayar dengan cermat. [1] [2]