Finality

Awalnya Paul hanya tahu bahwa dompetnya telah mengetahui transaksi tersebut. Itu belum sama dengan transaksi masuk ke sebuah blok. Setelah blok terbentuk dan blok-blok berikutnya menyusul, mengganti riwayat itu membutuhkan kerja yang semakin besar untuk dilampaui. Begitulah Finality meningkat dalam praktik. Sumber daya calon penyerang dan kondisi jaringan tetap berpengaruh. Protokol tidak menerbitkan sertifikat matematis bahwa transaksi mustahil dibalik; penerima menilai seberapa kuat bukti untuk menerima pembayaran tertentu. [1] [2]

Full Node memeriksa aturan Bitcoin secara mandiri. Ia tidak menerima suatu riwayat hanya karena panjang. Keabsahannya diperiksa lebih dulu, lalu dipilih cabang valid dengan akumulasi kerja terbesar. Yang dihitung adalah kerja yang dibuktikan oleh blok, bukan suara berdasarkan jumlah orang atau kepemilikan koin. Kerja lebih besar tidak membuat transaksi tidak valid menjadi valid. Paul perlu memeriksa keduanya: apakah pembayaran mematuhi aturan, dan seberapa dalam letaknya dalam riwayat valid yang sedang diikuti. [1]

Dalam contoh kita, transaksi Paul berada di blok pada ketinggian 800000, sedangkan ujung cabang yang sama berada pada ketinggian 800005. Ketinggian menunjukkan posisi blok, bukan waktu. Perhitungannya adalah 800005 − 800000 + 1 = 6 konfirmasi, termasuk blok yang memuat transaksi itu sendiri. Jadi, bukan hanya blok-blok sesudahnya yang dihitung. Pembayaran yang baru berada dalam mempool, kumpulan transaksi belum terkonfirmasi milik node tersebut, memiliki 0 konfirmasi. Menunggu saja tidak menambah jumlahnya. [2] [3]

Jaringan dapat sesaat mengetahui blok-blok yang bersaing, lalu melanjutkan cabang valid lain dengan kerja lebih besar. Perubahan riwayat aktif ini disebut reorganisasi. Dalam dokumentasi Bitcoin Core 28.0, kueri header blok getblockheader mengembalikan confirmations = -1 jika blok tersebut berada di luar rantai aktif. Angka itu menjelaskan status blok, bukan berarti seluruh pembayaran di dalamnya otomatis hilang. Transaksi Paul mungkin juga masuk cabang baru, menunggu tanpa konfirmasi, atau berkonflik dengan transaksi lain. Status transaksi itu harus diperiksa kembali. [1] [3]

Panduan pengembang menyebut 6 konfirmasi sebagai ambang yang umum untuk pembayaran bernilai tinggi, sekaligus menjelaskan perlunya penilaian risiko. Ini aturan penerimaan milik penerima, bukan titik perubahan konsensus Bitcoin. Paul perlu mempertimbangkan nilai sepeda, potensi kerugian, dan keandalan verifikasinya; angka tidak mengambil keputusan untuknya. Rata-rata sekitar satu jam juga tidak berarti enam blok selalu muncul dalam satu jam. Penambangan tidak mempunyai jadwal tetap, dan anjuran umum lama bukan jaminan untuk setiap situasi. [2]

Paul bisa memiliki BTC terkonfirmasi tetapi masih berselisih tentang penyerahan atau kondisi sepeda. PFMI, prinsip internasional untuk infrastruktur pasar keuangan, mensyaratkan titik penyelesaian akhir yang jelas serta batas setelah peserta tidak lagi dapat membatalkan instruksi. Kerangka ini berbeda dari menghitung blok Bitcoin. Konfirmasi saja tidak menentukan akibat hukum kontrak, finalitas pembayaran bank, atau perpindahan hak milik atas barang. Memeriksa pembayaran itu penting, tetapi tidak menggantikan syarat-syarat perdagangan lainnya. [4]

Jika Paul dan pembeli sepakat mengembalikan dana, pengembalian biasa dilakukan melalui transaksi baru yang dikirim penerima pembayaran semula. Transfer awal tetap ada dalam riwayat. Bitcoin tidak memiliki pusat layanan dengan tombol untuk membatalkan pembayaran terkonfirmasi atas permintaan. Reorganisasi mengubah riwayat aktif jaringan; itu bukan layanan pelanggan untuk memperbaiki kesalahan. Karena itu, periksa penerima dan jumlah sebelum mengirim. Menunggu lebih banyak konfirmasi tidak memperbaiki pembayaran yang salah dimasukkan. [5]

Bagi pengelola aplikasi pembayaran, pekerjaan tidak selesai saat pembayaran diterima. Aplikasi perlu mencatat transaksi, bloknya, dan sumber verifikasi, serta mendeteksi apakah node tertinggal dari jaringan. Nilai confirmations menggambarkan keadaan saat kueri dilakukan, bukan sertifikat permanen. Jika jumlahnya turun atau muncul konflik, aplikasi membutuhkan aturan penanganan yang ditetapkan sebelumnya dan pemeriksaan ulang cabang aktif. Tangkapan layar lama bukan bukti baru. Bagi Paul, intinya adalah memutuskan berdasarkan keadaan pembayaran saat ini, bukan hanya tampilan dompet pada suatu waktu lalu. [2] [3]