누군가 낮은 수수료로 비트코인을 보냈는데 아직 확인되지 않았다고 해 봅시다. 지갑이 그 결제에 대해 CPFP를 지원한다면 다른 내 주소로 보내는 등의 후속 거래를 만들 수 있습니다. 원래 거래는 부모, 새 거래는 자식이라고 부릅니다. 자식은 부모가 만든 출력, 즉 사용 조건이 붙은 금액을 사용합니다. 채굴자가 자식의 수수료를 받으려면 부모도 필요합니다. 원래 결제는 바뀌지 않습니다. 전체 수수료를 높이면 확인에 도움이 될 수 있지만, 확인 시점까지 보장하지는 않습니다.
Anna는 100 000 sat를 기다리고 있습니다. sat는 비트코인의 가장 작은 단위인 satoshi의 약자입니다. 결제는 보이지만 보내는 사람이 낮은 수수료를 설정해 아직 블록에 들어가지 않았습니다. Anna의 지갑은 이 미확인 출력을 사용할 수 있습니다. Anna는 그 출력으로 자기 주소에 보내는 새 거래를 만들고 더 높은 수수료를 냅니다. 보내는 사람이나 별도 서비스에 보상을 주는 것이 아니라, 일반적인 비트코인 거래 수수료를 내는 것입니다. 채굴자는 원래 거래 없이 새 거래만 확인할 수 없습니다. 원래 거래가 없으면 검증 중인 체인에 필요한 출력이 없기 때문입니다. 부모는 이미 앞서 확인되었거나 같은 블록에서 자식보다 먼저 나와야 합니다. 필요한 다른 미확인 조상 거래도 먼저 포함되어야 합니다. 반대는 성립하지 않습니다. 부모는 자식 없이도 확인될 수 있습니다. [3] [5]
다른 미확인 조상 거래가 없는 간단한 예를 보겠습니다. 부모의 크기는 200 vB이고 수수료는 200 sat입니다. 가상 바이트인 vB는 거래 가중치에서 계산한 크기 단위이며, sat/vB는 그 단위마다 몇 사토시를 제시하는지 나타냅니다. 자식의 크기는 100 vB이고 Anna가 내는 수수료는 2 800 sat입니다. 자식에 출력이 하나뿐이라면 받은 100 000 sat 중 97 200 sat가 남습니다. 두 거래는 합쳐서 300 vB에 3 000 sat를 내므로 전체 수수료율은 10 sat/vB입니다. 자식만 보면 28 sat/vB이지만, 채굴자는 수수료가 낮은 부모도 넣어야 합니다. 자식의 높은 숫자만 보면 이 의존 관계를 놓치게 됩니다. 이는 원리를 설명하는 계산이지 오늘의 권장 수수료율이 아닙니다. 실제 크기와 필요한 총수수료는 지갑이 확인합니다. 다른 조상 거래도 필요하다면 계산이 달라집니다. 심화 내용으로, 거래를 검증하고 전달하는 프로그램인 노드가 패키지를 로컬에서 수락할 때는 이미 수락한 거래를 다시 계산에 넣지 않으며 조정된 수수료를 사용할 수도 있습니다. 따라서 그때 표시되는 수수료율이 채굴자를 위한 단순 합산과 반드시 일치하는 것은 아닙니다. 조정된 수수료는 노드의 판단에 쓰이는 로컬 값일 뿐, 거래가 실제로 지불하는 수수료를 바꾸지 않습니다. [3]
CPFP는 누구나 남의 거래를 빠르게 만들 수 있는 버튼이 아닙니다. 부모의 출력을 사용할 권한이 있고, 서명을 비롯한 사용 조건을 충족해야 합니다. Anna는 받는 사람으로서 이를 할 수 있습니다. 보내는 사람은 남은 자기 자금을 돌려받는 change, 즉 거스름돈 출력을 사용할 수 있을지도 모릅니다. 탐색기나 Watch-only Wallet에서 금액을 보는 것만으로는 부족합니다. Watch-only Wallet은 결제를 조회하는 지갑이며, 자금을 지출하는 데 필요한 개인 키를 자체적으로 보관하지 않습니다. 지갑도 미확인 출력의 사용을 지원해야 합니다. 서명하기 전에 어떤 출력을 쓰는지, 돈이 어디로 가는지, 얼마나 남는지, 총수수료가 얼마인지 확인하세요. 출력 금액이 작으면 수수료가 상당 부분을 소모할 수 있습니다. [5]
Replace-by-Fee (RBF)는 원래 거래를 대체할 새로운 충돌 거래를 만듭니다. 적어도 하나의 같은 입력을 사용하지만 입력 전체가 정확히 같을 필요는 없습니다. CPFP는 원래 결제와 그 식별자를 그대로 두고 거래를 하나 더 추가합니다. RBF에는 대체 거래 입력의 조건을 충족할 권한이 필요하며, 일반적인 CPFP에는 원래 결제 출력의 조건을 충족할 권한이 필요합니다. 그래서 받는 사람은 보내는 사람의 대체 거래에 서명할 수 없어도 CPFP를 사용할 수 있습니다. 관계없는 별도의 결제에 높은 수수료를 붙여 보내는 것은 도움이 되지 않습니다. 자식이 실제로 대기 중인 결제에 의존해야 합니다. [3]
전체 수수료율이 높아지면 채굴자가 두 거래를 선택할 이유가 커지지만, 다음 블록의 자리를 예약해 주지는 않습니다. 더 높은 수수료를 내는 거래가 들어올 수도 있고, 일부 채굴자가 패키지를 받지 못할 수도 있습니다. 원래 결제와 자식의 확인 상태를 모두 살펴보세요. 노드가 수락했다고 표시하는 것은 아직 블록에서 확인되었다는 뜻이 아닙니다. 보내는 사람이 RBF로 원래 결제를 대체하면, 옛 출력을 참조하는 자식은 다른 새 거래에 자동으로 연결되지 않습니다. 상황을 다시 확인해야 합니다. 자식을 만들었다고 미확인 입금이 확실한 결제로 바뀌는 것도 아닙니다. [3]
다음 절은 더 깊이 알아보거나 자기 노드를 운영하는 독자를 위한 규칙입니다. Mempool은 특정 노드의 대기 거래 목록이지 네트워크 전체가 공유하는 하나의 줄이 아닙니다. 패키지는 함께 제출하는 거래 묶음입니다. 거래가 유효한지, 노드가 수락하는지, 채굴자가 선택하는지는 구별해야 할 세 가지 판단입니다. 합의는 거래와 블록의 유효성을 결정합니다. mempool 정책은 로컬 수락과 중계를, 채굴자 규칙은 후보 블록에 넣을 거래 선택을 결정합니다. CPFP는 합의를 바꾸지 않습니다. 경제적으로 유리한 패키지도 로컬 규칙을 위반할 수 있으며, 한 노드의 수락은 다른 노드나 채굴자를 구속하지 않습니다. [3] [5]
부모와 자식을 함께 전달하는 방식은 계속 발전합니다. Package CPFP는 관련 거래를 패키지로 평가한다는 뜻입니다. RPC는 노드와 상호작용하는 명령이며, minrelaytxfee는 일반적인 전달에 필요한 노드의 최소 수수료율을 뜻합니다. TRUC는 조상과 후손의 관계를 제한하는 특별한 거래 규칙입니다. 아래 이력은 명시된 Bitcoin Core 버전을 기준으로 합니다. Bitcoin Core 26은 submitpackage RPC와 package CPFP를 추가했습니다. 당시 자식은 mempool의 동적 최저 수수료율보다 낮은 부모를 도울 수 있었지만 최저 중계 수수료율 아래의 부모는 도울 수 없었습니다. 이 제한은 불변이 아닙니다. Core 31은 지원되는 부모 하나·자식 하나 패키지 중계에서 TRUC 이외의 거래도 포함하여 minrelaytxfee보다 낮거나 수수료가 0인 부모를 허용합니다. 자식의 다른 미확인 부모들은 이미 mempool에 있어야 합니다. 로컬 수락은 여전히 네트워크 전체의 동일한 전파를 보장하지 않습니다. [1] [2]
노드는 무한히 큰 의존 관계망을 받아들일 수 없습니다. 조상은 다른 거래보다 먼저 필요한 거래이고, 후손은 그 뒤로 이어지는 출력을 사용하는 거래입니다. WU는 거래 가중치 단위이며 토폴로지는 거래가 연결된 방식을 뜻합니다. 이러한 기술적 한도는 해당 노드 버전의 정책입니다. 제한은 메모리, 프로세서 자원과 대역폭을 보호합니다. 구버전 Core는 조상과 후손의 수와 크기를 제한했지만 Core 31은 이 mempool 제한을 연결된 cluster 제한으로 대체했습니다. 별도의 패키지 제한은 남아 있습니다. Core 31 문서는 최대 25개 거래와 총가중치 404000 WU를 명시합니다. 가중치는 가상 크기가 아닙니다. 잘못된 연결 구조, 충돌 또는 노드가 허용하는 거래 형식에 관한 로컬 조건(표준성) 위반은 충분한 수수료가 있어도 CPFP를 막을 수 있습니다. [2] [3]
서로 의존하는 미확인 거래는 항상 따로 경제성을 평가할 수 있는 것은 아닙니다. Cluster Mempool은 노드가 연결된 묶음을 살펴볼 수 있게 합니다. cluster는 연결된 전체 그룹이고, chunk는 거래 선택 과정에서 처리하는 더 작은 그룹입니다. 이미 확인된 블록의 조각이 아닙니다. Bitcoin Core 31은 Cluster Mempool을 사용합니다. cluster는 부모·자식 관계를 어느 방향으로든 따라 연결되는 거래들로 구성됩니다. cluster당 기본 제한은 64개 거래와 가상 크기 101 kB이며 설정할 수 있습니다. 순서는 함께 채굴되는 chunks라는 묶음과 그 수수료율을 고려합니다. 과거 CPFP carveout은 후손 제한에 대한 제한적인 예외를 허용했지만 Core 31은 이를 폐지했습니다. 이 방식으로 cluster의 거래 수 제한을 우회할 수는 없습니다. [2] [4]
이 절의 명령들은 서로 바꿔 쓸 수 없습니다. 테스트는 결과만 설명할 수 있지만, 패키지 제출은 서명된 거래를 실제로 수락하고 전달할 수 있습니다. vsize 필드는 가상 크기를 나타냅니다. 일반 지갑이 이런 세부 사항을 사용자를 대신해 처리할 수 있습니다. Core 31에서 getmempoolentry RPC는 해당 노드의 mempool에 있는 거래의 수수료, vsize, 의존 관계와 chunk 데이터를 보여 주며 getmempoolcluster는 관련 cluster를 보여 줍니다. testmempoolaccept RPC는 수락하거나 전파하지 않고 로컬 테스트를 합니다. 여러 거래는 조상을 후손보다 먼저 배치해야 하며 서로 또는 mempool과 충돌해서는 안 됩니다. submitpackage RPC는 지원되는 패키지를 실제로 mempool 수락과 중계를 위해 제출하므로 단순한 테스트가 아닙니다. 개별 거래의 결과, 버전과 설정을 확인하세요. 어떤 결과도 거래가 블록에 포함된다고 보장하지는 않습니다. [2] [6] [7] [8] [9]
더 정확히 이해하려면 이 항목과 함께 다음도 읽어 보세요 Replace-by-Fee (RBF), Transaction Fees, Fee Rate, Mempool, 트랜잭션, UTXO. 다음 항목에서도 이 글을 참조합니다 Change Address, 확인, 이중 지불, Fee Rate.