Jeff Garzik adalah pengembang yang dikenal melalui akun jgarzik. Ia mengerjakan perangkat lunak Bitcoin dan BIP, dokumen yang menjelaskan perubahan atau prosedur tertentu. Kontribusinya menunjukkan cara Bitcoin berkembang: seseorang dapat menulis kode dan mengusulkan aturan, tetapi tidak dapat memerintahkan seluruh jaringan untuk menerimanya.
Di GitHub, Jeff Garzik memakai nama jgarzik. Karyanya dapat ditelusuri melalui repositori tertentu, tempat publik yang menyimpan kode beserta riwayat perubahannya. Cara ini lebih berguna daripada memberi satu orang peran samar sebagai pihak yang “mengendalikan Bitcoin”. Untuk program, kita perlu mengetahui fungsinya dan versi yang sedang dilihat; untuk usulan, perubahan yang ingin dibuat. Profil pengembang sendiri tidak menentukan versi perangkat lunak yang dijalankan orang lain. [1]
README, berkas pengantar cpuminer milik Garzik, menjelaskannya sebagai program penambangan Bitcoin menggunakan CPU, yaitu prosesor komputer. Dukungan multithread memungkinkan perhitungan dibagi ke beberapa alur kerja yang berjalan bersamaan. Proyek pooler/cpuminer untuk Litecoin dan Bitcoin secara tegas menyebut program itu sebagai asalnya. Mengambil kode yang ada lalu mengembangkannya secara terpisah disebut fork proyek. Langkah itu sendiri tidak membelah jaringan Bitcoin, dan fitur yang ditambahkan kemudian belum tentu ada dalam program asli Garzik. [2] [3]
Contoh lain adalah Picocoin. Proyek ini mencakup libccoin, pustaka dalam bahasa C yang fungsinya dapat digunakan untuk membangun aplikasi Bitcoin. Namun, README menandai dompet HD dan node brd terkait sebagai WIP, artinya masih dikerjakan. Dompet HD menurunkan satu keluarga kunci dari dasar yang sama; node dimaksudkan untuk berkomunikasi dengan jaringan Bitcoin. Repositori diarsipkan pada 15 Februari 2024. Ia berguna untuk mempelajari sejarah, tetapi tersedianya kode saja tidak membuktikan adanya produk selesai, terpelihara, dan aman bagi tabungan Anda. [4]
Bayangkan sebuah node ingin mengetahui transaksi belum terkonfirmasi yang dikenal oleh node tetangganya. BIP 35 dari Garzik menangani kebutuhan itu: pesan mempool meminta daftar, jawaban inv membawa pengenal transaksi berupa hash, lalu getdata dapat meminta data transaksinya. Mempool merupakan “ruang tunggu” lokal sebelum konfirmasi, bukan daftar tunggal untuk seluruh dunia. Perintah getrawmempool dalam dokumentasi Bitcoin Core juga mengembalikan isi node tertentu. Menemukan transaksi di sana belum berarti transaksi tersebut sudah dikonfirmasi dalam blok. [5] [8]
Ukuran blok memengaruhi ruang untuk transaksi serta sumber daya yang diperlukan untuk mengirim dan memverifikasinya. Dalam BIP 100, Garzik, Tom Harding, dan Dagur Valberg Johannsson mengusulkan penyesuaian batas melalui suara yang dicatat penambang dalam blok. Perhitungan ulang dilakukan setiap 2016 blok, dengan syarat dukungan 75% dalam blok dan besaran perubahan yang dibatasi. Jadi, suara tidak dihitung berdasarkan jumlah orang. Registri menandai usulan sebagai Closed, atau ditutup; uraian itu tidak membuktikan bahwa seluruh jaringan Bitcoin menerima mekanismenya. [6]
Ambil contoh node biasa yang masih memeriksa batas awal 1 MB. Ketika blok lebih besar datang, node menolaknya meskipun penambangnya mendukung batas lebih tinggi. BIP 100 secara jelas memperingatkan pemisahan ini. Suara dalam blok adalah data yang bisa ditafsirkan perangkat lunak baru, bukan perintah untuk menulis ulang program lama. Perubahan yang mengizinkan blok yang ditolak aturan lama adalah Hard Fork. Arti fork ini berbeda dari sekadar membuat proyek turunan di GitHub. [6]
BIP 102 dari Garzik mengusulkan jalan lain: menaikkan batas sekali saja menjadi 2 MB. Aktivasi memerlukan terpenuhinya syarat waktu sekaligus sinyal dukungan dalam 95% dari 1000 blok terakhir. Terpenuhinya syarat itu tidak otomatis mengubah program validasi lama, yang tetap akan menolak blok lebih besar. Usulan ini juga berstatus Closed. Dokumen tersebut mencatat perubahan yang diusulkan, bukan menjelaskan aturan ukuran blok Bitcoin yang berlaku saat ini. [7]
Untuk setiap BIP, baca isi dan statusnya. BIP 35 tercatat sebagai Deployed, sudah diterapkan, pada lapisan Peer Services yang menangani layanan dan komunikasi antar-node. BIP 100 dan BIP 102 berstatus Closed pada lapisan Consensus (hard fork), karena menyangkut blok mana yang dianggap sah oleh node. Penulis yang sama dapat bekerja di kedua bidang dengan hasil berbeda. Keberhasilan menerapkan pesan jaringan tidak berarti semua usulan perubahan aturannya juga diterapkan. [5] [6] [7]
Untuk gambaran yang lebih utuh, baca entri ini bersama Cynthia Lummis, Mike Hearn, Perang ukuran blok. Entri ini juga dirujuk dari Mike Hearn.