收益與成本
挖礦難度上升時會怎樣：5%、10% 與 20% 情境
把今天每 TH/s 的產出一路複製到整個持有期，是 ASIC 收益模型最常見的偏差之一。即使你的機器算力沒有改變，網路難度上升後，同一算力可分得的預期 BTC 仍會下降。5%、10% 與 20% 情境的用途不是預言下一次調整，而是測試設備、電價與現金儲備能承受多大的逆風。 資料核對日期：2026-0
把今天每 TH/s 的產出一路複製到整個持有期，是 ASIC 收益模型最常見的偏差之一。即使你的機器算力沒有改變，網路難度上升後，同一算力可分得的預期 BTC 仍會下降。5%、10% 與 20% 情境的用途不是預言下一次調整，而是測試設備、電價與現金儲備能承受多大的逆風。
資料核對日期：2026-08-09（UTC+8）。本文不保證收益；決策前應重新取得 difficulty、礦池結算、電表與設備遙測資料。
目錄
- 難度改變的是什麼
- 先固定可信的基準期
- 三個難度情境怎麼讀
- 建立價格×難度矩陣
- 先寫好停止規則
- 每次調整後如何更新
- 不要把 difficulty、network hashrate 與 hashprice 重複計算
- 常見問題
難度改變的是什麼
Bitcoin 協議以 difficulty 調整找到區塊的門檻。其他條件不變時，固定算力的預期產出可用簡化式表示：
新每日 BTC＝基準每日 BTC × 基準難度 ÷ 新難度
若只輸入升幅，可寫成 新每日 BTC＝基準每日 BTC ÷（1＋升幅）。因此難度增加 10% 時，產出係數是 1/1.10，而不是直接把收入乘以 90%。這仍是估算；交易費、礦池 luck、結算方法、拒絕 share 與停機都會令實際結果偏離。
先固定可信的基準期
不要拿單日最高產出當基準。應取至少一個完整難度週期的入帳 BTC、平均有效算力、拒絕 share、上線小時與牆上用電量，並記錄起訖日期。礦池若同時顯示法幣估值，仍要保留 BTC 原始數量，才能把「難度影響產出」和「價格影響估值」拆開。
輸入表至少包含：基準每日 BTC、難度 +5%/+10%/+20%、BTC/KZT 三種價格、電價、適用挖礦費、礦池費、有效運轉率、散熱與維修準備金。每個情境必須使用同一組假設，不能把樂觀價格和保守成本任意拼在一起。
三個難度情境怎麼讀
5% 情境適合檢查邊際是否過薄。若小幅變動就令營運現金轉負，設備對電價或 uptime 過度敏感。10% 情境可作採購基本門檻：除了月淨現金，也要檢查維修後儲備與債務付款。20% 是壓力測試，不代表一定發生；它用來揭示設備提早失去競爭力時的退出風險。
每一列先調整 BTC 產出，再乘可實際成交的 BTC/KZT 價格，之後扣礦池費、電力、散熱、hosting、維修準備金與出售成本。折舊應放在管理損益欄，不要誤當成當月現金支出。
建立價格×難度矩陣
最實用的是 3×3 表：價格 −20%、不變、+20%，配對難度 +5%、+10%、+20%。每格顯示月淨現金與每 kWh 邊際收入。這會直接暴露「只要幣價上升就沒事」的隱藏假設。
再用 98%、95%、90% uptime 做第二輪。高溫、網路故障或維修會放大難度壓力；難度 +10% 且 uptime 降至 90% 的組合，才是採購決策應看的一類聯合風險。
先寫好停止規則
第一條是營運線：礦池後收入低於可避免的電力與適用費用時，評估暫停。第二條是維修線：修復成本高於修後可產生的保守現金流時，不再追加零件。第三條是資本線：壓力情境的回本期超過預定有效使用期時，停止採購或重談價格。
門檻要同時寫成 KZT、kWh 與 uptime 數字，而不是模糊的「行情不好」。如此難度更新時，值班人員可以依既定規則執行。
每次調整後如何更新
保留每個週期的模型版本，不要覆蓋舊表。把礦池實際入帳與模型比較，將差異分類為費率、luck、拒絕 share、停機或交易費。若連續三個週期出現同方向偏差，才修正基準係數。
一份可簽核的採購摘要至少要列出目前值、5/10/20% 結果、最差月份所需流動性及明確 stop-rule。如此情境分析才是經營工具，而不是裝飾性的預測圖。
常見問題
難度增加 10%，收益就少 10% 嗎？
不完全是。其他條件固定時，產出約乘以 1/1.10；實際礦池收入還受結算方法、luck 與費用影響。
幣價要放進同一張表嗎？
要，但應作為另一個維度。難度改變 BTC 產出，價格改變產出的法幣價值。
基準期要多長？
至少涵蓋一個完整難度週期或相近的穩定營運區間，不應使用單一幸運日。
不要把 difficulty、network hashrate 與 hashprice 重複計算
三者相關但不是同一欄。Difficulty 是協議中的目標尺度；network hashrate 是全網運算力估計；hashprice 則把特定算力的收入濃縮成一個市場指標。若已用 hashprice 作收入基準，又另外扣一次 difficulty 情境，可能把同一風險計算兩次。
模型要標明每項來源：difficulty 作用於基準 BTC/TH/s 產出，BTC/KZT 是獨立價格軸，礦池費、reject 與 uptime 再作營運調整。短期 network hashrate 估計不能取代自己的 accepted hashrate、實際 payout 與牆上電表。
單次上升與連續調整是兩條路徑
「累計 +20%」可能一次發生，也可能經多個週期逐步累積。終點相近，但期間已產 BTC、cash timing 與可採取的動作不同。連續模型應逐期保存：
本期 BTC＝初始 BTC×初始 difficulty÷本期 difficulty×有效 uptime×（1－礦池損耗）
每期 BTC 再依實際出售或帶日期的管理匯率換算。不能用最後一天幣價重估整段歷史現金流。逐期模型也能設定第一階段降功率、第二階段停止低效率 cohort、第三階段蒐集出售報價，而不是只看到期末一個大數字。
按 cohort 找到真正的停止線
全場平均 J/TH 會讓新機掩蓋舊機。每個型號、採購批次與功率模式要分別記 accepted TH/s、牆上 kW、all-in kWh、礦池損耗、維修準備及可避免 hosting 費。
每 kWh 邊際＝礦池後收入÷用電量－可避免的每 kWh 成本。結果為負時，可評估只停止該 cohort；但仍要計算最低 hosting 費、重啟成本和合約限制。Underclock 是否改善 J/TH 必須用電表和 accepted hashrate 驗證，不能只看控制台設定。
一個標明假設的計算例
以下不是市場數據。假設某 cohort 每月基準 0.010 BTC、有效 uptime 96%、礦池與 reject 合計損耗 3%，調整後為 0.010×0.96×0.97＝0.009312 BTC。Difficulty 單次上升 10% 後，其他條件固定，約為 0.009312÷1.10＝0.008465 BTC。
之後才乘上自行輸入、帶日期的 BTC/KZT，再扣真實電力、挖礦費、散熱和維修。若不同 cohort 的可避免成本不同，就可能一批仍為正、一批已為負，不能整場套同一決定。
把 cash runway 放進每個週期
每期列出期初 KZT、可出售 BTC、payout 日期、電力與 hosting 到期日、工資、維修準備及期末現金。尚未付款到錢包或尚未出售的 BTC 不是現金。另測 payout threshold、審查或銀行結算延遲時，是否仍能按時繳費。
Difficulty 緩慢上升時，現金儲備可能早於帳面回本期耗盡。出售計畫應分成支付已知義務、補回安全儲備及可長期保留三部分，而不是依賴價格方向猜測。
每期做 variance attribution
比較模型 BTC 與實際礦池入帳後，把差異拆為 accepted hashrate、uptime、reject/stale、結算方法或 luck、交易費等 reward component。不要把所有落差都歸因於 difficulty。只有原因可驗證時才修改基準係數，並保留舊版本、輸入快照、修改人與時間。
Difficulty 更新後的核准流程
先確認新 difficulty、accepted hashrate、kWh、礦池費、payout 狀態與 all-in 電價完整；缺一項就標成資料不足。再按 cohort 套用預先核准的營運、維修與資本 stop-rule。安全停機不等待財務計算；純經濟停機則要先核對合約、重啟與未付 payout。
每個決策保留帶時區的 RFC3339 時間、模型版本、證據與核准者。若採購只在幣價高、difficulty 低、uptime 完美和殘值高時成立，應降低設備價格、換更有效率機型或分階段擴充，而不是把該組合稱作基準情境。