비트코인 거래 weight는 `base size×3+total size`이고 vsize는 `ceil(weight÷4)`입니다. total size는 witness를 포함한 직렬화 크기, base size는 witness를 뺀 크기입니다. witness 바이트는 weight에 1단위, base 영역 바이트는 결과적으로 4단위가 반영되므로 실제 바이트 수와 수수료 계산용 vsize가 달라질 수 있습니다.
네 숫자는 같은 거래를 서로 다른 관점에서 잽니다
total size는 네트워크에 직렬화한 거래에서 witness를 포함한 전체 바이트 수입니다. base size는 witness 직렬화를 제거한 전통 형식의 크기입니다. 비-SegWit 거래는 witness가 없으므로 두 값이 같지만 SegWit 입력이 있으면 total size가 더 큽니다.
BIP 141은 거래 weight를 `base size×3+total size`로 정의합니다. total size 안에도 base 부분이 한 번 들어 있으므로 base 바이트는 합계 4 WU, witness 쪽 추가 바이트는 1 WU로 반영됩니다. 이는 서명이 중요하지 않다는 뜻이 아니라 블록 자원 계산에서 witness에 다른 가중치를 적용하는 규칙입니다.
실제 바이트는 전송량을, vsize는 weight를 수수료율과 비교하기 쉬운 단위로 바꾼 값을 보여 줍니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 네 숫자는 같은 거래를 서로 다른 관점에서 잽니다
total size는 네트워크에 직렬화한 거래에서 witness를 포함한 전체 바이트 수입니다.
- 공식에 숫자를 넣어 두 번 검산합니다
가정한 거래의 base size가 120 bytes, total size가 230 bytes라면 weight는 `120×3+230=590 WU`입니다.
- witness 할인은 주소 라벨만으로 고정되지 않습니다
P2WPKH 입력, P2WSH 멀티시그, Taproot 지출은 witness 구성과 길이가 서로 다릅니다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
공식에 숫자를 넣어 두 번 검산합니다
가정한 거래의 base size가 120 bytes, total size가 230 bytes라면 weight는 `120×3+230=590 WU`입니다. vsize는 `ceil(590÷4)=148 vB`입니다. 590을 4로 나누면 147.5이므로 내림하지 않고 올립니다.
수수료율을 6 sat/vB로 정했다면 총수수료 목표는 `148×6=888 sat`입니다. 230 total bytes에 6을 곱한 1,380 sat는 vB 단가를 실제 직렬화 byte에 잘못 적용한 값입니다. 지갑 화면이 WU만 준다면 먼저 4로 나눠 올림하고 단가를 곱합니다.
| 항목 | SegWit 가정 | 비-SegWit 가정 |
|---|---|---|
| base size | 120 bytes | 200 bytes |
| total size | 230 bytes | 200 bytes |
| weight | 590 WU | 800 WU |
| vsize | 148 vB | 200 vB |
| 6 sat/vB 수수료 | 888 sat | 1,200 sat |
witness 할인은 주소 라벨만으로 고정되지 않습니다
P2WPKH 입력, P2WSH 멀티시그, Taproot 지출은 witness 구성과 길이가 서로 다릅니다. 같은 주소 형식도 서명 개수, 공개되는 스크립트와 제어 경로에 따라 weight가 달라질 수 있습니다. 출력은 아직 지출 서명이 없으므로 입력과 다른 크기 특성을 가집니다.
따라서 ‘SegWit이면 무조건 몇 바이트’라는 표를 모든 거래에 적용하지 마세요. 입력 종류별 추정은 비교에 쓸 수 있지만 최종 PSBT를 서명한 뒤 디코딩한 weight와 vsize가 가장 직접적인 값입니다. 하드웨어 지갑을 쓸 때도 연결 앱의 최종 fee와 vsize를 함께 기록합니다.
- 원시 거래가 witness 직렬화를 포함하는지 확인합니다.
- base size와 total size를 서로 바꾸지 않습니다.
- weight 공식을 먼저 계산한 뒤 4로 나눠 올립니다.
- sat/vB는 vsize에, sat/kw는 weight 기준 단위에 맞춰 환산합니다.
- 최종 서명 후 예상치와 실제 값을 다시 대조합니다.
txid와 wtxid 차이도 같은 분리에서 나옵니다
BIP 141은 전통 직렬화의 이중 SHA-256을 txid로 유지하고 witness까지 포함한 새 직렬화의 이중 SHA-256을 wtxid로 정의합니다. witness가 없는 입력만 있으면 두 식별자가 같지만 witness가 있으면 달라질 수 있습니다. 이 구분은 weight 계산의 base·total 경계와 같은 데이터 분리를 사용합니다.
탐색기에서 txid만 보인다고 witness가 없다고 단정할 수는 없습니다. 서비스 UI가 wtxid를 표시하지 않을 수 있기 때문입니다. 거래 디코더에서 `weight`, `vsize`, witness 스택을 확인해야 합니다. 식별자 차이를 수수료 할인액으로 직접 환산하는 것도 올바르지 않습니다.
반올림과 단위 변환에서 흔히 틀립니다
weight가 592 WU면 정확히 148 vB이고 593 WU면 148.25를 올려 149 vB입니다. 입력마다 vsize를 계산해 먼저 올린 뒤 합치면 거래 전체를 한 번 계산한 값보다 커질 수 있습니다. 프로토콜 정의대로 전체 거래 weight를 구한 다음 마지막에 나누고 올립니다.
1 kvB는 1,000 vB 기준으로 쓰이지만 앱의 표기와 내부 정밀도를 확인해야 합니다. BTC/kvB를 sat/vB로 바꿀 때 BTC를 sat로 환산하고 1,000으로 나눕니다. 단위가 불명확한 수수료 입력란에는 값을 넣지 말고 제품 문서를 먼저 확인하세요.
수수료 단가와 거래 크기를 함께 대조합니다
sat/vB 글은 네트워크 상황에 맞춰 어떤 단가를 선택하고 총수수료를 구하는지에 답합니다. 이 글은 그 곱셈에 들어가는 vsize가 실제 byte와 왜 다르며 원시 거래에서 어떻게 계산되는지에 답합니다. 수수료율이 같아도 weight가 다르면 총수수료가 달라집니다.
비교할 때는 동일 거래의 서명 전·후 값을 섞지 마세요. 입력이 선택되지 않은 견적, PSBT, 완성 거래는 크기가 다를 수 있습니다. 계산 기록에는 거래 단계, base size, total size, weight, vsize와 적용 단가를 한 줄씩 남기면 오류를 재현하기 쉽습니다.
자주 묻는 질문
vsize는 실제 네트워크 전송 바이트인가요?
아닙니다. weight를 4로 나눠 올린 수수료 계산용 크기입니다. 실제 직렬화 크기는 total size입니다.
비-SegWit 거래도 vsize가 있나요?
있습니다. base와 total이 같으므로 weight는 총크기의 네 배, vsize는 총크기와 같습니다.
weight를 4로 나눈 소수는 버리나요?
버리지 않고 다음 정수 vB로 올립니다. 전체 거래 weight에 대해 마지막에 한 번 적용합니다.
