미확인 거래 B가 거래 A의 출력을 쓰면 A는 부모, B는 자식입니다. B가 다시 C의 입력을 만들면 C의 조상에는 B와 A가 재귀적으로 포함됩니다. Bitcoin Core 31.0 릴리스 노트와 v31.0 태그 문서는 연결된 미확인 거래 집합을 cluster로 정의하고 기본 한도를 64건·101kvB로 설명합니다. 이는 합의 규칙이 아닌 로컬 중계·멤풀 정책이며 설정으로 바꿀 수 있으므로 노드 버전과 설정을 함께 확인해야 합니다.
미확인 출력을 다시 쓰면 거래 그래프가 생깁니다
A가 아직 블록에 포함되지 않았는데 그 출력으로 B를 만들면 A→B 의존 관계가 생깁니다. B 출력으로 C를 만들면 A와 B는 C의 조상이고 B와 C는 A의 자손입니다. Bitcoin Core v31.0의 mempool design 문서는 이 관계를 방향 그래프로 정의합니다.
cluster는 부모·자식 방향을 어느 쪽으로 따라가든 연결되는 거래의 전체 구성 요소입니다. 단순 직선 A→B→C뿐 아니라 한 부모에서 여러 자식이 갈라지거나 여러 부모가 한 자식으로 합쳐지는 경우도 포함합니다. 지갑의 ‘미확인 잔액’ 한 줄만으로 그래프 모양을 알 수는 없습니다.
미확인 거래 하나의 확인 가능성은 그 거래 단독 수수료뿐 아니라 연결된 거래 집합의 구조와 수수료에 영향을 받습니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 미확인 출력을 다시 쓰면 거래 그래프가 생깁니다
A가 아직 블록에 포함되지 않았는데 그 출력으로 B를 만들면 A→B 의존 관계가 생깁니다.
- 정책 수치는 Bitcoin Core 버전에 따라 달라집니다
Bitcoin Core 31.0 릴리스 노트와 v31.
- 멤풀 거부는 블록 합의 무효와 다릅니다
Bitcoin Core 정책 README는 중계 정책이 합의 규칙에 추가되는 로컬 규칙 이며 미확인 거래를 멤풀에 넣기 전에 적용된다고 설명합니다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
정책 수치는 Bitcoin Core 버전에 따라 달라집니다
Bitcoin Core 31.0 릴리스 노트와 v31.0 태그의 mempool design 문서는 기존 ancestor·descendant 건수·크기 제한을 cluster 기본 한도 64 transactions·101 kB virtual size로 바꿨다고 밝힙니다. 이 한도는 명령행 설정으로 바꿀 수 있습니다. 예전 25건 값을 모든 노드의 보편 규칙처럼 인용하지 말고 실제 사용 노드가 30.x인지 31.x인지 확인해야 합니다.
또한 v3 TRUC 거래에는 더 엄격한 별도 topology 규칙이 있습니다. v31.0 태그 소스는 미확인 조상과 자손 집합을 각각 자기 자신 포함 2건으로 제한하고, 미확인 부모를 쓰는 자식의 sigop-adjusted vsize를 1,000으로 제한합니다. 일반 거래 정책과 v3 정책을 같은 표로 합치지 마세요.
| 개념 | 범위 | 확인할 것 |
|---|---|---|
| 부모 | 출력을 직접 제공한 미확인 거래 | 부모 txid와 멤풀 존재 |
| 조상 | 부모를 재귀적으로 거슬러 올라간 집합 | 전체 수와 합산 vsize |
| 자식 | 출력을 직접 소비한 미확인 거래 | 교체·충돌 여부 |
| 자손 | 자식을 재귀적으로 내려간 집합 | 퇴출 시 함께 영향받는 범위 |
| cluster | 양방향 연결 전체 구성 요소 | 노드 버전별 한도와 feerate diagram |
멤풀 거부는 블록 합의 무효와 다릅니다
Bitcoin Core 정책 README는 중계 정책이 합의 규칙에 추가되는 로컬 규칙이며 미확인 거래를 멤풀에 넣기 전에 적용된다고 설명합니다. 블록 안 거래에는 이 정책을 적용하지 않습니다. 한 노드가 cluster 한도 때문에 거래를 받지 않았다고 해서 서명이나 지출 조건이 합의상 무효라는 뜻은 아닙니다.
반대로 ‘언젠가 채굴자가 넣을 수도 있다’는 이유로 지갑 오류를 무시해서도 안 됩니다. 충분한 노드가 거래를 중계하지 않으면 채굴자에게 도달하기 어렵습니다. 사용 중인 노드의 `testmempoolaccept`, `getmempoolentry`, 조상·자손 조회 결과와 정확한 reject reason을 기록하세요.
- 문제 거래와 직접 부모 txid를 목록으로 만듭니다.
- 각 거래가 현재 노드 멤풀에 있는지 확인합니다.
- 노드 버전과 거래 version을 기록합니다.
- 조상·자손·cluster의 건수와 합산 vsize를 확인합니다.
- 수수료를 올리기 전 topology 거부인지 feerate 거부인지 구분합니다.
부모가 사라지면 자식만 남아 확정될 수 없습니다
자식 입력은 부모가 만든 outpoint를 참조합니다. 부모가 RBF로 다른 출력 구조의 거래로 교체되거나 멤풀에서 퇴출되면 기존 자식은 필요한 입력을 얻지 못합니다. 노드가 부모를 모르는 상태에서 자식만 받으면 missing inputs로 거부할 수 있습니다.
지갑 화면에서 자식이 pending이라고 보일 때 자식 수수료만 보지 말고 부모 상태를 먼저 확인하세요. 부모와 자식을 패키지로 평가하는 경로가 있어도 모든 노드·버전·거래 형태가 동일하게 지원하는 것은 아닙니다. 브로드캐스트 서비스 하나의 성공 응답은 네트워크 전체 전파를 보장하지 않습니다.
수수료 평가는 개별 거래와 묶음을 나눠 봅니다
낮은 수수료 부모와 높은 수수료 자식을 함께 채굴하면 두 거래의 총수수료를 총vsize로 나눈 패키지 수수료율이 의미를 가질 수 있습니다. 하지만 topology 한도를 초과한 집합은 단가만 높여도 같은 방식으로 받아들여지지 않을 수 있습니다.
v31.0 cluster mempool 문서는 연결 거래를 feerate diagram으로 평가하는 방향을 설명합니다. 단순히 모든 거래의 평균 하나만 계산하면 어떤 부분집합이 비효율적인지 놓칠 수 있습니다. 사용자 진단에서는 먼저 구조 제한을 통과하는지 확인하고 그다음 수수료 부족을 다룹니다.
연쇄 생성을 멈추고 확인된 출력으로 경계를 끊습니다
상점 지급이나 자동 출금이 동일 change를 계속 재사용하면 긴 미확인 사슬이 만들어질 수 있습니다. 운영 지갑은 확인된 UTXO를 충분히 준비하고, 미확인 change 재사용 횟수를 제한하며, 거래 생성 전에 멤풀 수용 여부를 검사하는 편이 안전합니다.
이미 한도에 가까우면 새 자식을 계속 만드는 대신 기존 거래의 확인 또는 안전한 교체를 기다립니다. 임의로 부모·자식 일부를 다시 전파하면 충돌 상태가 복잡해질 수 있습니다. 복구 조치는 지갑 종류, RBF 신호, 자식 존재 여부와 사용 노드 버전을 확인한 뒤 선택하세요.
자주 묻는 질문
조상 25개 제한은 지금도 항상 맞나요?
아닙니다. Bitcoin Core 31.0 이후 cluster mempool과 v3 별도 정책 등 구현이 변했습니다. 실제 노드 버전 문서를 확인하세요.
부모가 미확인이어도 자식을 만들 수 있나요?
가능하지만 부모에 의존하며 topology·수수료·중계 정책을 함께 통과해야 합니다.
한 노드의 거부는 거래가 무효라는 뜻인가요?
정책 거부라면 합의 무효와 다릅니다. 그래도 전파가 제한될 수 있으므로 이유와 지원 경로를 확인해야 합니다.
