결제를 보냈다고 바로 확인된 것은 아닙니다. 채굴자가 블록에 넣기 전까지 거래를 검증하고 전달하는 프로그램인 노드는 각자의 Mempool, 즉 대기 중인 거래 목록에 보관할 수 있습니다. 일정한 조건에서 RBF는 기존 거래와 적어도 하나의 같은 UTXO, 곧 아직 쓰지 않은 출력을 소비하는 새 거래를 대신 받아들이게 합니다. 대체 거래에는 유효한 서명이 필요하며, 이를 네트워크로 보내야 합니다. 수수료를 높이는 것만으로 빠른 확인이 보장되지는 않습니다.
Anna는 20,000 sat을 보냈지만 결제가 여전히 대기 중입니다. sat은 bitcoin의 최소 단위인 satoshi의 약자입니다. 지갑은 RBF로 수수료를 올리는 기능을 제공합니다. 간단한 예에서 원래 거래는 50,000 sat을 소비해 수신자에게 20,000 sat을 주고 수수료로 200 sat을 내며, 29,800 sat을 잔돈으로 Anna에게 돌려줍니다. 대체 거래에서는 수신자 금액을 20,000 sat으로 유지하면서 수수료를 2,000 sat으로 올리고 Anna에게 28,000 sat을 돌려줄 수 있습니다. 이 숫자는 원리를 설명할 뿐 현재 권장 수수료가 아닙니다. 서명 전에 Anna는 주소, 수신자 금액, 새로운 총수수료를 확인합니다. 지갑은 필요한 입력에 서명할 수 있어야 하며 하드웨어 지갑을 다시 연결해야 할 수도 있습니다. 대체 거래에는 거래 식별자인 새 txid가 생기므로 수신자에게 새 추적 링크를 알려줘야 할 수 있습니다. 수수료 올리기는 다른 UTXO로 독립적인 두 번째 결제를 만드는 것과 다릅니다. 별개의 두 결제는 모두 확인되어 두 번 지불하게 될 수 있습니다. [1] [2] [12]
지갑은 첫 확인 전에 입금을 표시할 수 있습니다. 이를 zero-conf라고 합니다. 결제는 관측됐지만 아직 블록에 들어가지는 않은 상태입니다. 다른 버전이 먼저 확인되면 표시된 입금이 사라질 수도 있습니다. 따라서 ‘RBF 비활성화’ 표시는 결제가 확실하다는 증거가 아닙니다. 미확인 결제를 받고 물건을 건네는 것은 사업상 위험을 감수하는 결정입니다. 블록에 포함된 거래는 RBF로 다시 쓸 수 없습니다. 체인 재구성 가능성은 별개의 위험이며, 중요한 결제에서 확인을 여러 번 기다리는 이유입니다. [1]
RBF 자체는 원래 수신자를 유지하도록 요구하지 않습니다. 대체 거래는 수수료를 올려 같은 사람에게 계속 지불할 수도 있고 다른 곳으로 자금을 보낼 수도 있습니다. 두 버전이 같은 UTXO를 소비하려 하므로 기술적으로는 충돌하는 지출 시도, 즉 Double Spend입니다. 이 용어만으로 사기인지 판단할 수는 없습니다. 다만 공격자가 남의 결제에 마음대로 서명할 수 있는 것은 아닙니다. 대체 거래도 필요한 서명을 비롯한 소비 조건을 만족해야 합니다. 지갑이 자신에게 보내는 거래로 바꾸는 기능을 ‘취소’라고 표시하더라도, 이는 원래 거래보다 먼저 확인되려는 시도이지 확실한 결제 철회가 아닙니다. [1]
RBF는 대기 중인 거래 자체를 바꿉니다. Child Pays for Parent (CPFP)는 원래 거래를 남겨 두고 그 출력 중 하나를 소비하는 새 거래를 만듭니다. 채굴자는 새 거래의 수수료를 받으려면 원래 거래도 포함해야 하므로 둘의 합산 수수료율을 평가할 수 있습니다. 새 거래를 자식, 원래 거래를 부모라고 합니다. 해당 출력을 소비할 수 있는 사람, 예를 들어 결제 수신자나 잔돈을 사용하는 발신자가 자식 거래를 만들 수 있습니다. 지갑 지원, 필요한 서명, 거래 간 의존 관계에 따라 가능한 방법이 달라집니다. CPFP는 원래 결제를 대체하지 않으며 확인 시점도 보장하지 않습니다. [2]
Mempool은 Bitcoin 전체가 공유하는 하나의 대기열이 아닙니다. 각 노드는 자체 목록과 대기 거래의 수락·전달 규칙을 갖습니다. RBF는 이 로컬 정책에 속하며, 블록 유효성을 결정하는 합의 규칙은 아닙니다. 따라서 채굴자는 다른 노드가 이전에 저장하지 않았던 유효한 충돌 거래를 선택할 수 있습니다. Full Node는 이후 블록 전체를 Bitcoin 규칙에 따라 검사하며, 자신의 이전 mempool 선호가 결과를 결정하지 않습니다. 한 노드가 대체 거래를 받아들였다고 모든 노드의 수락이 보장되는 것은 아닙니다. [1] [6]
사용자는 총 얼마를 내는지와 거래 크기에 비해 어느 수수료율을 제시하는지라는 두 숫자를 구분해야 합니다. 예시 크기가 200 vB라면 200 sat은 1 sat/vB이고, 같은 크기에서 2,000 sat은 10 sat/vB입니다. 가상 바이트 vB는 거래 무게에서 도출하는 크기 단위입니다. 거래를 다시 구성하면 크기가 달라질 수 있으므로 지갑은 수수료율도 다시 계산해야 합니다. 총수수료는 satoshi 금액이며 수수료율은 가상 바이트당 sat/vB 금액입니다. Core 30의 단일 교체는 퇴출되는 모든 거래 수수료의 합에 더해 대체 거래 크기에 incrementalrelayfee를 적용한 비용을 내야 합니다. 수수료율은 직접 충돌하는 각 거래보다 높아야 합니다. 수수료율만 높이거나 satoshi만 더하는 것으로는 부족합니다. Core 30의 기본 incrementalrelayfee는 0.1 sat/vB지만 노드 설정은 다를 수 있습니다. [2] [9]
아직 확인되지 않은 첫 거래의 출력을 이미 다른 대기 거래가 소비하고 있을 수 있습니다. 이런 후속 거래를 후손이라고 합니다. 부모가 제거되면 후손도 mempool에서 사용할 수 없게 되므로 노드는 영향을 받는 전체 그룹을 고려해야 합니다. 부모 거래를 교체하면 그 출력을 소비하는 후손도 mempool에서 퇴출될 수 있어 언제나 두 거래만 비교하는 것은 아닙니다. Core 30의 단일 교체는 직접 충돌 거래마다 자기 자신을 포함한 후손 수를 더한 값을 100으로 제한합니다. 공유 후손은 여러 번 계산될 수 있습니다. 패키지 수수료와 관계가 교체 성공에 영향을 줍니다. [2]
노드는 대체 거래를 끊임없이 재계산하게 만들어 과부하를 일으키는 행위도 막아야 합니다. 서비스 가용성을 노리는 DoS 공격에 대한 보호입니다. UTXO는 이전 거래의 아직 소비되지 않은 출력이며, 새 거래의 입력이 이를 참조합니다. 다음 규칙은 Bitcoin Core 30에 관한 구체적인 설명이지 Bitcoin의 불변 법칙이 아닙니다. Bitcoin Core 30의 단일 대체 거래 정책은 새로운 미확인 입력과 퇴출 거래 수도 제한합니다. 같은 UTXO를 소비하는 것만으로는 부족하며 노드가 허용하는 거래 형식에 관한 로컬 조건(표준성)과 전파 및 유효성 규칙을 충족해야 합니다. 제한은 연산 자원, 메모리, 대역폭을 보호합니다. 패키지 교체 규칙은 노드 버전에 따라 별도로 평가해야 합니다. Core 31은 Cluster Mempool을 도입하면서 이 정책을 바꿨습니다. 서로 연결된 미확인 거래를 그룹으로 평가합니다. 대체 거래는 누적 수수료와 순차적으로 차지하는 공간을 비교하는 feerate diagram을 개선해야 합니다. 충분한 총수수료와 대체 거래를 전파하기 위한 추가 수수료 등 다른 조건도 여전히 적용됩니다. 따라서 앞서 설명한 Core 30의 한도를 새 버전에 그대로 적용하지 말고, 자신의 노드 규칙을 확인하세요. [2] [13]
일부 지갑에는 왜 아직 RBF 스위치가 있을까요? 초기 opt-in RBF 정책을 사용하던 노드는 대체를 허용한다는 사전 신호를 요구했습니다. Bitcoin Core 24에서 이 조건 없이 full-RBF를 설정할 수 있게 됐고, Core 28에서 기본 활성화됐으며, Core 29에서 mempoolfullrbf 스위치가 없어졌습니다. 아래 BIP125 설명은 원래 신호 방식에 관한 것이며 오늘날 모든 노드의 공통 규칙은 아닙니다. BIP125는 하나 이상의 입력에서 nSequence가 0xfffffffe보다 작으면 명시적 opt-in 신호로 보며, 미확인 조상으로부터 신호를 상속하는 방식도 설명합니다. 이는 역사적 정책이며 합의 조건이 아닙니다. Full-RBF는 신호 없이도 교체를 평가하므로 신호 부재가 결제의 교체 불가능성을 보장하지 않습니다. [1] [3] [4] [5] [6]
이 부분은 직접 노드를 운영하는 사람을 위한 설명입니다. RPC는 소프트웨어에 정보를 요청하거나 동작을 제어하는 명령이며, 수수료 올리기 버튼을 쓰기 위해 알아야 하는 것은 아닙니다. getmempoolentry는 해당 노드의 mempool에 있는 거래의 상태를 보여 줍니다. testmempoolaccept는 서명된 대체 후보 한 건을 현재 노드 mempool과 규칙에 맞춰 전파 없이 시험합니다. 다른 노드의 수락이나 채굴을 보장하지 않습니다. Core 28은 mempoolfullrbf 기본값으로 full-RBF를 켰고 Core 29는 이 옵션을 제거했습니다. getmempoolinfo는 수수료 매개변수를 제공하지만 Core 30의 fullrbf 필드는 사용 중단 예정으로 표시됩니다. 버전과 실제 설정을 확인해야 합니다. [5] [6] [7] [8] [10] [11]
더 정확히 이해하려면 이 항목과 함께 다음도 읽어 보세요 Transaction Fees, Mempool, CPFP (Child Pays for Parent), 이중 지불, 확인, Fee Rate. 다음 항목에서도 이 글을 참조합니다 Change Address, 확인, 이중 지불, Fee Rate.