Lightning memperketat aturan faktur setelah serangan yang dilaporkan mengaburkan penarikan yang telah dibayar

Pengembang Lightning merevisi BOLT11, standar faktur Lightning Network, pada 19 Oktober untuk mewajibkan penolakan atas kolom hash pembayaran dan rahasia pembayaran yang ambigu. Revisi itu menyusul laporan seorang pengembang tentang serangan yang membuat penarikan Bitcoin yang telah selesai tampak belum dibayar. Revisi yang digabungkan itu mengatasi perbedaan cara komponen perangkat lunak menafsirkan satu permintaan pembayaran bertanda tangan. Hash pembayaran mengidentifikasi pembayaran yang dilacak oleh suatu komponen. Bitcoin Optech menyoroti revisi itu pada 23 Oktober.

Pengembang Roasbeef melaporkan peretasan baru-baru ini terhadap bot peer-to-peer Telegram dalam pernyataan pada 10 September mengenai proposal tersebut. Roasbeef mengatakan serangan itu mengeksploitasi pustaka yang memilih hash berbeda dari sebuah faktur: sebagian memilih kolom hash pembayaran pertama, sedangkan yang lain memilih kolom terakhir. Roasbeef tidak menyebutkan tanggal insiden maupun jumlah kerugian. Layanan dapat mencatat penarikan menggunakan satu hash, sementara node membayar dengan hash yang berbeda. Akibatnya, layanan dapat menggolongkan penarikan yang telah selesai sebagai belum dibayar sehingga memungkinkan pembayaran tambahan. Kegagalan terjadi pada titik ketika pelaksanaan pembayaran terhubung dengan pencatatan layanan.

Spesifikasi BOLT11 saat ini mengizinkan tepat satu kolom hash pembayaran, yang ditandai p, dan tepat satu kolom rahasia pembayaran, yang ditandai s. Jika salah satu kolom tidak ada atau muncul berulang, pembayaran harus gagal. Persyaratan itu mengatasi ambiguitas pada kedua jenis kolom, meskipun serangan penarikan yang dilaporkan melibatkan hash pembayaran yang bertentangan. Pembaca faktur harus menghitung kemunculan kolom, bukan hanya menghitung nilai yang berbeda. Proposal tersebut mencakup faktur uji tidak valid yang mengulang hash identik maupun menggunakan hash berbeda. Karena itu, menggabungkan hash identik menjadi satu nilai akan gagal mengidentifikasi faktur yang harus ditolak.

Perangkat lunak node Lightning lnd menggabungkan penolakan hash duplikat pada 23 September, sebelum revisi spesifikasi. Rilis lnd v0.20.5-beta dan v0.21.4-beta yang tersedia mencakup perbaikan hash pembayaran. Proposal lnd terpisah yang membahas pemeriksaan rahasia pembayaran yang lebih luas masih terbuka per 27 Oktober. Proposal itu akan memperkuat validasi rahasia pembayaran dan pemeriksaan dekoder lainnya, termasuk penolakan kolom s yang berulang. Penulis proposal menjelaskan bahwa pemeriksaan pemrosesan pembayaran berikutnya sudah berlaku bagi sebagian faktur yang diterima dekoder. Karena itu, keberhasilan dekode saja tidak membuktikan bahwa pembayaran akan berhasil.

Kegagalan yang didokumentasikan itu menunjukkan bahwa operator pembayaran perlu menolak faktur ambigu. Pencatatan penarikan juga perlu menggunakan hash pembayaran yang dipakai node.