Package Relay는 비트코인 노드가 서로 연관된 미확인 거래를 함께 전달하고 평가하는 방식입니다. 첫 거래의 수수료는 부족하지만 그 출력을 사용하는 후속 거래가 둘 모두에 충분한 수수료를 더할 때 도움이 됩니다. 거래의 유효성과 노드의 로컬 규칙은 여전히 충족해야 하며, 묶어서 평가한다고 확인이 보장되지는 않습니다.
안나는 비트코인 결제를 기다리고 있습니다. 보낸 사람이 낮은 수수료를 설정한 뒤 블록 공간 수요가 늘었습니다. 블록은 공동 기록에 추가하는 거래 묶음입니다. 노드는 거래와 블록을 검증하고 네트워크의 다른 참여자와 통신하는 소프트웨어입니다. 일부 노드는 이 거래를 자신의 mempool, 즉 미확인 거래를 모아 두는 로컬 저장 공간에 받아들이지 않습니다. 안나는 후속 거래로 수수료를 더하고 싶습니다. 하지만 후속 거래는 거부한 노드가 아직 입금을 알지 못하는 코인을 사용합니다. Package Relay는 필요한 관련 정보를 전달해 이 간극을 줄입니다. 노드가 수수료가 낮은 첫 거래만 따로 평가하지 않도록 돕는 것입니다. [1] [6]
첫 거래를 부모 거래, 그 출력을 사용하는 거래를 자식 거래라고 합니다. 출력은 정해진 조건을 충족하면 사용할 수 있는 구체적인 금액입니다. 안나가 부모 출력의 사용 조건을 충족할 수 있다면 자식 거래를 만들 수 있습니다. 받은 코인을 자신의 다른 주소로 옮기면서 일부를 수수료로 내는 방법이 그 예입니다. 이것이 CPFP (Child Pays for Parent)입니다. 자식의 높은 수수료가 두 거래의 확인을 도울 수 있습니다. Package Relay는 전달과 평가를 돕지만 수수료를 대신 내거나 서명하지 않으며, 남의 코인에 접근할 권한도 주지 않습니다. [1] [5]
부모의 크기가 200 vB이고 수수료가 200 sat, 자식의 크기가 100 vB이고 수수료가 1300 sat이라고 해 보겠습니다. vByte(vB)는 보통 수수료 계산에 쓰이는 가상 거래 크기 단위이고, sat은 비트코인의 작은 단위입니다. 합계는 300 vB에 1500 sat, 즉 5 sat/vB입니다. 개별 요율인 1과 13 sat/vB를 단순 평균한 값이 아닙니다. 여기서는 아직 수락되지 않은 두 거래만 있고, 다른 미확인 조상 거래나 로컬 수수료 조정은 없다고 가정합니다. 실제 노드는 이미 수락한 거래를 다시 계산하지 않으므로 평가 대상에 어떤 의존 거래가 포함되는지가 중요합니다. [5] [3]
자식의 입력은 부모의 출력을 가리킵니다. 둘을 함께 평가할 수는 있지만, 코인의 빠진 이력을 무시할 수는 없습니다. 목록에서는 포함된 각 부모를 자식보다 앞에 놓습니다. 이를 위상 순서라고 합니다. 서명과 나머지 유효성 규칙도 계속 검사합니다. 디지털 서명은 비밀 숫자 값인 개인 키로 결제 승인을 증명하며, 키 자체는 공개하지 않습니다. 같은 코인을 사용하는 두 충돌 거래가 수수료를 더한다고 양립할 수 있게 되지는 않습니다. 패키지의 개수, 크기, 구조에 대한 제한은 노드의 작업량도 제한합니다. 임의로 긴 거래 사슬을 보낼 수 있다는 뜻은 아닙니다. [5] [3] [7]
지갑은 비트코인을 받고 보내는 앱이나 기기입니다. 전달은 노드가 데이터를 받았다는 뜻입니다. 수락은 자체 규칙에 따라 거래를 mempool에 넣었다는 뜻입니다. 확인에는 블록 포함이 필요합니다. 노드마다 mempool이 다르므로 한 곳에서 성공했다고 이웃의 결정까지 알 수는 없습니다. Bitcoin Core 28.0에서 합산 요율은 혼잡한 mempool의 변동 최소 요율을 넘는 데 도움이 되지만, 별도의 최소 중계 요율을 일반적으로 없애지는 않습니다. 이 버전에는 특별한 제약을 받는 TRUC Transactions에 대한 예외가 있습니다. 따라서 수수료가 충분히 높은 자식이 모든 부모를 구할 수 있는 것은 아닙니다. [2] [5] [8]
Gloria Zhao의 BIP 331은 지원 기능 협상과 조상 정보 및 거래 자체를 요청하는 메시지를 설명하는 더 넓은 제안입니다. Bitcoin Core 28.0은 기존 네트워크 프로토콜로 부모 하나와 자식 하나를 묶는 제한된 기능을 문서화했습니다. 로컬 프로그래밍 인터페이스인 RPC는 독립적인 부모가 여러 개인 자식도 수락할 수 있었지만, 노드 간 중계도 똑같이 지원된다는 뜻은 아니었습니다. 이 설명은 해당 버전에 한정됩니다. 다른 버전에서는 그 문서와 상대 노드의 지원 기능을 확인해야 합니다. [1] [2]
Bitcoin Core 28.0의 submitpackage 명령은 준비한 패키지를 로컬 노드에 제출합니다. 자식과 그 미확인 부모들을 기대하며, 부모끼리는 의존하지 않고 자식은 마지막에 와야 합니다. package_msg와 개별 tx-results를 함께 읽어야 합니다. 노드가 패키지 일부만 수락할 수도 있습니다. 오류가 나더라도 이미 수락한 모든 것을 자동으로 되돌리지는 않습니다. 전체 성공도 네트워크 전파나 확인을 증명하지 않습니다. 일반적인 결제 가속 서비스가 아니라, 주소만이 아닌 올바르게 구성한 거래를 요구하는 명령입니다. [3]
분리된 테스트 환경에서 testmempoolaccept로 방송 없이 수락 여부를 검사할 수 있습니다. 다른 거래가 실패하면 해당 거래가 완전히 검증되지 않아 allowed가 없을 수 있습니다. 테스트 호출과 submitpackage의 조건도 완전히 같지는 않습니다. 버전, 설정, 의존 관계, 크기와 수수료를 기록하고, 다른 노드의 수락은 별도로 관찰해야 합니다. 시간이 중요한 Lightning Network 거래에는 여전히 제때 대응해야 합니다. Package Relay만으로는 혼잡, 불규칙한 블록 간격, pinning을 없애지 못합니다. pinning은 mempool 규칙을 의도적으로 이용해 수수료 인상을 방해하는 행위입니다. [4] [2] [1]
더 정확히 이해하려면 이 항목과 함께 다음도 읽어 보세요 Mempool, CPFP (Child Pays for Parent), Fee Rate, Replace-by-Fee (RBF), Lightning Network, vByte. 다음 항목에서도 이 글을 참조합니다 CPFP (Child Pays for Parent), Gloria Zhao, Cluster Mempool, TRUC Transactions.