Biaya 1% Melawan Biaya 4%: Mengapa Membandingkan Pool Berdasarkan Satu Angka Gagal dan Cara Menyusun Penilaian dari Empat Faktor

TL;DR

Biaya pool hanyalah satu dari empat input, dan bukan yang paling berbobot. Di sampingnya ada risiko operator, keandalan apa yang dipublikasikan pool tentang dirinya sendiri, dan likuiditas pembayaran: berapa hari sampai uang masuk ke dompet Anda dan berapa banyak yang hilang di jalan. Di bawah ini diuraikan metodologi yang menggabungkan empat komponen ini menjadi satu angka, dan dijelaskan di mana angka semacam itu berbohong.

POOL BTC bukan mining pool, melainkan situs perbandingan pool yang independen. Penilaian di bawah ini merujuk pada layanan pihak lain, dan metodologinya terbuka justru agar bisa dibantah.

Ide penilaian multifaktor ini bukan milik kami. Minerstat pada September 2026 mempublikasikan uraian opportunity score miliknya dari empat komponen (profit, risk, data confidence, liquidity), dan hal itulah yang mendorong kami menjelaskan pendekatan kami sendiri secara terbuka. Kami tidak menyalin formula kompetitor dan tidak mengaku-aku koefisien mereka sebagai milik kami: yang sama hanya susunan komponennya, karena itu jelas bagi siapa pun yang pernah menghitung imbal hasil sendiri.

Mengapa membandingkan pool berdasarkan satu biaya memberi jawaban yang salah?

Karena biaya tidak menjelaskan apa yang sebenarnya dibagi, maupun apakah uangnya akan sampai. Pool dengan 2% di PPLNS dan pool dengan 4% di FPPS membayar untuk hal yang berbeda: pada kasus kedua, biaya transaksi blok masuk ke dalam basis. Ditambah lagi ambang pembayaran, biaya jaringan saat penarikan, dan kemungkinan operator mengubah aturan, sama sekali tidak tercermin dalam persentase.

Mari kita lihat dengan angka yang sudah diverifikasi. Untuk bitcoin, F2Pool secara resmi menjalankan tiga skema sekaligus: FPPS 4%, PPS+ 2.5%, dan PPLNS 2% (bantuan F2Pool, diperiksa 29.08.2026). Memilih baris termurah lalu berhenti di situ tidak bisa dilakukan, karena PPLNS membebankan biaya transaksi riil dari blok yang ditemukan, sementara FPPS merata-ratakannya dari hari sebelumnya dan membayar terlepas dari apakah pool beruntung mendapat blok atau tidak. Mana yang lebih menguntungkan tergantung pada horizon Anda dan berapa nilai biaya transaksi saat itu.

Dan nilainya kadang hampir nol, kadang lebih besar dari subsidi:

Dalam kondisi tenang September 2026, selisih antara "berbagi porsi biaya" dan "tidak berbagi" hanya sepersekian persen pendapatan, dan pada kondisi seperti ini biaya yang diklaim memang menjadi faktor utama. Tapi pada 20 April 2024, selisih yang sama bernilai tiga perempat pendapatan harian. Metodologi yang bertumpu pada satu angka saja gagal tepat pada hari-hari seperti itu.

Hal kedua yang tidak terlihat dalam persentase: berapa biaya untuk menarik uangnya. Luxor punya ambang pembayaran 0.001 BTC ditambah biaya jaringan 0.000075 BTC, artinya saldo harus terkumpul lebih dari 0.001075 BTC, dan biaya jaringan ditanggung pengguna (dokumentasi Luxor). NiceHash mengenakan biaya layanan 2% saat pembayaran masuk, sementara penarikan dari dompet layanan adalah operasi terpisah: minimum 0.0005 BTC dan biaya mulai dari 0.0001 BTC di atasnya (halaman resmi NiceHash, diakses 02.09.2026). Mana yang lebih mahal bagi penambang tertentu tergantung pada hashrate-nya, bukan pada persentase yang tertera di etalase.

Uraian lengkap tentang semua hal yang terpotong di luar persentase yang diklaim ada di artikel terpisah tentang biaya riil komisi pool. Yang penting di sini: bahkan biaya efektif yang dihitung secara sempurna pun tetap hanya satu komponen dari empat.

Dari komponen apa saja penilaian pool yang jujur tersusun?

Dari empat komponen, dan masing-masing menjawab pertanyaan yang berbeda. Imbal hasil menjawab "berapa BTC per hari". Risiko operator menjawab "seberapa besar kemungkinan BTC itu tidak sampai ke saya". Keandalan data menjawab "seberapa bisa dipercaya kedua penilaian di atas". Likuiditas menjawab "kapan tepatnya saya melihat uangnya dan berapa yang hilang saat penarikan".

Urutan di sini bukan acak. Imbal hasil dihitung pertama karena tanpa itu yang lain tidak berarti, sedangkan keandalan data ada di posisi ketiga, tapi sebenarnya berfungsi sebagai filter sebelum semua yang lain: jika biaya pool tidak dipublikasikan, Anda tidak menghitung imbal hasil, melainkan menebaknya.

Halaman metodologi peringkat kami saat ini hanya menjelaskan komponen pertama, perhitungan net BTC/day. Tiga komponen lainnya kami terapkan saat penyaringan, tapi belum pernah diformalkan di mana pun, dan artikel ini menutup celah tersebut.

Bagaimana menghitung komponen imbal hasil dan mengapa net BTC/day, bukan persentase yang diklaim?

Karena persentase biaya adalah koefisien di dalam formula, bukan hasil akhirnya. Yang menarik bagi penambang adalah keluaran bersih setelah biaya pool dan setelah listrik, dinyatakan dalam BTC per hari pada hashrate miliknya sendiri. Pool yang sama bisa menjadi yang terbaik untuk farm dengan tarif 3 sen dan yang terburuk untuk penambang rumahan dengan tarif mahal.

Formula yang digunakan POOL BTC untuk menghitung:

\`\`\`

net BTC/day = (hashrate Anda / hashrate jaringan) × 144 × (subsidi + rata-rata biaya blok) × (1 - biaya pool) - listrik dalam BTC

\`\`\`

Yang penting pada setiap faktor:

1. Hashrate jaringan diambil dari API publik dan berubah setiap hari. Pada cuplikan 29.08.2026 angkanya 896.89 EH/s dengan difficulty 125 807 076 547 197.5, sedangkan pada cuplikan 09.09.2026 sudah 943.73 EH/s dengan difficulty 127 450 789 715 843.1 (mempool.space). Dalam sebelas hari jaringan tumbuh 5.2%, dan "tabel imbal hasil" tanpa tanggal pengambilan data mana pun jadi tidak berguna.
2. Subsidi 3.125 BTC per blok setelah halving 2024. Ini satu-satunya input yang benar-benar stabil dalam formula.
3. Rata-rata biaya blok hanya dihitung untuk skema yang membagikannya. FPPS dan PPS+ membagikannya, PPS klasik hanya membayar dari subsidi. Dari sinilah muncul kesenjangan antara biaya yang diklaim dan biaya efektif.
4. Listrik dikonversi ke BTC dengan kurs saat ini. Ini satu-satunya input yang hanya Anda yang tahu, dan paling sering menentukan hasil perbandingan.

Selanjutnya mulai hal yang tidak enak. Formula memuat "biaya pool", tapi angka ini tidak bisa didapat untuk kira-kira separuh pool besar, dan ini sudah masuk komponen ketiga, bukan pertama. Tentang bagaimana skema pembayaran mengubah varians sekaligus pendapatan akhir, dibahas rinci di uraian FPPS dan PPLNS.

Menghitung ini di kepala tidak perlu, untuk itulah ada kalkulator pembayaran: alat ini memasukkan parameter jaringan terkini dan harga kilowatt Anda.

Apa itu risiko operator pool dan bagaimana cara menilainya dari luar?

Risiko operator adalah kemungkinan bahwa imbal hasil yang sudah dihitung tidak sampai ke Anda: pool tutup, mengubah aturan pembayaran, macet selama seminggu, atau menghapus saldo Anda atas dasar formal. Dari luar hal ini tidak bisa diukur secara pasti, tapi punya tanda-tanda yang bisa diamati, dan hampir semuanya ada di dokumen terbuka yang jarang dibaca orang.

Apa yang benar-benar bisa diperiksa tanpa informasi orang dalam:

• Ketentuan layanan terkait saldo dan sisa yang belum dibayarkan. Di F2Pool hal ini tertulis jelas: jika alamat pembayaran tidak diatur lebih dari 90 hari, reward "may be treated as a donation", dan menurut ketentuan layanan, jika tidak ada alamat valid dalam 6 bulan setelah pemberitahuan tertulis, pengguna kehilangan hak atas yang sudah terakumulasi. Ini bukan skandal atau jebakan, ini baris kontrak biasa, tapi patut dibaca sebelum, bukan sesudah.
• Kustodi. Pool yang menahan saldo Anda sampai ambang batas, selama itu berperan sebagai debitur Anda. Pool dengan pembayaran langsung ke dompet dan ambang rendah membuat Anda lebih sedikit menjadi kreditur.
• Skema pembayaran sebagai pemindahan risiko. Pada skema mirip PPS, varians ditanggung operator, dan ini nyaman selama operator solven. Pada PPLNS, varians tetap ada di pihak Anda, tapi kewajiban pool terhadap Anda lebih kecil.
• Konsentrasi hashrate. Pangsa jaringan yang besar berarti keteraturan pembayaran sekaligus risiko sistemik bagi bitcoin itu sendiri. Kedua efek ini nyata, dan menggabungkannya jadi satu skor tanpa catatan itu tidak jujur.
• Riwayat insiden dan bagaimana pool membicarakannya. Log gangguan publik lebih berbobot daripada angka uptime yang indah tanpa metodologi pengukuran.
• Yurisdiksi dan persyaratan verifikasi. Keduanya berubah, dan berubah secara retroaktif untuk saldo yang sudah ditambang.

Bagaimana hashrate jaringan terdistribusi di antara pool-pool

Pengukuran langsung hashrate pool tidak ada, jadi industri menghitung pangsa berdasarkan blok yang ditemukan: explorer mengaitkan blok ke pool lewat tag di transaksi coinbase dan membaginya dengan jumlah total blok dalam periode. Berikut data mempool.space per 09.09.2026 untuk dua jendela rata-rata, mingguan dan bulanan. Pangsanya terus berubah, dan tabel semacam ini hanya berguna bersama tanggal cuplikannya.

Sumber kedua jendela: mempool.space Mining Pools API, diakses 09.09.2026.

Apa yang berguna bagi pembaca dari tabel ini. Tiga besar teratas menguasai sekitar 58% jaringan pada kedua jendela, dan ini adalah kasus di mana keteraturan pembayaran pool besar dan risiko sistemik bagi bitcoin tumbuh bersamaan. Selanjutnya, perbedaan antar jendela menunjukkan seberapa berisik angka tersebut: pangsa mingguan SECPOOL lebih tinggi sekitar sepertiga dibanding pangsa bulanannya, sedangkan 1.33% mingguan NiceHash bahkan hilang dari dua belas besar pada jendela bulanan. Membandingkan pool berdasarkan pangsa yang diambil pada hari berbeda dengan jendela berbeda tidak ada gunanya.

Pool mana yang punya halaman status publik

Hampir tidak ada yang punya. Kami memeriksa sembilan pool per 09.09.2026, dan halaman status yang lengkap hanya ditemukan pada satu pool.

Ini lebih penting dari kelihatannya. Uptime yang diklaim hampir mustahil diverifikasi dari luar: delapan dari sembilan pool tidak punya riwayat insiden maupun indikator ketersediaan yang terukur, dan klaim 99.9% dalam pemasaran tetap menjadi pernyataan yang tidak bisa dibantah. Satu-satunya besaran yang bisa diverifikasi di sini bukan persentasenya, melainkan fakta ada atau tidaknya halaman itu sendiri.

Khusus soal uptime sebagai metrik. Tidak satu pun pool dalam cuplikan kami mempublikasikan indikator ketersediaan terukur dengan metodologi yang dijelaskan: angka itu akan menjadi komitmen, dan mengukurnya secara jujur harus dilakukan dari luar. Karena itu dalam penilaian risiko, uptime berperan sebagai tanda yang diamati (apakah ada halaman status, apakah ada beberapa titik akses), bukan sebagai persentase.

Bagaimana mengetahui seberapa bisa dipercaya angka yang dipublikasikan pool tentang dirinya sendiri?

Dengan satu kriteria: apakah pool membuka halaman berisi biaya dan ambang batas di situsnya sendiri, tanpa login, dengan tanggal. Jika biaya hanya diketahui lewat agregator, Anda tidak membandingkan pool, melainkan penyajian ulang pool oleh pihak lain. Komponen ini bisa diverifikasi sepenuhnya dari luar dan karena itu satu-satunya yang tidak memerlukan kepercayaan pada kata-kata operator.

Bagaimana bentuknya dalam praktik. Saat verifikasi 29.08.2026, kami membuka sendiri halaman-halaman yang meragukan di browser, dan berikut hasilnya:

Dari tabel ini muncul kesimpulan yang jauh lebih penting dari peringkat apa pun: untuk empat pool dalam daftar, angka biaya di perbandingan mana pun, termasuk perbandingan kami, bukanlah fakta, melainkan rumor bertanggal. Dan jika dua pool berbeda 0.5 poin persentase sementara salah satunya biayanya sama sekali tidak dipublikasikan, selisih 0.5 poin itu tidak berarti apa-apa.

Skala sederhana yang kami gunakan:

1. Dipublikasikan di halaman resmi, terbuka tanpa login, ada tanggal verifikasi manual kami.
2. Dipublikasikan, tapi tidak lengkap: sebagian parameter ada, sebagian hanya di dukungan atau chat.
3. Hanya di balik login atau hanya lewat agregator, tanpa konfirmasi resmi.
4. Sumber saling bertentangan, dan kontradiksinya belum terselesaikan.

Tingkat keempat lebih sering muncul daripada yang kita harapkan. Pada EMCD kami menemukan konflik dua ambang batas yang belum terselesaikan sejak Agustus, dan kesimpulan yang benar di sini bukan "pilih saja yang kelihatan benar", melainkan "tandai sebagai belum terselesaikan dan jangan bangun perbandingan di atasnya".

Apa itu likuiditas pembayaran dan mengapa ambang minimum serta frekuensi pembayaran lebih penting dari kelihatannya?

Likuiditas adalah kecepatan mengubah yang sudah ditambang menjadi uang di dompet Anda. Dihitung dengan sederhana: ambang pembayaran dibagi net BTC/day Anda. Untuk farm ini hitungan jam, untuk satu ASIC rumahan ini bisa berbulan-bulan, dan selama itu saldo berada di operator, sementara aturannya bisa berubah.

Ambang batas dan potongan yang sudah diverifikasi untuk beberapa pool:

Tiga hal yang paling sering merusak perhitungan likuiditas:

Ambang pencatatan dan ambang penarikan bukanlah hal yang sama. Di NiceHash, 0.00001 BTC akan masuk ke saldo, tapi baru bisa ditarik mulai 0.0005 BTC, artinya lima puluh kali lebih besar. Membandingkan angka pertama dengan ambang pool biasa tidak ada gunanya.

Biaya penarikan tetap berubah menjadi persentase yang tergantung jumlahnya. Biaya 0.00003 BTC saat menarik 0.00025 BTC adalah 12% dari jumlahnya, sedangkan saat menarik 0.01 BTC hanya 0.3%. Baris tarif yang sama berarti hal berbeda bagi penambang rumahan dan bagi farm.

Sisa saldo saat pindah. Aturan "sisa di bawah ambang batas terus terkumpul dan tidak hangus" dikonfirmasi resmi untuk F2Pool, ViaBTC, dan Luxor. Untuk pool lainnya kami tidak menemukan pernyataan resmi langsung, artinya saat pindah pool, nasib sisa saldo di saldo lama adalah pertanyaan terbuka, bukan jaminan.

Berapa hari untuk mengumpulkan ambang pembayaran

Dihitung dengan ekspektasi matematis, tanpa varians dari skema tertentu:

\`\`\`

pangsa penambang = hashrate penambang / hashrate jaringan

pendapatan BTC/hari = pangsa penambang × 144 × reward_efektif

hari sampai ambang = ambang batas / pendapatan BTC per hari

\`\`\`

Reward_efektif adalah subsidi ditambah rata-rata biaya blok. Pada cuplikan 09.09.2026, hashrate jaringan 943.73 EH/s, porsi biaya transaksi selama 4320 blok terakhir 0.669%, jadi reward_efektif = 3.125 × 1.00669 = 3.1459 BTC (mempool.space, diakses 09.09.2026). Dibanding 896.89 EH/s pada 29.08.2026, jaringan tumbuh 5.2%, dan tepat sebesar itu pula waktu tunggu bertambah bagi semua yang tidak mengganti perangkatnya.

Ini perhitungan kami dengan formula di atas, bukan data dari pool. Varians riil PPLNS dan TIDES tidak dimasukkan di sini, pada skema-skema tersebut sebarannya di sekitar waktu yang diharapkan cukup terlihat. Kesimpulan praktisnya sederhana: ASIC rumahan 100 TH/s menunggu ambang 0.001 BTC sekitar tiga minggu, dan selama itu uangnya berada di operator. Pada ambang 0.01 BTC, waktu tunggunya melebihi setengah tahun. Anda bisa memasukkan hashrate dan tarif Anda sendiri di kalkulator pembayaran.

Bagaimana menggabungkan komponen-komponen ini menjadi satu penilaian dan dengan bobot berapa?

Dengan jumlah berbobot dari empat penilaian ternormalisasi, di mana keandalan data juga berfungsi sebagai filter kelayakan. Bobot di bawah ini adalah pilihan dan tanggung jawab kami, bukan standar industri: siapa pun yang berpikir berbeda berhak menetapkan bobotnya sendiri dan mendapat urutan pool yang berbeda. Justru karena itu bobotnya dipublikasikan, bukan disembunyikan dalam kode.

Urutan perhitungan:

1. Hitung net BTC/day untuk setiap pool pada hashrate dan harga listrik yang sama. Input berbeda untuk pool berbeda adalah kesalahan perbandingan yang paling sering terjadi.
2. Normalisasi imbal hasil ke skala 0 sampai 100 dalam himpunan yang dibandingkan: pool terbaik dalam himpunan mendapat 100, terburuk mendapat 0. Penilaiannya relatif, dan ini perlu diingat saat membacanya.
3. Nilai risiko operator berdasarkan tanda-tanda yang bisa diamati dari bagian di atas. Skalanya kasar: 0, 25, 50, 75, 100. Presisi di sini semu, dan tidak perlu berpura-pura risikonya terukur hingga ke persentase.
4. Nilai keandalan data dengan skala empat tingkat dan ubah ke poin: tingkat 1 adalah 100, tingkat 2 adalah 66, tingkat 3 adalah 33, tingkat 4 adalah 0.
5. Hitung likuiditas sebagai ambang batas dibagi pendapatan harian Anda, dan normalisasi seperti imbal hasil: makin cepat makin tinggi.
6. Jumlahkan dengan bobotnya dan dapatkan hasil akhir.

Bobot yang kami usulkan:

Satu aturan tegas di atas penjumlahan: pool dengan keandalan data tingkat 3 atau 4 tidak ikut dalam pemeringkatan. Pool itu tetap ditampilkan dalam daftar dengan catatan "data belum terkonfirmasi" dan tanpa skor akhir. Jika tidak, hasilnya jadi absurd, di mana pool mendapat skor tinggi berkat biaya yang terlihat bagus tapi tidak ada yang bisa mengonfirmasinya.

Bagaimana bentuknya pada satu pool:

\`\`\`

Imbal hasil 82 × 0.50 = 41.0

Risiko 75 × 0.20 = 15.0

Keandalan 100 × 0.20 = 20.0

Likuiditas 60 × 0.10 = 6.0

Hasil akhir 82.0

\`\`\`

Mengapa kami tidak mempublikasikan tabel skor akhir untuk semua pool

Karena tabel semacam itu, yang cocok untuk semua pembaca, tidak pernah ada, dan mempublikasikannya justru menciptakan kesan objektivitas yang salah. Alasannya konkret, bukan alasan umum.

Pertama: tiga dari empat komponen bergantung pada input yang berbeda-beda untuk setiap orang. Imbal hasil dihitung dengan hashrate dan harga kilowatt Anda sendiri, likuiditas dihitung dengan waktu pengumpulan ambang batas Anda sendiri. ASIC rumahan 100 TH/s menunggu ambang 0.001 BTC sekitar tiga minggu, farm 1 PH/s sekitar dua hari. Ambang yang sama memberi penilaian berbeda bagi pembaca berbeda, dan tidak ada cara merata-ratakannya.

Kedua: separuh pool yang dibandingkan tidak lolos filter kelayakan. Di AntPool, Binance Pool, Foundry USA, dan Luxor, tarif biaya secara resmi tidak dipublikasikan, dan menurut aturan kami sendiri, pool-pool itu tetap tanpa skor akhir. Tabel dengan empat dari sepuluh baris kosong bukanlah peringkat.

Ketiga: bobot adalah pilihan, bukan besaran yang diukur. Angka 50/20/20/10 milik kami mencerminkan pandangan kami tentang apa yang penting, dan susunan lain akan menghasilkan urutan lain. Skor gabungan sebuah pool selalu merupakan keputusan penulis, bukan sifat dari pool itu sendiri.

Cara menyesuaikan bobot sesuai kebutuhan Anda. Jika Anda punya satu atau dua mesin dan ambang batasnya terkumpul dalam hitungan minggu, naikkan bobot likuiditas dan turunkan bobot imbal hasil: setengah persen biaya pada volume seperti itu nilainya lebih kecil daripada satu bulan menunggu. Jika saldo Anda selalu menyimpan jumlah yang cukup besar, naikkan bobot risiko operator. Jika Anda sama sekali tidak mau mengandalkan angka yang belum terkonfirmasi, jadikan keandalan data bukan sebagai bobot, melainkan filter tegas: pool tingkat 3 dan 4 langsung tersingkir dari perbandingan.

Dalam kasus apa penilaian komposit menipu dan apa yang harus diperiksa sendiri?

Penilaian ini menipu dalam tiga situasi tipikal: saat perataan menyembunyikan kegagalan pada satu komponen, saat himpunan pool yang dibandingkan disusun sedemikian sehingga normalisasi mendistorsi gambaran, dan saat angka di dalam komponen berasal dari tanggal yang berbeda-beda. Skor komposit adalah rangkuman yang praktis, bukan vonis, dan keputusan diambil setelah memeriksa sumber aslinya.

Di mana tepatnya letak kegagalannya:

• Perataan menyembunyikan nol. Pool bisa mendapat skor akhir yang lumayan meski keandalan datanya nol, jika imbal hasilnya di atas kertas paling bagus. Justru dari sinilah aturan filter kelayakan di bagian sebelumnya muncul.
• Normalisasi bergantung pada himpunan. Pool yang sama, dalam kelompok lima pool yang mahal, akan mendapat 100 untuk imbal hasil, tapi dalam kelompok lima belas pool hanya mendapat 60. Skornya bisa dibandingkan dalam satu cuplikan, tapi tidak bisa dibandingkan antar cuplikan.
• Tanggalnya tidak sinkron. Biaya diperiksa Agustus, parameter jaringan diambil September, kurs BTC kemarin. Hasilnya terlihat seperti satu angka utuh, padahal disusun dari data tiga hari berbeda.
• Bobot adalah selera. Angka 50/20/20/10 milik kami mencerminkan pandangan kami tentang apa yang penting. Milik Anda bisa berbeda, dan urutan pool akan berubah, dan yang salah bukan aritmetikanya.
• Biaya perpindahan tidak masuk skor. Di ViaBTC, jendela PPLNS didefinisikan sebagai 5 putaran difficulty terakhir, di Ocean skema TIDES dengan jendela 8 difficulty jaringan. Keluar dari pool semacam itu menghapus posisi terkumpul dalam jendela, dan selisih satu poin tidak sebanding dengan itu.
• Pool mengubah ketentuan di tengah periode penilaian. Biaya dan ambang batas bukan konstanta, melainkan nilai saat ini. Pemeriksaan sebulan sekali berarti Anda menggunakan angka usang selama sebulan.

Apa yang harus diperiksa sendiri sebelum mengarahkan hashrate:

1. Buka sendiri halaman biaya resmi pool yang dipilih dan pastikan Anda melihat angka yang sama seperti di perbandingan.
2. Cari ambang pembayaran dan aturan soal sisa di bawah ambang batas. Jika aturannya tidak ada secara terbuka, anggap saja sisa saldo hilang saat Anda pindah.
3. Baca bagian ketentuan layanan soal reward yang belum dibayarkan dan batas waktunya.
4. Periksa bahwa skema pembayaran di akun Anda sama dengan yang ada di perbandingan. Di sejumlah pool, skema dipilih di pengaturan dan defaultnya bukan yang termurah.
5. Hitung ulang imbal hasil dengan harga listrik Anda sendiri, bukan rata-rata pasar.

Bagaimana menerapkan metodologi ini secara praktis saat memilih pool?

Sebagai filter, bukan sebagai peringkat. Pertama Anda singkirkan pool dengan data yang belum terkonfirmasi, lalu hitung imbal hasil dengan input Anda sendiri, lalu lihat likuiditas untuk hashrate Anda, dan baru di akhir Anda bandingkan skor akhir dari dua atau tiga kandidat yang tersisa. Seluruh proses ini memakan waktu satu malam dan menghemat berbulan-bulan dari pool yang tidak tepat.

Urutan tindakannya:

1. Kumpulkan daftar kandidat. Cuplikan siap pakai dengan biaya, skema, dan ambang batas ada di kartu pool, dan di sana juga terlihat angka mana yang terkonfirmasi resmi dan mana yang tidak.
2. Singkirkan semua pool dengan keandalan data di tingkat 3 atau 4. Ini bukan berarti pool itu buruk, artinya tidak ada yang bisa dibandingkan.
3. Hitung net BTC/day di kalkulator dengan hashrate dan harga kilowatt Anda sendiri. Bukan rata-rata, bukan "yang tipikal untuk wilayah".
4. Bagi ambang pembayaran setiap kandidat dengan pendapatan harian yang Anda dapatkan. Anda akan mendapat waktu sampai pembayaran pertama dalam hari. Jika lebih dari sebulan, likuiditas menjadi faktor utama Anda, bukan biaya.
5. Baca ketentuan dua finalis soal sisa saldo dan reward yang belum dibayarkan.
6. Tentukan skor dan bobot sesuai kebutuhan Anda sendiri. Jika dua pool berbeda kurang dari 5 poin, selisihnya masih dalam margin kesalahan data asli, dan sebaiknya pilih berdasarkan yang tidak terukur: bahasa dukungan, kecepatan respons, ada tidaknya halaman status.
7. Catat tanggal pemeriksaan dan kembali lagi setelah satu kuartal. Biaya dan ambang batas berubah, dan keputusan yang diambil berdasarkan data tahun lalu tidak lebih baik dari keputusan berdasarkan rumor.

Kasus khusus di mana metodologi ini tidak diperlukan: jika Anda serius mempertimbangkan solo mining, komponennya tetap sama, tapi bobotnya sangat berbeda, karena varians berhenti menjadi parameter dan berubah menjadi cerita utama. Tentang ini ada perbandingan solo dan pool mining.

Ringkasan

Perbandingan berdasarkan satu biaya hanya berlaku pada pasar biaya transaksi yang tenang dan hanya untuk penambang yang tidak peduli soal waktu pembayaran. Begitu tarif yang tidak terungkap, ambang batas 0.001 BTC, dan aturan soal sisa yang belum dibayar masuk ke dalam gambaran, satu angka berhenti menggambarkan realitas.

Empat komponen dibanding satu tidak membuat penilaian jadi presisi. Yang mereka lakukan adalah membuatnya jujur: terlihat dari apa penilaian itu disusun, bobot apa diberikan pada apa, dan di mana datanya memang tidak ada. Skor pool yang biayanya tidak dipublikasikan bukanlah skor rendah, melainkan ketiadaan skor, dan mengakui ini lebih berguna daripada memasukkan angka dari agregator ke dalam formula.