Bitcoin package는 dependency order를 가진 미확인 transactions 묶음입니다. 저수수료 parent가 개별 mempool minimum을 넘지 못해도 그 output을 쓰는 child가 충분한 fee를 더하면 parent+child aggregate feerate가 policy를 통과할 수 있어 함께 평가합니다. 다만 Bitcoin Core의 package acceptance와 P2P package relay 지원 범위는 버전별로 발전 중이며 submitpackage 성공이 모든 peer로 전파됐거나 mining을 보장하는 것은 아닙니다.
자식은 확인되지 않은 부모 출력에 의존합니다
Parent가 만든 UTXO를 child input이 쓰면 child만으로는 유효성을 검증할 수 없습니다. Node가 parent를 mempool에 갖고 있지 않다면 missing input으로 거절할 수 있습니다. Package는 부모를 먼저 정렬해 context를 제공하고 묶음 전체의 정책을 평가할 기회를 줍니다.
Consensus는 block 안에서 parent가 child보다 앞에 있으면 각각 거래를 검증합니다. Package policy는 block consensus의 새 transaction type이 아니라 mempool admission·relay를 위한 node 정책입니다. 한 node가 package를 받아도 다른 version·설정의 peer가 같은 정책을 쓴다고 가정하지 않습니다.
Package relay는 여러 거래를 하나로 합치는 consensus 규칙이 아니라, 의존 거래를 함께 보아 mempool 입구에서 평가하는 정책입니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 자식은 확인되지 않은 부모 출력에 의존합니다
Parent가 만든 UTXO를 child input이 쓰면 child만으로는 유효성을 검증할 수 없습니다.
- CPFP는 aggregate feerate를 높입니다
Child-pays-for-parent에서는 child가 자기 vsize보다 많은 fee를 부담해 parent와 child total fee를 total vsize로 나눈 rate를 높입니다.
- Bitcoin Core 26.0의 제한을 버전과 함께 읽습니다
Core 26.0 release notes는 submitpackage RPC를 추가해 child와 모든 unconfirmed parents를 package로 평가하고 package CPFP를 지원했다고 설명합니다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
CPFP는 aggregate feerate를 높입니다
Child-pays-for-parent에서는 child가 자기 vsize보다 많은 fee를 부담해 parent와 child total fee를 total vsize로 나눈 rate를 높입니다. Miner가 child fee를 얻으려면 parent도 같은 block에 포함해야 하므로 경제적 유인이 연결됩니다. Child가 parent output을 실제로 spend하지 않으면 CPFP 관계가 아닙니다.
예를 들어 parent 200 vB·200 sat와 child 100 vB·2,800 sat라면 묶음은 3,000 sat/300 vB=10 sat/vB입니다. Child 단독 28 sat/vB만 표시하면 miner가 반드시 함께 넣어야 하는 parent 비용을 숨깁니다. Ancestor chain 전체를 계산합니다.
| 층위 | 확인 항목 | 완료 의미 |
|---|---|---|
| Consensus | 각 transaction 유효성 | block에 들어갈 수 있음 |
| Package policy | count·size·topology·feerate | local 평가 통과 |
| Mempool | conflict·ancestor limits | local 저장 |
| P2P relay | peer feature·policy | 다른 node 전달 가능 |
| Mining | template·경쟁 fee | 실제 block 포함 |
Bitcoin Core 26.0의 제한을 버전과 함께 읽습니다
Core 26.0 release notes는 submitpackage RPC를 추가해 child와 모든 unconfirmed parents를 package로 평가하고 package CPFP를 지원했다고 설명합니다. 당시에는 한 child와 그 parents 구조로 제한되고 parent가 다른 parent output을 spend하면 안 되며 package RBF도 지원하지 않았습니다.
같은 문서는 successful submission이 network propagation을 뜻하지 않는다고 경고했습니다. 이후 Core versions에서 1-parent-1-child relay와 TRUC policy 등이 바뀌었으므로 운영 node의 getnetworkinfo version과 해당 release notes·RPC help를 확인합니다. 26.0 제한을 영구 protocol 규칙처럼 쓰지 않습니다.
- Node version과 package feature를 확인합니다.
- Transactions를 dependency order로 정렬합니다.
- 각 tx consensus와 conflict를 검사합니다.
- Total fee·vsize로 aggregate rate를 계산합니다.
- Local 결과와 peer propagation을 별도 관측합니다.
Dust·ancestor·RBF 정책도 함께 작동합니다
높은 child fee가 모든 오류를 덮는 것은 아닙니다. Parent output이 dust policy에 걸리거나 transaction이 non-standard, conflict·ancestor limits를 위반하면 package가 거절될 수 있습니다. Minimum relay feerate 아래인 개별 parent를 어떤 조건에서 허용하는지도 version policy를 따릅니다.
Replacement는 기존 mempool transaction과 conflicts, fee 증가, descendants를 다룹니다. Package RBF와 일반 BIP125 replacement를 같은 지원 상태로 보지 않습니다. testmempoolaccept·submitpackage result의 tx별 error와 package_msg를 모두 보존합니다.
Wallet은 bump 성공을 confirmation과 구분합니다
Wallet이 CPFP child를 만들었다면 spendable parent output, child fee, package rate와 broadcast peers를 표시합니다. Local node accepted만 보고 ‘가속 완료’라고 하지 않고 peer mempools와 eventual block inclusion을 추적합니다. Parent가 이미 confirmed되면 child는 독립 fee 경쟁으로 바뀝니다.
Fee bump 자동화는 최대 총 fee, 재시도 간격, stale estimate, double-spend conflict를 제한합니다. Watch-only wallet과 signer가 parent output ownership을 확인하고 공격자가 dust input을 붙여 잘못된 package를 만들지 않도록 coin selection을 통제합니다.
자주 묻는 질문
Package는 하나의 txid를 갖나요?
아닙니다. 각 transaction은 자체 txid를 가지며 node가 정책 평가를 위해 의존 묶음으로 처리합니다.
submitpackage 성공이면 모든 node가 거래를 받았나요?
아닙니다. Local acceptance와 P2P propagation, miner inclusion은 별도 상태입니다.
높은 child fee면 어떤 parent도 통과하나요?
아닙니다. Consensus·standardness·topology·conflict 같은 다른 정책도 충족해야 합니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
