Rusty Russell

Proyek besar sering dimulai secara sederhana. Retrospektif Blockstream pada 9 Juni 2026 mengenang commit pertama Russell tanggal 26 Mei 2015: alat kecil untuk membuat pesan pembukaan kanal. Commit adalah perubahan yang dicatat dalam riwayat kode. Percobaan awal itu tumbuh menjadi Core Lightning, dengan kontribusi Russell pada program, pengujian, dan bimbingan bagi pengembang lain. Artikel tersebut juga menjelaskan kepergiannya setelah sebelas tahun. Itu bukan pengumuman akhir seluruh kontribusi sumber terbukanya pada masa depan, dan peran kepemimpinan terdahulu bukan wewenang permanen atas jaringan. [1]

Bayangkan kafe dan pelanggan menggunakan program berbeda. Pembayaran tidak seharusnya bergantung pada pemilihan penyedia yang sama. Mereka memerlukan aturan bersama untuk pesan dan maknanya. Spesifikasi BOLT menjelaskan komunikasi ini dalam Lightning. Russell memimpin proses pengembangannya secara kolaboratif dan mendukung interoperabilitas, yaitu kemampuan implementasi berbeda untuk bekerja bersama. Repositori publik menerima usulan serta komentar. Namun, kontributor penting sekalipun tidak bisa sendirian memaksakan perubahan kepada semua node: aturan harus diwujudkan dalam perangkat lunak nyata dan penggunaannya. [1] [2]

Dua program bisa menafsirkan paragraf yang sama secara berbeda. lnprototest buatan Russell menyediakan alat dalam Python untuk menulis skenario dan menguji respons terhadap pesan protokol. README, dokumentasi pengantar proyek, membedakan pelaksana tiruan dari pengujian terhadap implementasi nyata. Simulasi membantu menyiapkan tes, tetapi keberhasilannya saja tidak membuktikan perilaku node sungguhan. Penting mengetahui apa yang benar-benar dijalankan dan situasi mana yang dicakup. Sekumpulan skenario yang lulus pun bukan audit lengkap terhadap semua kemungkinan cacat. [3]

Dengan BOLT 12, kafe dapat menerbitkan penawaran yang bisa dipakai kembali, misalnya kode QR. Dompet pelanggan mengirim invoice_request berdasarkan penawaran itu dan memperoleh invoice tertentu, yaitu permintaan berisi rincian pembayaran tersebut. Pembayaran dilakukan setelahnya. Penawaran dapat digunakan berulang kali sambil menghasilkan invoice masing-masing. Itu tidak berarti invoice yang sudah digunakan menjadi permintaan baru untuk setiap pembelian. Memisahkan penawaran, permintaan, dan invoice membuat pembayaran praktis tanpa mencampur transaksi berbeda. [4]

Core Lightning memperlihatkan pemisahan ini. Perintah fetchinvoice menghubungi penerbit penawaran dan mengambil invoice. Kolom changes dapat menunjukkan perbedaan dari penawaran, seperti jumlah atau deskripsi. Respons berhasil tidak mengirim uang. Ini seperti menerima tagihan kafe: periksa dahulu apa yang dibayar dan berapa jumlahnya. Dompet harus memproses ketentuan yang diterima lalu memulai pembayaran secara terpisah. Selesai mengambil permintaan tidak sama dengan selesai membayarnya. [5]

Dokumentasi pay membedakan complete, pending, dan failed: selesai, tertunda, dan gagal. Tertunda bukan berarti berhasil membayar. amount_msat adalah jumlah yang diterima penerima, sedangkan amount_sent_msat adalah total terkirim termasuk biaya. msat berarti millisatoshi, seperseribu satoshi. Karena itu, pelanggan dapat mengeluarkan biaya tambahan di atas jumlah yang diterima kafe. Dokumentasi kini menandai pay sebagai antarmuka usang dan menjelaskan peralihan ke xpay. Ini penjelasan status dan jumlah, bukan petunjuk memasang versi tertentu; baca hasil sesuai program yang benar-benar digunakan. [6]

Ketika kafe mengembalikan uang, pembayaran awal tidak diputar mundur. BOLT 12 juga menjelaskan alur sebaliknya: pedagang menyebutkan jumlah yang ingin dikirim, pelanggan memberikan invoice, dan pedagang memeriksa invoice_node_id, pengenal node yang akan dibayar. Lalu pembayaran baru dikirim kepada pelanggan. Ini tidak membatalkan transfer awal atau otomatis memberikan hak atas pengembalian dana. Protokol menyediakan cara pelaksanaannya; alasan dan ketentuannya perlu disepakati sendiri oleh para pihak. [4]

Saat ada sengketa, kita perlu memahami apa yang benar-benar dibuktikan. BOLT 12 menjelaskan bahwa preimage, nilai rahasia yang cocok dengan hash dalam permintaan pembayaran, dapat menunjukkan bahwa invoice telah dibayar. Namun, setelah diumumkan, orang lain juga dapat menunjukkannya; nilai itu sendiri tidak mengidentifikasi pengirim uang. Kunci dalam permintaan dapat membuktikan siapa yang meminta invoice, tetapi tidak otomatis memverifikasi identitas resmi orang tersebut. Invoice terbayar, kendali atas kunci, dan identitas pelanggan adalah informasi yang berbeda. [4]