비트코인암호학채굴 intermediate

RBF(Replace-By-Fee): 비트코인 수수료 재설정

비트코인 Replace-By-Fee 메커니즘의 기술적 심층 분석 — BIP-125 옵트인 RBF, 풀 RBF, 지갑에서의 사용법, 멤풀 역학, 가맹점 영향.

· 9분

비트코인 트랜잭션을 방금 보냈다. 멤풀을 확인하고, 수수료가 상대적으로 낮은 것을 보고, 수수료율을 5 sat/vB로 설정했다. 하지만 “전송” 버튼을 누른 후 트랜잭션이 브로드캐스트되기까지의 10초 사이에, 인기 거래소가 대규모 UTXO 통합을 시작했다 — 8-12 sat/vB 수준의 수천 개 트랜잭션이 멤풀에 쏟아졌다. 당신의 5 sat/vB 트랜잭션은 이제 우선순위 대기열의 맨 아래에 놓여 있다. 현재 블록 생산 속도로는 몇 시간, 며칠이 걸릴 수 있다. 멤풀이 계속 혼잡하면 기본 336시간 만료 후 완전히 삭제될 수도 있다.

이것이 **Replace-By-Fee(RBF)**가 해결하는 문제다. RBF는 미확인 트랜잭션의 새 버전을 더 높은 수수료로 생성하여, 채굴자의 트랜잭션 선택 알고리즘에서 더 높은 우선순위 위치로 효과적으로 “끌어올릴” 수 있게 한다. 비트코인에서 가장 실용적으로 중요한 기능 중 하나이지만, 여전히 널리 오해되고 있다.

RBF가 실제로 하는 것

핵심적으로 RBF는 단순하다: 트랜잭션 발신자가 멤풀의 미확인 트랜잭션을 동일한 입력을 사용하지만 더 높은 수수료를 지불하는 새로운 트랜잭션으로 교체할 수 있게 한다. 교체 트랜잭션은 원본을 무효화한다 — 동일한 UTXO(미사용 트랜잭션 출력)를 소비하기 때문에 둘 다 확인될 수 없다.

노드가 교체 트랜잭션을 받으면:

  1. 교체가 원본과 동일한 입력 중 하나 이상을 소비하는지 확인한다.
  2. 교체가 원본보다 엄격하게 높은 절대 수수료를 지불하는지 확인한다.
  3. 교체가 교체 릴레이의 대역폭 비용을 충당할 만큼 충분히 높은 수수료율을 지불하는지 확인한다(증분 릴레이 수수료, 일반적으로 교체 크기의 1 sat/vB).
  4. 교체가 원본에 없던 새로운 미확인 입력을 도입하지 않는지 확인한다(피닝 공격 방지).
  5. 교체되는 원본 트랜잭션 수(자손 포함)가 100개를 초과하지 않는지 확인한다.

모든 조건이 충족되면, 노드는 원본 트랜잭션을 멤풀에서 제거하고 교체를 수락한다.

역사: BIP-125와 옵트인 논쟁

사토시 나카모토의 비트코인 원래 구현에는 실제로 기초적인 교체 메커니즘이 포함되어 있었다 — 트랜잭션에는 교체를 허용하기 위한 nSequence 필드가 있었다. 그러나 이 기능은 초기에 비활성화되었다. 공격자가 추가 수수료 없이 무제한으로 트랜잭션을 교체하여 네트워크의 멤풀 릴레이에 DoS 공격을 할 수 있었기 때문이다.

BIP-125: 옵트인 RBF (2015)

2016년 2월, BIP-125가 Bitcoin Core 0.12.0에 구현되었다. 옵트인 RBF를 도입했다: 트랜잭션이 입력의 nSequence 값을 0xFFFFFFFE(4294967294) 미만으로 설정하여 교체 가능함을 신호한다. 구체적으로:

  • nSequence < 0xFFFFFFFE → 옵트인 RBF 신호 (교체 가능)
  • nSequence = 0xFFFFFFFE → 상대적 타임록 신호 (RBF 아님)
  • nSequence = 0xFFFFFFFF → 최종 트랜잭션 (RBF 아님, 타임록 아님)

“옵트인” 설계는 정치적 타협이었다. 비트코인 커뮤니티의 많은 사람들 — 특히 영확인(zero-conf) 트랜잭션에 의존하는 가맹점과 결제 처리업체 — 은 무제한 교체가 이중 지불을 사소하게 쉽게 만든다며 반대했다. RBF를 옵트인으로 만들면, 가맹점이 교체 가능 트랜잭션과 교체 불가능 트랜잭션을 구별할 수 있다는 논리였다.

실제로 이 구별은 항상 다소 환상적이었다. 채굴자는 옵트인 신호와 관계없이 가장 높은 수수료를 지불하는 트랜잭션을 포함하는 것이 경제적으로 인센티브가 있다. 옵트인 플래그는 노드가 시행하는 릴레이 정책이지, 블록체인이 시행하는 합의 규칙이 아니다. 수정된 소프트웨어를 실행하는 채굴자는 nSequence 신호와 관계없이 교체 트랜잭션을 수락할 수 있었다(실제로 일부는 그렇게 했다).

풀 RBF (2022-2023)

2023년 5월에 출시된 Bitcoin Core 25.0은 mempoolfullrbf 옵션(기본값 false)을 도입하여, 노드 운영자가 옵트인 신호와 관계없이 교체 트랜잭션을 수락할 수 있게 했다. Bitcoin Core 28.0(2024년 말)에서는 풀 RBF가 기본 동작이 되었다.

풀 RBF로의 전환이 중요한 몇 가지 이유:

  1. 프로토콜의 정직성: 옵트인 RBF가 결코 진정한 보안 보장이 아니었다는 현실을 인정했다. 어떤 채굴자든 항상 트랜잭션을 교체할 수 있었다; 옵트인 신호는 대부분의 노드에서 릴레이 정책에만 영향을 미쳤다.
  2. 단순화된 멘탈 모델: 사용자는 더 이상 트랜잭션이 RBF를 “신호”하고 있는지 걱정할 필요가 없다. 모든 미확인 트랜잭션은 잠재적으로 교체 가능하다. 이것이 현실을 더 정확하게 표현한다.
  3. 개선된 수수료 시장 효율성: 풀 RBF는 가장 높은 수수료를 지불하는 트랜잭션이 항상 우선시되도록 하여 비트코인 수수료 시장의 효율성을 향상시킨다.

실제로 RBF 사용하기

Bitcoin Core에서

Bitcoin Core의 지갑은 버전 0.12.0부터 RBF를 지원해 왔다. RBF 활성화 트랜잭션 전송:

# RBF 활성화로 전송 (최근 버전에서는 기본값)
bitcoin-cli sendtoaddress "bc1q..." 0.01

# 미확인 트랜잭션의 수수료 인상
bitcoin-cli bumpfee "원본_트랜잭션의_txid"

bumpfee 명령은 다음과 같은 교체 트랜잭션을 생성한다:

  • 원본과 동일한 입력을 사용
  • 동일한 수신자에게 동일한 금액을 전송
  • 더 높은 수수료를 지불하기 위해 잔돈 출력을 줄임
  • 잔돈 출력이 너무 작으면(더스트) 추가 입력을 추가할 수 있음

Sparrow Wallet에서

Sparrow Wallet은 직관적인 RBF 인터페이스를 제공한다:

  1. 트랜잭션 탭으로 이동한다.
  2. 미확인 트랜잭션을 우클릭한다.
  3. “Increase Fee” (또는 자금을 자신에게 돌려보내려면 “Cancel Transaction”)를 선택한다.
  4. 수수료 슬라이더로 새 수수료율을 설정한다.
  5. 서명하고 브로드캐스트한다.

Electrum에서

  1. 히스토리 탭에서 미확인 트랜잭션을 우클릭한다.
  2. **“Increase fee”**를 선택한다.
  3. 새 수수료율을 설정한다.
  4. 서명하고 브로드캐스트한다.

모바일 지갑에서

  • Blue Wallet: 미확인 트랜잭션 탭 → “Bump Fee”
  • Muun: 서브마린 스왑 메커니즘을 통해 자동으로 수수료 인상 처리 (전통적인 RBF는 아니지만 동일한 효과)
  • Phoenix (라이트닝 중심): 온체인 앵커 트랜잭션에 대해 수수료 인상 사용

RBF가 필요한 상황

시나리오 1: 수수료 추정 실패

수수료 추정은 미래의 멤풀 상태를 예측해야 하므로 본질적으로 불완전하다. 최고의 수수료 추정기도 갑작스러운 수요 급증 — 거래소 출금, 에어드롭 청구, Ordinals 기반의 NFT 민팅, 시장 이벤트 중 동시 매수 — 시에는 과소 추정할 수 있다.

RBF는 안전망이다. 보수적인(낮은) 수수료율로 시작하고, 원하는 시간 내에 확인되지 않을 때만 인상할 수 있다. 이 전략은 항상 “빠른” 확인을 위해 과다 지불하는 것보다 종종 비용을 절약한다.

시나리오 2: 시간에 민감한 결제

시간 제한이 있는 구매(콘서트 티켓, 한정 세일)에 대한 결제 상황이다. 트랜잭션이 멤풀에 걸려 있다. RBF 없이는 기다려야 한다 — 구매 기간을 놓칠 수도 있다. RBF로 수수료를 현재 빠른 확인 요율로 인상하면 다음 블록에 포함된다.

시나리오 3: 저수수료 기간의 UTXO 통합

경험 있는 사용자들은 저수수료 기간에 작은 UTXO를 통합한다. 1 sat/vB로 일괄 통합했는데 수수료가 갑자기 올랐다면, RBF로 통합을 포기하고 더 높은 수수료로 재생성하지 않고도(처음부터 새 트랜잭션을 생성하므로 더 비싸다) 수수료를 인상할 수 있다.

시나리오 4: 실수 교정

앨리스에게 0.1 BTC를 보냈는데 밥에게 보내려 했다는 것을 깨달았다. 트랜잭션이 아직 미확인이라면, 대신 밥에게 0.1 BTC를 보내는 RBF 교체를 생성할 수 있다. 앨리스에게 보낸 원래 트랜잭션은 절대 확인되지 않는다.

중요한 주의사항: 이것은 원래 트랜잭션이 미확인인 동안에만 작동한다. 트랜잭션이 블록에 채굴되면, 최종적이고 비가역적이다 — 확인된 트랜잭션에 대한 RBF는 없다.

RBF와 영확인 보안

RBF의 가장 논쟁적인 측면은 항상 영확인(zero-confirmation) 트랜잭션 — 네트워크에 브로드캐스트되었지만 아직 블록에 포함되지 않은 트랜잭션 — 에 대한 영향이었다.

가맹점의 딜레마

일부 사업체, 특히 오프라인 매장과 POS 가맹점은 속도를 위해 영확인 트랜잭션에 의존했다. 고객이 트랜잭션을 브로드캐스트하고, 가맹점이 멤풀에서 이를 확인하고, 블록 확인을 기다리지 않고 즉시 상품이나 서비스를 제공한다(블록 확인은 평균 10분이지만 1시간 이상 걸릴 수 있다).

RBF에 대한 반대 논리는 가맹점에 대한 이중 지불을 사소하게 쉽게 만든다는 것이었다: 고객이 가맹점에 트랜잭션을 브로드캐스트하고, 상품을 받고, 즉시 자금을 자신의 지갑으로 되돌리는 RBF 교체를 브로드캐스트할 수 있다.

영확인이 결코 안전하지 않았던 이유

현실은 RBF 이전에도 영확인은 결코 강력한 보안 보장이 아니었다:

  1. 어떤 채굴자든 릴레이 정책과 관계없이 충돌하는 트랜잭션을 수락할 수 있었다.
  2. 레이스 공격(충돌하는 트랜잭션을 네트워크의 다른 부분에 동시에 브로드캐스트)은 항상 가능했다.
  3. 피니 공격(채굴자가 충돌하는 트랜잭션이 포함된 블록을 미리 채굴)은 이론적으로 실행 가능했다.

솔직한 평가: 사소한 금액 이상의 트랜잭션에서는 최소 1회 확인(평균 약 10분)을 기다리는 것이 항상 권장되는 관행이었다. 고가치 트랜잭션에서는 3-6회 확인이 강력한 확률적 최종성을 제공한다.

즉각적인 결제 확인이 필요한 사업체에게는 라이트닝 네트워크가 암호학적 보안 보장과 함께 진정한 즉시 최종성을 제공한다 — 온체인 영확인 트랜잭션보다 근본적으로 더 나은 솔루션이다.

멤풀 역학과 RBF

RBF를 이해하려면 멤풀 — 각 비트코인 노드가 독립적으로 유지하는 미확인 트랜잭션 대기열 — 을 이해해야 한다.

채굴자의 트랜잭션 선택 방식

채굴자는 블록 크기 제한(약 400만 웨이트 단위, 실제 데이터로 약 1.5-2.5 MB) 내에서 수수료 수익을 극대화하도록 멤풀에서 트랜잭션을 선택하여 블록을 구성한다. 고려하는 알고리즘:

  1. 수수료율 (가상 바이트당 사토시): 높은 수수료율 = 높은 우선순위.
  2. 조상 수수료율: 트랜잭션이 미확인 부모에 의존하는 경우, 전체 조상 패키지의 결합 수수료율을 평가한다.
  3. 트랜잭션 크기: 큰 트랜잭션은 수수료 단위당 더 많은 블록 공간을 소비한다.

RBF는 이 선택 과정과 직접 상호작용한다. 수수료를 인상하면, 이 우선순위 대기열에서 트랜잭션을 더 높은 위치로 이동시키는 것이다.

수수료 시장으로서의 멤풀

멤풀은 블록 공간에 대한 실시간 경매로 기능한다. 어느 순간이든, 멤풀 상단의 트랜잭션(다음 블록에 포함될 가능성이 높은)의 수수료율을 조사하여 블록 포함에 대한 현재 “시세”를 관찰할 수 있다.

mempool.space 같은 도구가 멤풀의 실시간 시각화를 제공한다:

  • 다양한 확인 시간 목표에 대한 현재 수수료율
  • 가상 바이트 단위의 멤풀 총 크기
  • 수수료율 분포 히스토그램
  • 역사적 수수료율 추세

RBF를 사용하면 이 경매에 합리적으로 참여할 수 있다. 처음에 너무 낮게 입찰했다면 입찰을 올릴 수 있다. 이것은 모든 경매가 작동하는 방식과 유사하다 — 그리고 오스트리아 경제학의 관점에서, 이것은 아름답게 순수한 자유시장 메커니즘이다. 블록 공간은 희소한 자원이며, 수수료 시장은 어떤 중앙 권위도 가격을 지시하지 않으면서 이를 효율적으로 배분하는 가격 발견 메커니즘이다.

수수료율 계산

RBF로 수수료를 인상할 때 단위를 이해해야 한다:

수수료율 = 총 수수료 (사토시) / 트랜잭션 크기 (가상 바이트)

일반적인 단일 입력, 이중 출력 SegWit 트랜잭션은 약 141 vBytes이다. 20 sat/vB의 수수료율을 원한다면:

총 수수료 = 20 × 141 = 2,820 사토시 ≈ 0.00002820 BTC

비트코인 가격 약 $95,000(2026년 초 기준)에서 이는 약 $2.68이다. 높은 혼잡 시 같은 트랜잭션이 100 sat/vB이면: $13.40.

CPFP: RBF의 대안

RBF만이 정체된 트랜잭션을 가속하는 유일한 방법이 아니다. **Child-Pays-for-Parent(CPFP)**는 다르게 작동하는 대안 메커니즘이다:

원래 트랜잭션을 교체하는 대신, CPFP는 정체된 트랜잭션(부모)의 출력을 사용하는 새로운 트랜잭션(자식)을 생성한다. 자식은 부모-자식 패키지의 결합 수수료율이 채굴자에게 매력적이 될 만큼 충분히 높은 수수료를 지불한다. 채굴자는 자식을 포함하려면 부모를 포함해야 하므로, 둘 다 함께 확인된다.

CPFP vs. RBF 사용 시점

시나리오RBF 사용CPFP 사용
발신자인 경우선호가능 (잔돈 출력 통해)
수신자인 경우불가능선호
트랜잭션에 많은 출력이 있는 경우작동작동 (모든 출력 통해)
RBF 신호 없는 트랜잭션 (구형 지갑)일부 노드에서 릴레이 안 될 수 있음항상 작동

핵심 차이: RBF는 발신자가 사용하고, CPFP는 발신자(잔돈 출력 통해) 또는 수신자 모두 사용 가능하다. 이것은 수신 대기 중인 결제가 정체되었을 때 CPFP가 특히 유용한 이유다 — 높은 수수료로 들어오는(미확인) 출력을 소비하여 부모 트랜잭션을 가속할 수 있다.

실전 팁

  1. 지갑 설정에서 항상 RBF를 활성화하라. 단점이 없다. 최신 Bitcoin Core(28.0+)에서는 풀 RBF를 통해 모든 트랜잭션이 사실상 교체 가능하다.

  2. 긴급하지 않은 트랜잭션에서는 보수적인 수수료로 시작하라. mempool.space 또는 유사한 도구로 현재 상태를 확인하라. 현재 범위의 하단에 수수료율을 설정하고, 원하는 시간 내에 확인되지 않으면 RBF로 인상하라.

  3. 수수료율과 절대 수수료를 구별하라. 흔한 실수는 sat/vB의 수수료율 대신 BTC의 총 수수료에 집중하는 것이다. 1,000 사토시 수수료는 단순한 트랜잭션에는 넉넉할 수 있지만 입력이 많은 복잡한 트랜잭션에는 부족할 수 있다.

  4. 가능하면 트랜잭션을 일괄 처리하라. 단일 트랜잭션으로 여러 수신자에게 전송하는 것이 개별 트랜잭션보다 수수료 효율적이다. 일괄 트랜잭션에 수수료 인상이 필요하면, 하나의 RBF 교체가 모든 출력을 커버한다.

  5. “취소”에도 RBF를 사용하라. 잘못된 주소로 비트코인을 보냈는데 트랜잭션이 미확인이면, 즉시 전체 금액을 자신의 지갑으로 되돌리는(수수료 차감) RBF 교체를 생성하라.

관련 자료

관련 글

ideas 작업증명 (Proof of Work) ideas 반감기 (Halving) ideas 난이도 조정 (Difficulty Adjustment) — 비트코인의 항상성 ideas 슈노르 서명과 비트코인: 암호학적 업그레이드