Konfirmasi

Alice mengirim 20 000 sat, satuan terkecil bitcoin, kepada temannya. Dompetnya menampilkan Terkirim dan temannya sudah melihat pembayaran masuk, tetapi dengan nol konfirmasi. Ini tidak bertentangan: informasinya sudah menyebar di antara node, komputer yang memverifikasi Bitcoin, tetapi belum masuk blok. Mempool adalah tempat penyimpanan lokal transaksi belum terkonfirmasi pada suatu node, bukan satu antrean milik seluruh jaringan. Begitu pembayaran masuk blok yang diterima, konfirmasi pertama muncul. Blok berikutnya memberi konfirmasi kedua, lalu yang berikutnya lagi ketiga. Alice tidak perlu mengirim ulang. Menyiarkan transaksi bukan konfirmasi, dan pengenalnya, txid, juga tidak menjamin konfirmasi. Transaksi belum terkonfirmasi dapat diganti, misalnya melalui Replace-by-Fee (RBF) untuk menaikkan biaya. Menerima pembayaran tanpa konfirmasi disebut zero-conf dan berarti menanggung risiko bahwa pembelanjaan lain atas dana yang sama justru terkonfirmasi. [4] [8] [11]

Penambang memilih transaksi untuk blok baru dan mencari Proof of Work yang sah, hasil perhitungan yang memerlukan biaya dan memenuhi aturan Bitcoin. Full node lain kemudian memeriksa sendiri blok itu: apakah tanda tangan, jumlah dan syarat pembelanjaan benar, dan dananya belum dibelanjakan? Ini bukan pemungutan suara penambang atau stempel persetujuan satu perusahaan. Penambang tidak dapat membuat pembayaran tidak sah menjadi sah hanya dengan memasukkannya ke blok. Node menghitung konfirmasi hanya pada rantai yang diterimanya. Di antara cabang sah, node memilih yang memiliki akumulasi kerja terbesar, disebut chainwork. Setiap blok merujuk pendahulunya, sehingga mengubah riwayat lama juga memerlukan pembangunan ulang bagian sesudahnya. [2] [7]

Bitcoin menargetkan rata-rata sepuluh menit antarblok, bukan jadwal tetap. Blok baru dapat datang dalam hitungan detik atau jauh lebih lama. Menunggu satu jam tidak otomatis berarti enam konfirmasi. Tarif biaya lebih tinggi dapat meningkatkan peluang transaksi dipilih penambang, tetapi tidak mempercepat munculnya blok. Beberapa dompet menyediakan RBF, penggantian transaksi belum terkonfirmasi dengan transaksi berbiaya lebih tinggi, atau CPFP (Child Pays for Parent): transaksi lanjutan menambah biaya yang cukup agar penambang tertarik memasukkannya bersama transaksi induknya. Ketersediaannya bergantung pada dompet dan transaksi. Biaya rendah dapat berarti menunggu lama atau dikeluarkan dari Mempool suatu node. Perlakukan perkiraan dompet sebagai perkiraan, bukan batas waktu yang dijanjikan. [3] [4]

Penerima atau layanan menetapkan berapa konfirmasi yang diperlukan untuk mengakui pembayaran. Pembelian kecil dapat menoleransi risiko berbeda dari penyerahan barang mahal yang tidak bisa dibatalkan. Jika bursa menunggu beberapa konfirmasi, transaksi mungkin sudah ada di blockchain sementara saldo akun belum bertambah. Ini belum tentu kesalahan pembayaran. Periksa jumlah, alamat tujuan dan status dalam dompet, serta ketentuan pengkreditan layanan. Sumber informasi juga penting. Penyerang dapat mengisolasi node dan memberinya pandangan jaringan yang terbatas; ini disebut Eclipse Attack. Waktu tunggu yang sesuai bergantung pada nilai, kemungkinan memperbaiki akibatnya, kepercayaan kepada pihak lain dan cara verifikasi. Jumlah konfirmasi saja tidak melindungi dari kunci yang dicuri. [11] [13]

Bayangkan pembayaran sebagai catatan yang di atasnya terus bertambah halaman sejarah baru. Mengubah satu halaman lama tidak cukup: penyerang harus membuat kelanjutan sah yang bersaing dengan akumulasi kerja memadai. Dalam asumsi normal, konfirmasi tambahan membuatnya lebih sulit. Namun hasilnya juga bergantung pada daya komputasi penyerang dan kondisi jaringan. Enam konfirmasi yang sering disebut adalah pedoman historis, bukan aturan konsensus atau batas ajaib keamanan penuh. Tidak ada satu angka peluang penulisan ulang yang secara jujur mencakup semua keadaan. Lebih banyak konfirmasi juga tidak memperbaiki alamat salah atau pembayaran kepada penipu. [1] [13]

Percabangan singkat bisa terjadi tanpa serangan ketika dua penambang menemukan blok hampir bersamaan. Perpindahan node ke cabang pemenang lain disebut reorganisasi. Keluaran transaksi mencatat jumlah dan syarat pembelanjaan; masukan transaksi berikutnya merujuk keluaran itu dan membelanjakannya. Keluaran yang belum dibelanjakan disebut UTXO. Jika cabang pesaing yang valid mengumpulkan lebih banyak kerja, yaitu chainwork, node melepaskan blok-blok di ujung rantai semula dan menyambungkan cabang yang menang. Transaksi dari blok yang dilepas dapat kembali ke Mempool jika masih valid, atau dapat dikonfirmasi pada ketinggian lain. Transaksi itu juga dapat berkonflik jika cabang baru membelanjakan output yang sama dengan yang dirujuk inputnya. Nilai confirmations yang negatif dalam Bitcoin Core adalah cara dompet menyatakan kedalaman konflik. Itu bukan jumlah blok negatif dalam aturan konsensus. [5] [7]

Tinggi blok adalah posisinya dalam urutan, dihitung dari blok awal bernomor nol. Jika blok yang memuat transaksi berada pada ketinggian h dan blok terakhir rantai aktif node pada ketinggian H, jumlah konfirmasinya adalah H − h + 1. Jadi, blok yang memuat transaksi itu sendiri dihitung sebagai konfirmasi pertama. Hasilnya bergantung pada blok terverifikasi terbaik milik node tersebut, sehingga saat blok baru datang, angka itu dapat sesaat berbeda antar-node. Angka tersebut bukan bagian dari transaksi, tidak bertambah hanya karena waktu berlalu, dan tidak dapat ditentukan secara andal dari cap waktu. Bitcoin Core mengembalikan data seperti blockhash, blockheight, dan confirmations berdasarkan keadaan yang diketahui dompet terkait atau tampilan UTXO. [3] [5] [6]

SPV berarti verifikasi pembayaran sederhana, sedangkan RPC adalah antarmuka pemrograman untuk bertanya kepada node. Perbedaan metode verifikasi tetap penting meski dua aplikasi menampilkan jumlah yang sama. Full node memvalidasi rantai dan menjawab berdasarkan ujung terkini dari rantai yang telah diverifikasinya sendiri. Klien SPV memeriksa Proof of Work pada header blok serta bukti Merkle bahwa transaksi disertakan, tetapi tidak memverifikasi seluruh aturan konsensus sendiri. Bukti Merkle memakai sejumlah kecil sidik jari kriptografis data untuk menunjukkan bahwa transaksi termuat dalam blok, tanpa perlu mengunduh semua transaksi dalam blok tersebut. Layanan yang memegang dana atas nama pengguna juga menerapkan aturan sendiri untuk mengkreditkan pembayaran dan mengelola risiko. Bahkan hasil RPC dari full node menggambarkan keadaan pada satu saat tertentu yang dapat berubah akibat reorganisasi. Jadi, selain jumlah konfirmasi, penting pula siapa yang dipercaya pengguna untuk memantau rantai, memverifikasinya, dan menyimpan dana. [1] [2] [8]

Coinbase Transaction adalah transaksi pertama khusus dalam blok yang membayar imbalan penambang; tidak berkaitan dengan bursa Coinbase. Kunci waktu membatasi kapan dana boleh dibelanjakan. BIP menandai dokumen usulan teknis atau standar. Konfirmasi juga memulai beberapa masa tunggu dalam protokol. Output transaksi coinbase tunduk pada aturan COINBASE_MATURITY = 100: output itu paling awal dapat dibelanjakan dalam blok yang ketinggiannya 100 lebih tinggi daripada blok yang memuat transaksi coinbase tersebut. Ini adalah masa tunggu wajib sebelum imbalan blok dibelanjakan, bukan pilihan penerima pembayaran biasa. Penguncian waktu relatif BIP68 berpatokan pada konfirmasi output yang dibelanjakan dan menilai usianya menurut aturan berbasis blok atau waktu. Skrip adalah program singkat yang menetapkan syarat untuk membelanjakan suatu output. Perintah CHECKSEQUENCEVERIFY (CSV) dari BIP112 memungkinkan syarat relatif itu ditegakkan dalam skrip. Transaksi yang membelanjakan output tanpa konfirmasi tetap bergantung pada transaksi yang membuat output tersebut. Agar transaksi lanjutan dapat dikonfirmasi, transaksi pendahulunya harus disertakan dalam blok yang sama atau blok sebelumnya. [9] [10]

Lightning Network memungkinkan pembayaran melalui kanal yang didanai transaksi Bitcoin. BOLT adalah nama spesifikasi teknisnya; bagian ini membahas pembukaan kanal, bukan menunggu blok pada setiap pembayaran di dalamnya. BOLT 2 memungkinkan pihak yang menerima pembukaan kanal Lightning menetapkan jumlah konfirmasi yang diperlukan untuk transaksi pendanaan melalui kolom minimum_depth, sebelum mengirim pesan channel_ready. Persyaratan ini memperhitungkan risiko pembelanjaan ganda pada pendanaan. Kanal yang dibuka tanpa konfirmasi, atau zero-conf channel, menetapkan minimum_depth ke nol dan secara sadar mengandalkan kepercayaan kepada penyedia dana serta pembatasan protokol. Itu tidak memberikan penyelesaian seketika yang tidak dapat dibatalkan. Jika transaksi pendanaan itu sendiri merupakan transaksi coinbase, BOLT 2 mewajibkan pihak yang tidak membuka kanal untuk menunggu setidaknya 100 blok. Operator perlu memantau output pendanaan tertentu, yaitu funding outpoint, kedalamannya dalam rantai aktif, dan reorganisasi. Menyiarkan txid saja belum berarti kanal sudah terbuka. [12] [14]