비트코인 패키지(package)는 의존 순서가 정해진 미확인 거래 묶음입니다. 수수료가 낮은 부모 거래가 혼자서는 멤풀 최저 기준을 넘지 못해도, 그 출력을 쓰는 자식 거래가 수수료를 넉넉히 보태면 부모와 자식을 합친 수수료율(feerate)이 정책을 통과할 수 있습니다. 그래서 둘을 함께 평가합니다. 다만 Bitcoin Core의 패키지 수용과 P2P 패키지 중계(relay)가 어디까지 지원되는지는 버전마다 계속 바뀌고 있습니다. submitpackage가 성공했다고 모든 피어에 퍼졌거나 채굴이 보장되는 것도 아닙니다.
자식은 아직 확인되지 않은 부모의 출력에 기댑니다
부모가 만든 UTXO를 자식의 입력이 쓰면, 자식만 놓고는 유효한지 검증할 수 없습니다. 노드 멤풀에 부모가 없다면 입력 누락으로 거절할 수 있습니다. 패키지는 부모를 먼저 세워 맥락을 주고, 묶음 전체를 정책에 비춰 볼 기회를 줍니다.
합의 규칙은 블록 안에서 부모가 자식보다 앞에 있으면 거래를 하나씩 검증합니다. 패키지 정책은 블록 합의에 새로 생긴 거래 유형이 아니라 멤풀에 받아들이고 중계할지를 정하는 노드 정책입니다. 한 노드가 패키지를 받아들였다고 해서, 버전과 설정이 다른 피어도 같은 정책을 쓴다고 가정하지 않습니다.
패키지 중계는 여러 거래를 하나로 합치는 합의 규칙이 아닙니다. 서로 의존하는 거래를 함께 놓고 멤풀 입구에서 평가하는 정책입니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 자식은 아직 확인되지 않은 부모의 출력에 기댑니다
부모가 만든 UTXO를 자식의 입력이 쓰면, 자식만 놓고는 유효한지 검증할 수 없습니다.
- CPFP는 묶음 전체의 수수료율을 끌어올립니다
자식이 부모를 대신 내 주는 방식(Child-pays-for-parent)에서는 자식이 제 크기보다 많은 수수료를 부담합니다.
- Bitcoin Core 26.0의 제한은 버전과 함께 읽습니다
Core 26.0 릴리스 노트는 submitpackage RPC를 추가해, 자식 하나와 그 미확인 부모 전부를 패키지로 평가하고 패키지 CPFP를 지원했다고 설명합니다.
설명을 위한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
CPFP는 묶음 전체의 수수료율을 끌어올립니다
자식이 부모를 대신 내 주는 방식(Child-pays-for-parent)에서는 자식이 제 크기보다 많은 수수료를 부담합니다. 그러면 부모와 자식의 총수수료를 총 가상 크기(vsize)로 나눈 비율이 올라갑니다. 채굴자가 자식의 수수료를 받으려면 부모도 같은 블록에 넣어야 하므로 경제적 동기가 하나로 묶입니다. 자식이 부모의 출력을 실제로 쓰지 않는다면 CPFP 관계가 아닙니다.
예를 들어 부모가 200 vB·200 sat이고 자식이 100 vB·2,800 sat라면 묶음은 3,000 sat/300 vB=10 sat/vB입니다. 자식만의 28 sat/vB를 내세우면, 채굴자가 반드시 함께 넣어야 하는 부모의 비용이 가려집니다. 조상 거래 사슬 전체를 계산합니다.
| 층위 | 확인 항목 | 완료 의미 |
|---|---|---|
| 합의 규칙 | 거래별 유효성 | 블록에 들어갈 수 있음 |
| 패키지 정책 | 개수·크기·구조·수수료율 | 로컬 평가 통과 |
| 멤풀 | 충돌·조상 한도 | 로컬에 저장 |
| P2P 중계 | 피어 기능·정책 | 다른 노드로 전달 가능 |
| 채굴 | 블록 템플릿·수수료 경쟁 | 실제 블록 포함 |
Bitcoin Core 26.0의 제한은 버전과 함께 읽습니다
Core 26.0 릴리스 노트는 submitpackage RPC를 추가해, 자식 하나와 그 미확인 부모 전부를 패키지로 평가하고 패키지 CPFP를 지원했다고 설명합니다. 당시에는 자식 하나와 그 부모들로 이뤄진 구조만 허용됐고, 부모가 다른 부모의 출력을 써서도 안 됐으며, 패키지 RBF도 지원하지 않았습니다.
같은 문서는 제출에 성공했다고 네트워크에 퍼졌다는 뜻은 아니라고 경고했습니다. 이후 Core 버전에서 부모 하나·자식 하나(1-parent-1-child) 중계와 TRUC 정책 등이 바뀌었으니, 운영 노드의 getnetworkinfo 버전과 해당 릴리스 노트·RPC 도움말을 확인합니다. 26.0의 제한을 영구적인 프로토콜 규칙처럼 쓰지 않습니다.
- 노드 버전과 패키지 기능을 확인합니다.
- 거래를 의존 순서대로 정렬합니다.
- 거래마다 합의 규칙 위반과 충돌을 검사합니다.
- 총수수료와 총 가상 크기로 묶음 수수료율을 계산합니다.
- 로컬 결과와 피어 전파를 따로 관측합니다.
더스트·조상 한도·RBF 정책도 함께 작동합니다
자식 수수료가 높다고 모든 오류가 덮이지는 않습니다. 부모 출력이 더스트(dust) 정책에 걸리거나, 거래가 비표준이거나, 충돌·조상 한도를 어기면 패키지는 거절될 수 있습니다. 최소 중계 수수료율에 못 미치는 개별 부모를 어떤 조건에서 받아 줄지도 버전별 정책을 따릅니다.
교체(replacement)는 기존 멤풀 거래와의 충돌, 수수료 인상, 자손 거래를 다룹니다. 패키지 RBF와 일반 BIP125 교체가 같은 수준으로 지원된다고 보지 않습니다. testmempoolaccept·submitpackage 결과에 담긴 거래별 오류와 package_msg를 모두 보존합니다.
지갑은 수수료 올리기 성공과 확인을 구분합니다
지갑이 CPFP 자식 거래를 만들었다면 쓸 수 있는 부모 출력, 자식 수수료, 묶음 수수료율, 전파한 피어를 보여 줘야 합니다. 로컬 노드가 받아들인 것만 보고 ‘가속 완료’라고 하지 말고, 피어 멤풀과 최종 블록 포함 여부를 추적합니다. 부모가 이미 확인됐다면 자식은 혼자 수수료 경쟁을 하게 됩니다.
수수료 올리기를 자동화할 때는 최대 총수수료, 재시도 간격, 낡은 추정치, 이중 지불 충돌에 상한을 둡니다. 조회 전용 지갑과 서명자는 부모 출력의 소유권을 확인하고, 공격자가 더스트 입력을 끼워 엉뚱한 패키지를 만들지 못하게 코인 선택을 통제합니다.
자주 묻는 질문
패키지는 txid 하나로 묶이나요?
아닙니다. 거래마다 자기 txid가 있고, 노드가 정책 평가를 위해 서로 의존하는 묶음으로 처리할 뿐입니다.
submitpackage가 성공하면 모든 노드가 거래를 받았나요?
아닙니다. 로컬 수용, P2P 전파, 채굴자의 블록 포함은 각각 다른 상태입니다.
자식 수수료가 높으면 어떤 부모든 통과하나요?
아닙니다. 합의 규칙·표준성·구조·충돌 같은 다른 정책도 충족해야 합니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
