---
title: "Penyesuaian kesulitan Bitcoin: target, retarget, dan batas"
description: "Bitcoin menghitung ulang ambang proof of work setiap 2.016 blok untuk mengarahkan interval blok rata-rata jangka panjang menuju sepuluh menit. Target, encoding ringkas, jendela timestamp, batas, aturan jaringan, dan hasil probabilistik harus dianalisis secara terpisah."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Penyesuaian kesulitan Bitcoin: target, retarget, dan batas
> Hanya untuk tujuan edukasi; bukan merupakan nasihat investasi atau rekomendasi investasi. Investasi dapat mengakibatkan kerugian.
## Jawaban langsung
Penyesuaian kesulitan Bitcoin adalah aturan konsensus deterministik yang secara berkala mengubah hash proof of work terbesar yang dapat diterima, disebut `target`, untuk mengarahkan interval blok rata-rata jangka panjang ke sepuluh menit ketika hashrate aktif berubah. Di mainnet, target biasanya tetap selama 2.016 blok lalu dihitung ulang untuk periode berikutnya. Setiap node validasi memperoleh target wajib yang sama dari header sebelumnya; miner tidak memberikan suara dan penjelajah blok tidak menetapkannya.
Proof of work suatu header hanya valid bila hash-nya, ditafsirkan sebagai bilangan bulat, kurang dari atau sama dengan target yang dienkode dalam bidang `nBits` 32-bit. Target yang lebih kecil menerima lebih sedikit hash sehingga membutuhkan lebih banyak percobaan secara ekspektasi. Secara konvensi, kesulitan adalah angka relatif yang berbanding terbalik dengan target:
`D = T₁ / T`
Di sini `T` adalah target saat ini dan `T₁` target acuan untuk kesulitan 1. Target dan kesulitan bergerak berlawanan arah. Keduanya bukan pengukuran langsung jumlah mesin, energi, identitas miner, atau hashrate teramati.
Sepuluh menit adalah nilai harapan, bukan jadwal. Percobaan hash dan kedatangan blok bersifat acak: dua blok dapat terpaut beberapa detik atau tidak ada blok selama satu jam meski target dan hashrate stabil. Retarget adalah umpan balik tertunda sepanjang satu periode; ia mengurangi penyimpangan frekuensi yang menetap, tetapi tidak menghapus varians jangka pendek atau langsung menanggapi guncangan hashrate.
Penyesuaian memengaruhi irama waktu peristiwa berbasis ketinggian, termasuk pengurangan subsidi, tetapi tidak menentukan nilai subsidi, interval 210.000 blok, atau aturan suplai akhir. Ia juga tidak sendirian memilih rantai kanonis. Aturan fork choice Bitcoin membandingkan chainwork kumulatif setelah memvalidasi header dan blok; kesulitan satu blok bukan kerja kumulatif.
## Cara menganalisis retarget
1. **Tetapkan jaringan dan aturan.** Mainnet, testnet lama, Testnet4, signet, dan regtest tidak memiliki semua pengecualian yang sama. Catat rantai, aturan perangkat lunak, ketinggian kandidat, serta apakah retarget atau blok khusus kesulitan minimum diaktifkan.
2. **Dekode target yang diklaim.** Uraikan `nBits` ringkas pada header kandidat menjadi target `T`. Tolak target negatif, nol, overflow, atau di atas `powLimit`, lalu wajibkan hash header memenuhi `≤ T`.
3. **Temukan batas periode.** Di mainnet, target baru diperlukan saat ketinggian kandidat habis dibagi 2.016. Pada ketinggian lain, `nBits` blok sebelumnya harus berlanjut tanpa perubahan.
4. **Pilih jendela timestamp.** Pada batas mainnet, Bitcoin Core mengurangi timestamp blok pertama dalam periode 2.016 blok sebelumnya dari timestamp blok terakhir. Kedua ujung memuat 2.016 blok tetapi hanya 2.015 interval antarblok. Rentang nominal tetap `2,016 × 600 = 1,209,600` detik.
5. **Batasi waktu yang berlalu.** Tetapkan `t = clamp(t_actual, 302,400, 4,838,400)` detik, yakni seperempat hingga empat kali 14 hari nominal. Timestamp header adalah bidang konsensus yang diberikan miner dan tunduk pada batas validitas lain, bukan waktu penerimaan node yang tepat.
6. **Hitung dan enkode target baru.** Menurut aturan mainnet saat ini, hitung dengan bilangan bulat `T_new = min(powLimit, T_old × t / 1,209,600)`, lalu enkode hasil secara ringkas ke `nBits`. Pembagian bilangan bulat dan pembulatan format ringkas dapat sedikit berbeda dari rasio desimal ideal.
7. **Tafsirkan secara probabilistik.** Secara pendekatan, `D_new / D_old = T_old / T_new`. Bandingkan retarget dengan distribusi waktu blok dan hashrate yang jelas diberi label estimasi; pisahkan dari kesimpulan tentang pendapatan, chainwork, konsentrasi, dan risiko konfirmasi.
Rumus mainnet memakai target blok terakhir sebagai `T_old`. Testnet4 sengaja berbeda: BIP 94 mengizinkan blok khusus kesulitan minimum setelah timestamp yang cukup terlambat, melarang pengecualian pada blok pertama periode, dan mendasarkan retarget pada kesulitan nyata blok pertama agar pengecualian sementara tidak mencemari periode berikutnya. Regtest biasanya menonaktifkan retarget. Deskripsi aturan tanpa menyebut jaringan tidak lengkap.
## Contoh perhitungan
### 1. Periode nominal tanpa perubahan
Misalkan `T_old = 10` dalam unit target sembarang dan rentang terukur tepat `1,209,600` detik. Batas tidak mengubah apa pun:
`T_new = 10 × 1,209,600 / 1,209,600 = 10`
Rasio kesulitan adalah `10 / 10 = 1`, jadi kesulitan ideal tidak berubah. Ini bukan berarti tiap blok membutuhkan sepuluh menit; interval acak yang cepat dan lambat dapat saling mengimbangi.
### 2. Periode cepat 12 hari
Misalkan timestamp ujung terpaut 12 hari. Karena berada dalam batas, rasio target adalah `12 / 14 = 6/7`. Target baru sekitar 85,7143% dari target lama, sedangkan:
`D_new / D_old ≈ 14 / 12 = 1.166667`
Kesulitan ideal naik sekitar 16,67%, bukan 14,29%. Persentase penurunan target dan kenaikan kesulitan berbeda karena keduanya saling berkebalikan.
### 3. Batas empat kali
Jika timestamp ujung hanya terpaut 1,75 hari, perhitungan memakai minimum 3,5 hari. Target dapat turun hingga kira-kira seperempat nilai lama, sehingga kesulitan dapat naik hingga kira-kira empat kali dalam satu retarget mainnet.
Jika timestamp mencakup 70 hari, perhitungan memakai maksimum 56 hari. Target dapat naik kira-kira empat kali dan kesulitan turun ke seperempat, kecuali `powLimit` lebih dahulu membatasi target. “Batas empat kali” harus menyebut apakah maksudnya target atau kesulitan serta arahnya.
### 4. Guncangan hashrate di tengah periode
Gunakan ekspektasi sederhana: 1.008 blok pertama ditambang pada laju yang sesuai dengan interval sepuluh menit dan memakan sekitar tujuh hari. Lalu 30% hashrate hilang saat target tetap. Sisa 70% memberi interval harapan `10 / 0.70 ≈ 14.286` menit; 1.008 blok terakhir memakan sekitar sepuluh hari dan seluruh periode sekitar 17 hari.
Dengan mengabaikan efek ujung, keacakan, dan pembulatan ringkas, pengali target adalah `17/14 ≈ 1.214286`; pengali kesulitan `14/17 ≈ 0.823529`, penurunan sekitar 17,65%. Penurunan tidak mencapai 30% penuh karena guncangan hanya memengaruhi setengah periode. Jika hashrate tetap 70%, setelah penyesuaian parsial ini blok masih diharapkan lebih lambat dari sepuluh menit dan periode berikutnya memberi umpan balik lanjutan.
## Risiko dan kegagalan peninjauan
### Kesalahan aturan dan aritmetika
- Menyebut kesulitan sebagai ambang itu sendiri alih-alih membedakan target dari ukuran relatif terbaliknya.
- Membalik rumus sehingga periode cepat menaikkan target atau periode lambat menaikkan kesulitan.
- Menganggap 2.016 blok sebagai 2.016 interval timestamp terukur; perhitungan mainnet saat ini mencakup 2.015 interval.
- Melupakan batas 3,5 dan 56 hari, `powLimit`, pembagian bulat, atau pembulatan `nBits` ringkas.
- Menerapkan pernyataan mainnet ke Testnet4, testnet lama, signet, regtest, atau rantai proof of work lain.
- Menganggap prakiraan penjelajah sebagai input konsensus, bukan estimasi sebelum blok batas ada.
- Menggunakan waktu penerimaan lokal, bukan timestamp header yang digunakan perhitungan konsensus.
- Mencampuradukkan kesulitan blok saat ini, kerja per blok, chainwork kumulatif, atau hasil fork choice.
### Pengukuran dan inferensi
- Menganggap hashrate estimasi sebagai inventaris langsung mesin aktif, bukan inferensi dari kerja dan kedatangan acak.
- Mengekstrapolasi retarget dari bagian kecil periode ketika varians waktu blok biasa dapat mendominasi.
- Membaca kenaikan kesulitan sebagai bukti kenaikan harga, pendapatan miner, energi, atau desentralisasi.
- Membaca penurunan sebagai bukti kegagalan jaringan tanpa memeriksa kerja absolut, konsentrasi, dan durasi.
- Membandingkan angka kesulitan antar-rantai tanpa menormalkan fungsi hash, target acuan, dan aturan penyesuaian.
- Menggambarkan sepuluh menit sebagai tenggat, jaminan layanan, atau waktu konfirmasi tetap.
- Menyimpulkan profitabilitas tanpa imbalan blok, biaya, uptime, syarat pool, lindung nilai, listrik, pembiayaan, dan efisiensi.
### Keamanan dan operasi
- Menganggap retarget sebagai perlindungan langsung terhadap arus masuk atau keluar hashrate mendadak dalam periode berjalan.
- Menganggap kesulitan lebih rendah menambah kapasitas blok atau langsung membersihkan antrean transaksi.
- Memilih kebijakan konfirmasi dari kesulitan saja sambil mengabaikan kerja kumulatif, kemampuan reorganisasi, dan nilai.
- Mengabaikan insentif manipulasi timestamp dan mitigasi khusus protokol saat menilai mekanisme penyesuaian.
- Mengubah aritmetika konsensus, indeks batas, atau encoding ringkas tanpa vektor lintas implementasi dan rencana aktivasi.
## Kesalahpahaman umum
- **Setiap blok Bitcoin membutuhkan sepuluh menit.** Sepuluh menit adalah rata-rata target dengan hashrate yang sesuai; setiap kedatangan tetap acak.
- **Miner memilih kesulitan berikutnya lewat pemungutan suara.** Node validasi menghitung `nBits` yang diizinkan secara mandiri; blok dengan nilai lain tidak valid.
- **Target 20% lebih kecil berarti kesulitan 20% lebih tinggi.** Hubungannya terbalik: pengali target 0,8 berarti pengali kesulitan 1/0.8 = 1.25, atau 25% lebih tinggi.
- **Retarget mengukur hashrate secara langsung.** Ia menanggapi produksi blok bertimestamp; setiap angka hashrate adalah estimasi dengan asumsi sampel dan waktu.
- **Kesulitan adalah kebijakan moneter Bitcoin.** Retarget membantu menstabilkan irama waktu penerbitan berbasis ketinggian; aturan terpisah menetapkan nilai subsidi dan pengurangannya.
## Topik terkait
- [Waktu blok](/id/crypto/block-time/)
- [Aturan fork choice](/id/crypto/fork-choice-rule/)
- [Hashrate](/id/crypto/hashrate/)
- [Penambangan](/id/crypto/mining/)
- [Proof of Work](/id/crypto/proof-of-work/)
## Sumber
- [Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf) - Bitcoin.org (diakses: 2026-08-19)
- [Bitcoin Core: Proof-of-Work Calculations](https://github.com/bitcoin/bitcoin/blob/master/src/pow.cpp) - Bitcoin Core (diakses: 2026-08-19)
- [Bitcoin Core: Network Consensus Parameters](https://github.com/bitcoin/bitcoin/blob/master/src/kernel/chainparams.cpp) - Bitcoin Core (diakses: 2026-08-19)
- [Bitcoin Core: Consensus Parameter Definitions](https://github.com/bitcoin/bitcoin/blob/master/src/consensus/params.h) - Bitcoin Core (diakses: 2026-08-19)
- [Bitcoin Developer Guide: Block Chain](https://developer.bitcoin.org/devguide/block_chain.html) - Bitcoin Project (diakses: 2026-08-19)
- [Bitcoin Developer Reference: Block Headers](https://developer.bitcoin.org/reference/block_chain.html) - Bitcoin Project (diakses: 2026-08-19)
- [BIP 94: Testnet 4](https://bips.dev/94/) - Bitcoin Improvement Proposals (diakses: 2026-08-19)
- [Bitcoin Core RPC: getblockheader](https://developer.bitcoin.org/reference/rpc/getblockheader.html) - Bitcoin Project (diakses: 2026-08-19)
Source: https://wiki.fcontext.com/id/crypto/difficulty-adjustment/index.mdx