Bitcoin Core의 fee estimator는 미래 block을 정확히 시뮬레이션하는 예언기가 아니라, node가 관찰한 mempool transactions를 feerate buckets로 나누고 각 bucket이 몇 block 안에 confirm됐는지 통계적으로 추적해 목표 confirmation target에 맞는 rate를 고릅니다. Local node의 uptime·mempool view와 최근 traffic에 의존하므로 새 node, 급격한 fee spike, transaction 정책 변화에서는 estimate가 없거나 실제 대기와 달라질 수 있습니다.
관찰 데이터는 이 node의 mempool에서 시작합니다
거래가 mempool에 들어온 높이, feerate와 block 포함 높이를 관찰하면 몇 blocks 안에 성공했는지 알 수 있습니다. Estimator는 비슷한 feerate를 buckets로 묶고 성공·실패 sample을 decay해 최근 환경에 더 무게를 둡니다. 다른 node가 보지 못한 private transaction이나 miner policy는 반영하지 못합니다.
Node를 막 시작했거나 block 동안 sample이 부족하면 신뢰할 estimate를 반환하지 않을 수 있습니다. Release notes도 좋은 estimate가 항상 가능하지 않다고 설명합니다. API가 null·error를 돌려줄 때 임의의 0 fee로 치환하지 않습니다.
수수료 추정치는 미래 mempool의 정답이 아니라, 이 노드가 본 과거 확인률로 만든 목표별 확률 판단입니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 관찰 데이터는 이 node의 mempool에서 시작합니다
거래가 mempool에 들어온 높이, feerate와 block 포함 높이를 관찰하면 몇 blocks 안에 성공했는지 알 수 있습니다.
- Confirmation target은 숫자 하나의 약속이 아닙니다
estimatesmartfee의 conf_target은 대략 몇 blocks 안에 포함되길 원하는지 나타냅니다.
- Feerate와 총 fee를 분리합니다
Estimator는 보통 BTC/kvB 또는 sat/vB 같은 rate를 반환합니다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
Confirmation target은 숫자 하나의 약속이 아닙니다
estimatesmartfee의 conf_target은 대략 몇 blocks 안에 포함되길 원하는지 나타냅니다. 반환 feerate는 해당 horizon과 mode에서 충분한 성공률을 보인 bucket을 기반으로 합니다. 2 blocks target을 선택해도 다음 두 blocks inclusion을 보장하지 않습니다.
Conservative mode는 더 긴 관찰 horizon과 충분한 history를 사용해 갑작스러운 fee 감소에 덜 민감한 값을 줄 수 있고 economical은 짧은 horizon에 더 반응합니다. 실제 Core version의 RPC help에서 mode와 허용 target 범위를 확인합니다. UI가 ‘빠름·보통’으로 번역해도 block target을 표시합니다.
| 값 | 역할 | 보장 여부 |
|---|---|---|
| Estimated feerate | 과거 확인률 기반 rate | 포함 보장 아님 |
| conf_target | 목표 block 수 | 정확한 시간 아님 |
| mempoolminfee | 현재 node 수용 하한 | miner 포함 보장 아님 |
| minrelaytxfee | relay 정책 하한 | network 전체 동일 아님 |
| fallbackfee | estimate 부재 시 wallet 값 | 시장 관찰치 아님 |
Feerate와 총 fee를 분리합니다
Estimator는 보통 BTC/kvB 또는 sat/vB 같은 rate를 반환합니다. 실제 fee는 signed transaction의 virtual size에 rate를 적용합니다. Input 유형과 개수, change output, witness가 vsize를 바꾸므로 송금 금액만으로 fee를 정할 수 없습니다.
Coin selection 뒤 예상보다 input이 늘면 같은 rate에서도 fee가 커집니다. Wallet은 rate source, estimated vsize, total fee를 함께 보여 주고 excessive fee guard를 둡니다. 단위를 BTC/kB와 sat/vB 사이에서 변환할 때 1000과 1e8 factor를 테스트합니다.
- 사용 Core version과 RPC help를 고정합니다.
- Target blocks와 estimate mode를 기록합니다.
- Returned feerate 단위를 변환 검증합니다.
- 실제 transaction vsize로 total fee를 계산합니다.
- Estimate 부재·spike에 fee bump 경로를 준비합니다.
급격한 mempool 변화는 과거 모델을 앞섭니다
대형 mint, exchange batch, hash rate 변화 뒤 block 간격 증가처럼 새 demand가 생기면 과거 낮은 rate의 성공률이 현재 queue를 설명하지 못합니다. 반대로 일시 spike가 끝나도 conservative estimate가 높게 남을 수 있습니다. Mempool histogram과 recent blocks를 보조로 보되 future miner selection을 확정하지 않습니다.
각 miner는 block template 정책과 private order flow가 다를 수 있습니다. Local mempoolminfee 이상이라는 사실은 광범위 relay나 빠른 confirmation을 보장하지 않습니다. 사용자는 urgency와 RBF·CPFP 가능성을 함께 선택해야 합니다.
예측 오차를 fee bump와 측정으로 다룹니다
Replace-by-fee가 가능한 transaction은 적절한 sequence와 wallet policy를 확인하고 낮은 초기 rate 뒤 필요시 bump할 수 있습니다. Recipient나 service가 unconfirmed txid를 고정 추적한다면 replacement 운영 영향을 고려합니다. CPFP는 spendable child output과 package 정책이 필요합니다.
운영 지표는 estimate와 실제 confirmation blocks, 생성 시 mempool size, bump 횟수를 저장합니다. 평균만 보지 말고 target별 초과 비율을 봅니다. 특정 날의 적중을 근거로 항상 같은 고정 rate를 쓰지 않습니다.
자주 묻는 질문
2-block estimate면 약 20분 안에 확정되나요?
보장이 아닙니다. Block 간격과 future mempool·miner 선택이 변하므로 목표 block 수의 통계 추정입니다.
추정치가 없으면 0 fee로 보내도 되나요?
아닙니다. Wallet fallback·현재 relay 정책과 bump 전략을 확인해야 합니다.
같은 feerate면 모든 거래의 총 fee가 같나요?
아닙니다. Virtual size가 input·output과 script 유형에 따라 달라집니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
