Package Relay는 관련된 미확인 트랜잭션을 노드 사이에 전달하여 멤풀 수용 시 부모와 자식을 함께 평가할 수 있게 합니다. 데이터 전달, 로컬 수용 정책, 채굴자의 블록 선택은 별개 단계이며 패키지는 개별 트랜잭션의 합의 유효성을 바꾸지 않습니다.
수수료율이 낮은 부모는 노드가 더 높은 수수료의 자식을 보기 전에 거부될 수 있습니다. 필요한 트랜잭션이 채굴자에게 도달해야 CPFP가 경제적 유인이 됩니다. Package Relay는 이러한 전달의 공백을 메우는 데 도움이 되지만 서명이나 입력 검증을 대신하지 않습니다. [BIP 331 — Ancestor Package Relay]
예시 부모는 200 vB에 수수료 200 sat, 자식은 100 vB에 수수료 1300 sat입니다. 합산하면 1500 / 300 = 5 sat/vB이며 개별 수수료율 1과 13의 평균이 아닙니다. 이 예시는 다른 조상 없이 두 미확인 트랜잭션만 있다고 가정합니다. 실제 수용 여부는 노드 정책과 충돌에도 달려 있습니다. [BIP 331 — Ancestor Package Relay]
자식은 부모의 출력을 지출합니다. 위상 정렬된 목록에서는 부모가 자식보다 앞서야 합니다. 높은 수수료로도 누락된 조상이나 충돌하는 지출을 바로잡을 수 없습니다. 패키지의 크기, 개수, 형태 제한은 노드 자원을 보호하며 보편적인 합의 매개변수가 아닙니다. [Bitcoin Core 28.0 — submitpackage]
BIP 331은 지원 협상과 조상 정보 및 트랜잭션 다운로드용 전용 메시지를 설명합니다. 반면 Bitcoin Core 28.0은 기존 릴레이 프로토콜로 부모 하나와 자식 하나를 기회적으로 묶는 제한된 지원을 문서화했습니다. 로컬 RPC에서 여러 부모를 허용한다고 P2P도 똑같이 지원하는 것은 아닙니다. 이 설명은 버전 28.0에 관한 것이며 모든 버전이나 피어에 대한 보장이 아닙니다. [BIP 331 — Ancestor Package Relay] [Bitcoin Core 28.0 — release notes]
submitpackage 28.0은 트랜잭션을 검증하고 로컬 노드에 제출합니다. package_msg와 개별 tx-results를 모두 확인해야 합니다. 패키지 일부만 수용할 수 있으므로 실패 시 전부를 원자적으로 되돌리는 작업이 아닙니다. 완전히 성공해도 이웃 노드의 수용이나 채굴자의 적시 블록 포함을 증명하지는 않습니다. [Bitcoin Core 28.0 — submitpackage]
별도 테스트 환경에서 버전, 멤풀 설정, 의존 순서, 크기, 수수료를 기록합니다. testmempoolaccept는 방송하지 않고 검사하지만 결과를 submitpackage의 보장으로 보아서는 안 됩니다. 다른 노드에서의 수용도 관찰합니다. 시간 제약이 있는 Lightning 트랜잭션에는 여전히 여유가 필요합니다. 패키지 지원만으로 pinning, 혼잡, 블록 지연을 없앨 수 없습니다. [Bitcoin Core 28.0 — testmempoolaccept] [Bitcoin Core 28.0 — release notes]
더 정확히 이해하려면 이 항목과 함께 다음도 읽어 보세요 Mempool, CPFP (Child Pays for Parent), Fee Rate, Replace-by-Fee (RBF), Lightning Network. 다음 항목에서도 이 글을 참조합니다 CPFP (Child Pays for Parent), Gloria Zhao.