HTLC

Anna ingin mengirim 20.000 sat kepada Pavel melalui Lightning Network. Sat adalah singkatan dari satoshi, satuan bitcoin terkecil pada rantai. Mereka tidak memiliki kanal pembayaran bersama, tetapi keduanya mempunyai koneksi yang sesuai melalui Eva. Kanal adalah kesepakatan dua peserta tentang pembagian bitcoin yang dapat diperbarui tanpa mencatat setiap pembayaran dalam blok. Eva menawarkan pembayaran bersyarat 20.000 sat kepada Pavel, sementara Anna menawarkan 20.010 sat kepada Eva. Selisih 10 sat menjadi biaya Eva dalam contoh sederhana ini. Yang terjadi adalah perubahan saldo terkait pada dua kanal, bukan satu koin tertentu yang berpindah melintasi keduanya. Pavel mengetahui rahasia untuk memenuhi syaratnya. Eva kemudian dapat memakai nilai yang sama terhadap Anna. Ia tidak perlu lebih dahulu membayar Pavel secara permanen hanya berdasarkan janji. Angka ini menjelaskan mekanismenya, bukan biaya lazim atau yang disarankan. [1]

Pavel menyiapkan rahasia acak sepanjang 32 byte untuk pembayaran, yaitu payment_preimage. SHA-256 menghitung payment_hash darinya. Memeriksa apakah nilai yang diungkap menghasilkan sidik jari yang benar mudah dilakukan; mendapatkan rahasia yang dipilih dengan baik hanya dari sidik jarinya praktis tidak mungkin. Invoice BOLT 11 biasa, yakni permintaan pembayaran Lightning, memuat hash pada kolom p, bukan preimage itu sendiri. Ketika Pavel memenuhi pembayaran, rahasia dikirim kembali sepanjang rute dan menghubungkan HTLC terkait. payment_secret pada kolom s berbeda: nilai ini membantu penerima memproses pembayaran dengan benar dan tidak menggantikan preimage. Tidak satu pun nilai tersebut merupakan Seed Phrase (kata-kata untuk memulihkan dompet) atau kunci privat dompet. [1] [4]

Jika kedua pembayaran memiliki tenggat yang sama, Pavel dapat mengungkap rahasia terlalu terlambat sehingga Eva tidak sempat mengeklaim pembayaran masuk. Karena itu, HTLC masuk dari Anna kedaluwarsa lebih lambat daripada HTLC keluar Eva kepada Pavel. Selisih yang disebut cltv_expiry_delta memberi Eva cadangan waktu. Cadangan ini juga diperlukan jika pihak lain berhenti merespons dan kesepakatan harus ditegakkan melalui transaksi Bitcoin on-chain. Cadangan dihitung dalam blok, bukan menit yang pasti, serta harus memperhitungkan keterlambatan dan reorganisasi rantai. Perangkat lunak dan aturan kanal menentukan pengaturan yang aman; cadangan terlalu kecil membahayakan dana. Reorganisasi mengganti sebagian rantai dengan cabang valid lainnya, sehingga status konfirmasi transaksi sebelumnya dapat berubah. [1]

Dalam Lightning, cltv_expiry adalah tinggi blok, yakni posisi blok dalam rantai. Ini bukan Unix timestamp (tanggal dan waktu yang dinyatakan sebagai hitungan detik) atau masa berlaku invoice BOLT 11 dalam detik. Setelah syarat waktu terpenuhi, jalur timeout mungkin tersedia untuk penyelesaian tanpa rahasia. Dana tidak bergerak sendiri: node Lightning, yaitu program pengelola kanal pembayaran, harus menyelesaikan pembaruan kanal dengan benar atau memakai transaksi on-chain yang sesuai. Preimage yang valid juga tidak otomatis berhenti berfungsi saat tenggat berakhir. Jika output yang sama, yaitu sejumlah dana dengan aturan pembelanjaan, belum dibelanjakan melalui cara lain, jalur pembelanjaan yang diizinkan dapat bersaing; keduanya tidak dapat dikonfirmasi dalam satu rantai valid. Tindakan tepat waktu karena itu merupakan bagian dari keamanan. [1] [4] [5]

HTLC menghubungkan syarat, tetapi tidak membuat berapa pun jumlah dana bisa melewati rute mana pun. Eva membutuhkan dana yang cukup ke arah keluar, disebut likuiditas, serta ruang untuk satu HTLC tertunda lagi. Batas, biaya, atau node yang tidak tersedia dapat menghentikan pembayaran. Selama percobaan tertunda belum diselesaikan dengan benar, sebagian dana dapat tetap terikat. Status dompet menjelaskan keseluruhan percobaan; satu pesan saja bukan bukti hasilnya. Mengungkap preimage tidak sama dengan mengonfirmasi transaksi Bitcoin. Pembayaran Lightning biasa yang berhasil akan diselesaikan melalui perubahan kanal, tanpa mencatat setiap pembayaran dalam blok baru. [1] [3]

Bagian berikut merupakan referensi teknis. Status kanal mencatat siapa berhak atas setiap jumlah dan HTLC mana yang masih tertunda. Commitment transaction adalah transaksi Bitcoin bertanda tangan yang dapat menegakkan status itu on-chain. update_add_htlc baru mengusulkan penambahan; update_fulfill_htlc melaporkan pemenuhan dan update_fail_htlc kegagalan. Mengumumkan perubahan saja tidak cukup. Melalui commitment_signed dan revoke_and_ack, para pihak bertukar tanda tangan status baru serta informasi yang membuat penggunaan status lama tidak aman. Menurut BOLT 2, keduanya harus menyetujui perubahan terkait secara tidak dapat dicabut sebelum kewajiban berikutnya bergantung padanya. Kesepakatan peserta ini bukan konfirmasi dalam blok. Sebaliknya, pendanaan dan kemungkinan penutupan kanal bertumpu pada transaksi Bitcoin. [1]

Kolom adalah nilai individual dalam pesan. Millisatoshi adalah seperseribu satoshi, satuan pencatatan di dalam Lightning; pecahan ini tidak dapat dibelanjakan tersendiri pada rantai Bitcoin. Dasar pesan update_add_htlc berisi channel_id, id, amount_msat, payment_hash, cltv_expiry, dan onion_routing_packet. amount_msat dinyatakan dalam millisatoshi. Node memeriksa batas kanal, likuiditas tersedia, dan syarat penerusan; HTLC keluar memiliki parameternya sendiri. Node tidak boleh menawarkan HTLC terkait sebelum penambahan HTLC masuk disepakati secara tidak dapat dicabut menurut BOLT 2. [1]

Onion routing membungkus petunjuk setiap perantara dalam lapisan terenkripsi yang terpisah. Eva menerima informasi untuk langkahnya, bukan daftar terbuka semua peserta. Node mendekripsi lapisan onion miliknya dan memverifikasi integritasnya. Pada rute biasa yang tidak dibutakan, node membandingkan amt_to_forward dan outgoing_cltv_value dengan jumlah masuk, biaya, dan selisih waktu yang disyaratkan. Paket tidak mengungkap seluruh rute kepadanya. Ini tidak meniadakan korelasi lalu lintas atau penarikan kesimpulan identitas lainnya; onion routing bukan jaminan anonimitas mutlak. [3]

Output adalah jumlah dana dengan aturan pembelanjaan yang ditulis dalam bahasa Script. Offered dan received berarti HTLC yang ditawarkan dan diterima dari sudut pandang peserta kanal. Tahap kedua adalah transaksi lanjutan; CHECKSEQUENCEVERIFY (CSV) mewajibkan waktu tunggu sejak konfirmasi output yang dibelanjakan. Kunci pencabutan memungkinkan penalti atas publikasi status lama yang sudah dicabut. BOLT 3 membedakan output offered dan received serta jalur HTLC-success atau HTLC-timeout. Mengetahui hash saja tidak cukup: tanda tangan, preimage, dan syarat waktu yang sesuai tetap berlaku. Output lokal tahap kedua memiliki penundaan CSV sebesar to_self_delay, sedangkan kunci pencabutan yang benar memungkinkan pihak lawan memakai cabang penalti tanpa penundaan itu. Script tepatnya bergantung pada jenis kanal. [2] [6]

Trimming berarti HTLC kecil tidak menjadi output tersendiri saat status kanal dibawa on-chain. Dust merujuk pada jumlah kecil tersebut. Dust exposure mengukur total nilai yang terkena keterbatasan ini. Jika jumlah setelah biaya tahap kedua yang berlaku kurang dari dust_limit_satoshis, transaksi komitmen tidak membuat output HTLC. Aturannya bergantung pada jenis yang disepakati: option_anchors dan zero_fee_commitments tidak memiliki biaya tahap kedua tersebut; zero_fee_commitments dapat mengarahkan nilai yang dipangkas ke shared_anchor. Output yang tidak ada tidak dapat diklaim tersendiri on-chain. Jumlah seluruh HTLC semacam ini membentuk dust exposure. [2] [1]

Pemeriksaan berikut ditujukan kepada operator node dan pengembang. Decoding mengubah catatan menjadi kolom yang dapat dibaca; tindakan ini tidak mengirim apa pun atau dengan sendirinya membuktikan semua syarat terpenuhi. Bandingkan amount_msat, payment_hash, dan cltv_expiry masuk serta keluar; verifikasi preimage dengan SHA-256. Pantau juga commitment_signed, revoke_and_ack, dan status akhir, bukan hanya satu pesan fulfill/fail. Untuk penegakan on-chain, dekode transaksi komitmen sebenarnya, periksa keberadaan output, cabang yang dipakai, dan HTLC-success/HTLC-timeout. Periksa tanda tangan, syarat waktu, dan konfirmasi; decoding saja tidak membuktikan validitas. [1] [2]