"비트코인은 한 번 보내면 절대 취소가 안 된다"는 말은 절반만 맞아요. 갈리는 자리가 하나 있어요. 확인(confirmation)이 붙었는가예요. 아직 블록에 실리지 않고 대기열에 남아 있는 거래는 같은 입력을 쓰는 새 거래로 대체될 수 있고, 그 조건은 규격 문서와 구현 문서에 글자로 적혀 있어요.
문제는 그 조건을 인용할 때 대부분 BIP-125의 다섯 줄을 가져온다는 점이에요. 그런데 BIP-125 본문은 그 다섯 줄을 소개하면서 "The initial implementation expected in Bitcoin Core 0.12.0 uses the following rules"라고 적어 두었어요. 초기 구현의 규칙이라고 규격이 스스로 밝힌 거예요. 실제로 오늘 Bitcoin Core 저장소의 정책 문서를 열면 번호는 6번까지 있는데 1번과 2번 자리에는 (Removed)라는 한 단어만 남아 있고, 살아 있는 조건은 네 개예요.
이 글은 수수료가 무엇에 붙는지를 다루지 않아요. 그 축은 비트코인 송금 수수료가 거래 크기에 붙는 구조에 따로 정리해 두었어요. 여기서는 오직 대체 거래가 받아들여지는 조건만 두 문서의 원문으로 대조해요. 수수료도 "규칙 3·4가 요구하는 절대 수수료 증가"라는 조건으로만 나와요.
먼저 못 박아 둘 것이 하나 있어요. 대체는 되돌리기가 아니에요. 이미 상대에게 도착한 값을 회수하는 절차가 아니라, 아직 확정되지 않은 거래를 같은 재료로 만든 다른 거래로 바꿔치우는 절차예요.
취소가 아니라 대체예요 — 같은 입력을 쓰는 새 거래
Bitcoin Core 저장소의 doc/policy/mempool-replacements.md는 첫 문단부터 무엇이 무엇과 충돌하는지를 정의해요. 원문을 그대로 옮기면 이래요.
A transaction conflicts with an in-mempool transaction ("directly conflicting transaction") if they spend one or more of the same inputs. A transaction may conflict with multiple in-mempool transactions.
A transaction ("replacement transaction") may replace its directly conflicting transactions and their in-mempool descendants (together, "original transactions") if, in addition to passing all other consensus and policy rules, each of the following conditions are met:
여기 나오는 낱말을 먼저 정리할게요.
| 낱말 | 이 글에서 쓰는 뜻 |
|---|---|
| 입력(input) | 이 거래가 재료로 쓰는, 앞선 거래가 남긴 잔액 조각 |
| 멤풀(mempool) | 아직 블록에 실리지 않은 거래가 노드마다 들고 대기하는 자리 |
| 확인(confirmation) | 거래가 블록에 실린 상태. 확인이 붙으면 멤풀에서 빠져요 |
| 원거래(original transaction) | 대체당하는 쪽. 직접 충돌하는 거래와 그 멤풀 자손을 묶은 말 |
| 대체 거래(replacement transaction) | 같은 입력을 쓰면서 새로 밀어 넣는 거래 |
정의를 읽으면 "취소"라는 낱말이 어디에도 없다는 게 눈에 들어와요. 문서가 말하는 동작은 replace, 곧 바꿔 놓기예요. 취소처럼 보이는 결과는 이렇게 만들어져요. 대체 거래의 출력을 원래 받는 사람 대신 내 다른 주소로 잡으면, 원거래가 밀려나면서 값이 나가지 않은 것처럼 보여요. 하지만 네트워크가 한 일은 "취소"가 아니라 "같은 재료로 만든 다른 거래를 채택"한 거예요.
| 흔히 도는 말 | 두 문서가 적어 둔 것 |
|---|---|
| 보낸 비트코인을 취소하는 기능이 있다 | 문서에 있는 동작은 대체예요. 같은 입력을 쓰는 새 거래가 원거래를 밀어내요 |
| 취소하면 상대에게 간 코인이 돌아온다 | 대체 대상은 아직 확인되지 않은 거래예요. 확정된 값을 회수하는 절차가 아니에요 |
| 수수료만 더 내면 언제든 바꿀 수 있다 | 정책 문서는 조건을 번호로 적어 두었어요. 절대 수수료 증가는 그중 두 줄이에요 |
| 내가 조건을 맞추면 반드시 받아들여진다 | 문서의 표현은 "may replace"예요. 받아들일지는 각 노드의 정책이에요 |
마지막 줄이 중요해요. 원문은 "must replace"가 아니라 may replace라고 적었어요. 조건을 채우는 것은 필요조건이고, 실제로 어느 노드가 받아 주고 어느 채굴자가 실어 줄지는 그 노드와 채굴자의 소프트웨어·설정에 달려 있어요.
BIP-125가 적어 둔 다섯 조건
BIP-125 원문의 머리표에는 제목이 Opt-in Full Replace-by-Fee Signaling, Layer는 Applications, Type은 Specification, Status는 Deployed, Assigned는 2015-12-04로 적혀 있어요. 저자는 David A. Harding과 Peter Todd예요. 제목에 Signaling이 들어가 있다는 점을 기억해 두세요. 뒤에서 이 낱말이 갈림길이 돼요.
초록은 왜 이 정책이 필요했는지를 이렇게 적어요.
Many nodes today will not replace any transaction in their mempool with another transaction that spends the same inputs, making it difficult for spenders to adjust their previously-sent transactions to deal with unexpected confirmation delays or to perform other useful replacements.
같은 문서의 Summary 절은 대체 가능하다는 신호를 켜는 방법을 두 가지로 나눠요.
Explicit signaling: A transaction is considered to have opted in to allowing replacement of itself if any of its inputs have an nSequence number less than (0xffffffff - 1).
Inherited signaling: Transactions that don't explicitly signal replaceability are replaceable under this policy for as long as any one of their ancestors signals replaceability and remains unconfirmed.
원문은 위키 문법으로 두 소제목에 굵은 표시가 붙어 있는데, 여기서는 표시만 걷어 내고 문장을 그대로 옮겼어요.
명시 신호는 입력에 붙는 nSequence 값을 (0xffffffff - 1)보다 작게 잡는 방식이고, 상속 신호는 신호를 켠 조상 거래가 아직 확인되지 않은 동안 그 자손도 대체 가능해지는 방식이에요.
그리고 문제의 다섯 줄이 나와요. 그 앞에 붙은 문장까지 같이 옮길게요.
The initial implementation expected in Bitcoin Core 0.12.0 uses the following rules:
즉 규격 문서 스스로 이 다섯 줄을 0.12.0에서 예상되는 초기 구현의 규칙이라고 소개해요. "영구히 유효한 현행 규칙"이라고 적지 않았어요. 게다가 동사가 "expected", 곧 예상이에요. 이 낱말도 뒤에서 걸려요. 아래 1번의 상속 신호 부분을 두고, 나중에 볼 Bitcoin Core 정책 문서의 History가 이 예상과 다르게 적어 두거든요. 다섯 줄을 원문과 함께 옮기면 이래요.
| 번호 | BIP-125 원문 | 우리말 요지 |
|---|---|---|
| 1 | "The original transactions signal replaceability explicitly or through inheritance as described in the above Summary section." | 원거래가 명시 신호나 상속 신호로 대체 가능하다고 밝혀 두었을 것 |
| 2 | "The replacement transaction may only include an unconfirmed input if that input was included in one of the original transactions." | 대체 거래는 원거래에 들어 있던 것이 아닌 미확인 입력을 새로 끌어오지 말 것 |
| 3 | "The replacement transaction pays an absolute fee of at least the sum paid by the original transactions." | 대체 거래가 내는 절대 수수료가 원거래들이 낸 합 이상일 것 |
| 4 | "The replacement transaction must also pay for its own bandwidth at or above the rate set by the node's minimum relay fee setting." | 자기 대역폭 값을 노드의 최소 중계 수수료 기준 이상으로 낼 것 |
| 5 | "The number of original transactions to be replaced and their descendant transactions which will be evicted from the mempool must not exceed a total of 100 transactions." | 밀려날 원거래와 그 자손을 합쳐 100건을 넘지 말 것 |
bitcoin/bips 저장소의 bip-0125.mediawiki 원문(9,569바이트)을 직접 내려받아 옮긴 값이에요.
4번에는 예시까지 붙어 있어요. 원문은 "if the minimum relay fee is 1 satoshi/byte and the replacement transaction is 500 bytes total, then the replacement must pay a fee at least 500 satoshis higher than the sum of the originals"예요. 500바이트짜리를 밀어 넣으려면 원거래 합보다 최소 500 사토시를 더 내라는 뜻이에요. 이 숫자가 뒤에서 바뀌어요.
투자 정보 안내
본 글은 암호화폐 시장에 대한 객관 데이터·정보 제공 목적이며, 특정 코인 매수·매도 권유가 아닙니다. 암호화폐는 변동성이 매우 크고 원금 전액 손실이 가능하므로 본인 판단과 책임 하에 결정하세요.
구현 문서가 지금 적용하는 네 규칙과 지워진 두 줄
이제 Bitcoin Core 저장소의 doc/policy/mempool-replacements.md를 열어요. 문서 제목은 Mempool Replacements이고 첫 절 제목이 Current Replace-by-Fee Policy예요. 조건 목록에 번호는 1번부터 6번까지 붙어 있어요. 그런데 앞의 두 줄은 이래요.
- (Removed)
- (Removed)
한 단어짜리 줄이에요. 그러니까 번호는 여섯 개지만 조건은 네 개예요. 번호를 다시 매기지 않고 자리만 비워 둔 이유는 뒤이은 규칙들이 3·4·5·6이라는 이름으로 코드와 토론에서 계속 불려 왔기 때문으로 읽히지만, 그 이유가 문서에 적혀 있지는 않아요. 확인되는 것은 자리가 비었다는 사실까지예요.
살아 있는 네 규칙의 원문은 이래요.
| 번호 | 현행 정책 문서 원문 | 우리말 요지 |
|---|---|---|
| 3 | "The replacement transaction pays an absolute fee of at least the sum paid by the original transactions." | 절대 수수료가 원거래들이 낸 합 이상일 것 |
| 4 | "The additional fees (difference between absolute fee paid by the replacement transaction and the sum paid by the original transactions) pays for the replacement transaction's bandwidth at or above the rate set by the node's incremental relay feerate." | 늘어난 수수료가 대체 거래의 대역폭 값을 증분 중계 수수료율 이상으로 감당할 것 |
| 5 | "The number of distinct clusters corresponding to conflicting transactions does not exceed 100." | 충돌 거래에 대응하는 서로 다른 클러스터 수가 100을 넘지 않을 것 |
| 6 | "The feerate diagram of the mempool must be strictly improved by the replacement transaction." | 대체 거래가 멤풀의 수수료율 도표를 엄격히 개선할 것 |
bitcoin/bitcoin 저장소 master 브랜치의 doc/policy/mempool-replacements.md 원문(3,623바이트)이에요.
각 규칙에는 Rationale 문단이 붙어 있어요. 왜 그렇게 정했는지를 문서가 직접 설명해 둔 자리예요. 규칙 3의 근거는 "Only requiring the replacement transaction to have a higher feerate could allow an attacker to bypass node minimum relay feerate requirements and cause the network to repeatedly relay slightly smaller replacement transactions without adding any more fees"예요. 수수료율만 높이라고 하면 크기를 조금씩 줄인 거래를 반복해서 흘려보내는 길이 열린다는 뜻이에요. 규칙 4의 근거는 "Try to prevent DoS attacks where an attacker causes the network to repeatedly relay transactions each paying a tiny additional amount in fees, e.g. just 1 satoshi"이고, 규칙 5의 근거는 "Limit CPU usage required to update the mempool for so many transactions being removed at once"예요. 규칙 6의 근거는 "This ensures that block fees in all future blocks will go up after the replacement (ignoring tail effects at the end of a block)"예요.
두 문서를 줄 단위로 겹쳐 놓으면 무엇이 바뀌었는지가 선명해져요.
| BIP-125 | 현행 정책 문서 | 무엇이 달라졌나 |
|---|---|---|
| 1번 신호 요구 | 1. (Removed) | 조건 자체가 사라졌어요 |
| 2번 미확인 입력 제한 | 2. (Removed) | 조건 자체가 사라졌어요 |
| 3번 절대 수수료 합 이상 | 규칙 3 | 문장이 사실상 그대로예요 |
| 4번 최소 중계 수수료 기준 | 규칙 4 | 기준이 최소 중계 수수료에서 증분 중계 수수료율로 바뀌었고, 재는 대상이 "대체 거래 전체 수수료"에서 "늘어난 수수료 몫"으로 바뀌었어요 |
| 5번 밀려나는 거래 100건 | 규칙 5 | 세는 대상이 거래 100건에서 서로 다른 클러스터 100개로 바뀌었어요 |
| 없음 | 규칙 6 | 수수료율 도표를 엄격히 개선하라는 규칙이 새로 생겼어요 |
4번의 변화는 예시 숫자로 보면 바로 잡혀요. 현행 문서의 예시는 "if the incremental relay feerate is 0.1 satoshi/vB and the replacement transaction is 500 virtual bytes total, then the replacement pays a fee at least 50 satoshis higher than the sum of the original transactions"예요. BIP-125가 500바이트에 500 사토시를 더 내라고 적었던 자리에, 현행 문서는 500 가상 바이트에 50 사토시를 더 내라고 적어요. 기준으로 삼는 수수료율의 이름과 값이 달라졌기 때문이에요.
5번의 변화는 성격이 더 커요. BIP-125는 밀려날 거래의 개수를 셌는데, 현행 문서는 충돌 거래에 대응하는 클러스터의 개수를 세요. 클러스터가 무엇을 묶은 단위인지는 이 정책 문서 본문에 정의돼 있지 않고, 문서 끝의 이력에 "Feerate diagram policy enabled in conjunction with switch to cluster mempool as of v31.0"이라고 적힌 줄이 있을 뿐이에요. 낱말 풀이는 다른 문서에 한 번 나와요. Bitcoin Core 28.0 릴리스 노트가 제한적 패키지 대체를 설명하면서 "a connected component, aka cluster"라고 적어요. 멤풀 안에서 서로 이어져 한 덩어리가 된 것을 클러스터라 부른다는 뜻이에요. 다만 그 줄은 규칙 5를 설명하는 자리가 아니라 크기 2짜리 덩어리를 다루는 자리이고, 규칙 5가 세는 클러스터가 v31.0의 클러스터 멤풀에서 어디까지를 한 덩어리로 잡는지는 그 문장 하나로 확정되지 않아요. 그래서 이 글은 "세는 단위가 거래에서 클러스터로 바뀌었다"까지만 말할 수 있어요.
문서 아래쪽 History 절에는 아홉 줄이 붙어 있어요. 이 아홉 줄이 규격과 구현이 갈라져 온 경로예요.
| 이력 | 내용 |
|---|---|
| v0.12.0 | 옵트인 방식의 전면 대체가 상속 신호는 빼고 멤풀과 채굴에서 받아들여짐 |
| BIP-125 | Bitcoin Core 구현을 바탕으로 정의됨 |
| PR #9380 | 증분 중계 수수료율이 -minrelaytxfee와 구분되고 -incrementalrelayfee로 설정 가능해짐 |
| v0.18.1 | 지갑 GUI에서 대체 기능이 기본으로 켜짐 |
| v24.0 | 전면 대체가 설정 가능한 멤풀 정책으로 들어옴 |
| v28.0 | 전면 대체가 기본 정책이 됨 |
| PR 30592 | 대체를 위한 신호 요구가 더 이상 필요하지 않게 됨 |
| PR #33106 | 증분 중계 수수료율 기본값이 1 가상 바이트당 0.1 사토시 |
| v31.0 | 클러스터 멤풀 전환과 함께 수수료율 도표 정책이 켜짐 |
같은 문서의 History 절 아홉 줄을 순서대로 옮긴 표예요.
첫 줄에 붙은 괄호를 그냥 넘기면 안 돼요. 원문은 "Opt-in full replace-by-fee (without inherited signaling) honoured in mempool and mining as of v0.12.0"이에요. 앞에서 옮긴 BIP-125 1번은 원거래가 "명시 신호나 상속(inheritance)"으로 대체 가능함을 밝히면 된다고 적었는데, 같은 0.12.0을 되짚는 이 줄은 상속 신호를 뺀 형태로 적어요. 규격이 "0.12.0에서 예상되는" 규칙이라며 다섯 줄을 내놓은 그 자리에서, 구현 쪽 기록은 1번의 절반을 빼고 적은 셈이에요. 규격과 구현이 갈라진 자리 중 가장 이른 것이 여기예요. 다만 이 글이 확인한 것은 두 문서가 서로 다르게 적어 두었다는 사실까지이고, 그 시절 코드가 실제로 어떻게 동작했는지는 이번에 연 문서로 확정하지 않았어요.
두 번째 줄이 눈에 띄어요. 문서는 "BIP125 defined based on Bitcoin Core implementation"이라고 적어요. 규격이 먼저 있고 구현이 따라간 것이 아니라, 구현을 근거로 규격이 쓰였다고 스스로 밝히는 거예요. 그러면 구현이 앞으로 나갔을 때 규격 문서가 뒤에 남는 일도 자연스러워요.
신호를 켜지 않아도 대체될 수 있게 된 기본값
BIP-125의 제목은 Opt-in Full Replace-by-Fee Signaling이에요. 이름에 들어 있는 두 낱말이 그 정책의 전제였어요. 보내는 쪽이 "나는 나중에 이 거래를 바꿀 수 있게 해 두겠다"고 신호를 켠 거래만 대체 대상이 된다는 전제요. 초록도 그 전제 위에서 받는 쪽의 선택을 이렇게 적어요.
Nodes and recipients may continue to treat transactions without the signal the same way they treated them before, preserving the existing status quo.
그런데 현행 정책 문서의 History에는 이렇게 적혀 있어요.
Signaling for replace-by-fee is no longer required as of [PR 30592].
같은 절의 바로 위 줄은 "Full replace-by-fee is the default policy as of v28.0"이에요. 그리고 Bitcoin Core 28.0 릴리스 노트의 Mempool Policy Changes 절에는 그 변경이 설정값 단위로 적혀 있어요.
The default value of the
-mempoolfullrbfconfiguration option has been changed from 0 to 1, i.e.mempoolfullrbf=1.
여기서 두 가지를 갈라 둘게요.
첫째, 이 값은 Bitcoin Core의 기본값이에요. 릴리스 노트가 말하는 것은 그 소프트웨어의 설정 기본값이지 "네트워크의 모든 노드가 항상 그렇게 동작한다"가 아니에요. 노드는 저마다 다른 소프트웨어와 다른 버전, 다른 설정으로 돌아가요. 그래서 이 글은 "Bitcoin Core의 기본 정책이 그렇다"까지만 말해요.
둘째, 이 옵션 이름의 현재 상태는 이 글에서 확정하지 못했어요. 확인한 범위를 밝혀 둘게요. bitcoin/bitcoin 저장소 master 브랜치의 src/init.cpp(134,307바이트)를 내려받아 문자열로 찾았을 때 mempoolfullrbf는 나오지 않았어요. 다만 이 파일 하나를 본 것이라, 그 옵션이 어느 버전에서 어떻게 정리됐는지까지는 이번에 확정하지 못했어요.
실무로 옮기면 함의는 이렇게 갈려요.
| 층위 | BIP-125 시절 전제 | 현행 정책 문서가 적은 것 |
|---|---|---|
| 대체 대상이 되는 거래 | 신호를 켠 거래와 그 자손 | 신호 요구가 없어졌다고 적혀 있어요 |
| 받는 쪽의 판단 기준 | 신호가 없으면 종전대로 취급 | 신호 유무만으로 안심할 근거가 약해졌어요 |
| 보내는 쪽의 기대 | 신호를 껐으면 못 바꾼다 | 껐다는 이유만으로 못 바꾼다고 단정할 수 없어요 |
받는 쪽에서 특히 그래요. 예전에는 "이 거래에 신호가 켜져 있는가"를 보고 미확인 상태의 위험을 가늠하는 방식이 통했는데, 신호 요구가 사라진 정책에서는 그 판단 재료가 줄어들어요. 그래서 BIP-125 자신이 받는 쪽 지침으로 적어 둔 두 가지 중 두 번째 쪽이 더 단순한 기준으로 남아요. 원문은 "Ignoring the opt-in transaction until it has been confirmed"예요.
확인이 한 번 붙으면 이 문이 닫혀요
지금까지 인용한 조건은 전부 멤풀 안의 거래에 관한 거예요. 정책 문서의 첫 문장이 "conflicts with an in-mempool transaction"이고, 밀려나는 대상도 "their in-mempool descendants"예요. 멤풀은 아직 블록에 실리지 않은 거래가 머무는 자리이므로, 확인이 붙어 멤풀에서 빠진 거래는 이 문서가 다루는 대상이 아니게 돼요.
BIP-125도 같은 경계를 문서 여러 자리에서 반복해요. 대표적인 세 곳만 옮기면 이래요.
The recipient or recipients of a transaction containing this signal may choose not to treat it as payment until it has been confirmed, eliminating the risk that the spender will use allowed replacements to defraud them.
받는 쪽이 확인될 때까지 지급으로 취급하지 않으면 대체를 이용한 사기 위험이 사라진다고 적어요. 상속 신호 정의에도 같은 경계가 들어 있어요. "for as long as any one of their ancestors signals replaceability and remains unconfirmed"라고 적었죠. 받는 쪽 지갑 지침에서도 "Ignoring the opt-in transaction until it has been confirmed"라고 적어요. 세 자리 모두 기준선이 확인이에요. 여기 옮기지 않은 자리도 더 있어요. 받는 쪽 지침 끝은 처리 방식을 자손 거래까지 물려주라면서 "for as long as any ancestor opt-in full-RBF transactions remain unconfirmed"라고 적고, 보내는 쪽 지침은 신호가 켜진 미확인 거래를 함부로 쓰지 말라고 적어요.
| 거래 상태 | 이 두 문서가 다루는가 | 무엇이 가능한가 |
|---|---|---|
| 서명 전 | 아니요 | 아직 네트워크에 나가지 않았어요 |
| 멤풀 대기(미확인) | 예 | 네 규칙을 채우는 대체 거래가 원거래를 밀어낼 수 있어요 |
| 확인 1회 이상 | 아니요 | 멤풀 대체 정책의 대상이 아니에요 |
확인이 붙은 뒤에 무엇이 가능하고 무엇이 불가능한지는 이 두 문서가 다루는 범위 밖이라, 이 글은 그 부분을 단정하지 않아요. 여기서 말할 수 있는 것은 멤풀 대체라는 문은 확인과 함께 닫힌다는 사실까지예요.
그래서 "내 거래를 취소할 수 있나요"라는 질문은 그대로는 답이 안 나와요. 답이 나오는 형태로 바꾸면 이래요. 지금 이 거래에 확인이 몇 번 붙었나요. 확인 수를 어디서 어떻게 확인하는지는 코인 입금이 처리 중일 때 컨펌 수를 확인하는 방법에 따로 적어 두었어요. 그 글은 확인 수를 세는 절차를 다루고, 이 글은 그 수가 0일 때 열려 있는 조건을 다뤄요.
다른 체인은 같은 문제를 다른 재료로 풀어요. 이더리움 계열은 계정마다 붙는 번호를 덮어쓰는 방식이라 대기 중인 거래를 처리하는 절차가 아예 달라요. 그 갈래는 코인 전송이 대기 상태에서 안 넘어갈 때의 처리에 정리해 두었어요. 이 글에서 인용한 두 문서는 비트코인 쪽 문서라 그 체인에는 적용되지 않아요.
거래소에서 나간 출금은 내가 대체할 수 없어요
여기가 검색 의도와 실제 구조가 가장 크게 어긋나는 자리예요. "비트코인 출금 취소"를 찾는 분 대부분은 거래소 출금 화면에서 버튼을 누른 뒤예요. 그런데 앞에서 본 정의를 그대로 적용하면 결론이 바로 나와요.
대체 거래는 같은 입력을 쓰는 새 거래예요. 어떤 입력을 쓰려면 그 입력에 걸린 잠금을 풀 수 있어야 하고, 그 열쇠를 쥔 쪽만 서명할 수 있어요. 거래소 출금은 거래소가 관리하는 지갑의 출력을 입력으로 써요. 그러니 이용자에게는 애초에 그 입력으로 새 거래를 만들 방법이 없어요. 조건 네 개를 다 아는 것과 무관한, 그보다 앞선 층의 문제예요.
| 상황 | 입력에 서명할 수 있는 쪽 | 이용자가 대체 거래를 만들 수 있나 |
|---|---|---|
| 내가 직접 관리하는 지갑에서 보냄 | 나 | 만들 수 있어요. 네 규칙을 채우는지가 남아요 |
| 거래소 출금 화면에서 보냄 | 거래소 | 만들 수 없어요. 서명 권한이 없어요 |
그러면 이용자에게 남는 길은 거래소 창구뿐인데, 각 거래소가 이미 나간 출금에 대해 대체나 취소를 지원하는지는 이번에 공식 안내를 열어 확인하지 못했어요. 그래서 이 글은 "구조상 이용자가 직접 대체 거래에 서명할 수 없다"까지만 적고, 특정 거래소가 무엇을 해 주는지 여부는 단정하지 않아요. 이용자가 자기 열쇠를 쥐는 방식과 거래소에 맡기는 방식이 어떻게 갈리는지는 거래소 보관과 자가수탁 지갑 비교에 따로 정리해 두었어요.
투자 정보 안내
본 글은 암호화폐 시장에 대한 객관 데이터·정보 제공 목적이며, 특정 코인 매수·매도 권유가 아닙니다. 암호화폐는 변동성이 매우 크고 원금 전액 손실이 가능하므로 본인 판단과 책임 하에 결정하세요.
조건을 다 채워도 남는 것 — may replace의 뜻
네 규칙을 전부 채운 대체 거래를 만들었다고 해서 결과가 정해지는 것은 아니에요. 근거는 문서 안에 있어요.
첫째, 정책 문서의 조건 앞에는 "in addition to passing all other consensus and policy rules"라는 단서가 붙어 있어요. 이 네 규칙은 대체에 관한 조건이고, 그 밖의 합의 규칙과 정책 규칙은 따로 통과해야 해요.
둘째, 동사가 may예요. 규격 쪽도 마찬가지여서, BIP-125 초록은 "Nodes may allow transactions containing this signal to be replaced in their mempools"라고 적어요.
셋째, BIP-125의 Deployment 절은 실제 대체가 불확실할 수 있다고 적고 그 조건을 두 가지로 나눠요. 원문은 "Actual replacement may be unreliable until two conditions have been satisfied"이고, 이어지는 두 줄은 대체가 채굴자에게 닿을 중계 경로가 충분한지와, 대체를 지원하는 해시레이트가 충분한지예요. 2015년 문서의 서술이라 오늘의 상태를 그대로 말하지는 않지만, 조건 충족과 결과가 별개라는 구조 자체는 그대로예요.
넷째, 규칙 6은 멤풀의 수수료율 도표를 엄격히 개선하라고 요구해요. 원문의 낱말은 "strictly improved"예요. 조건이 개수나 문턱값이 아니라 도표 전체의 비교라서, 같은 수수료를 더 내더라도 상황에 따라 판정이 달라질 여지가 남아요. 이 도표가 정확히 어떻게 계산되는지는 이 문서에 정의돼 있지 않아요.
오해와 원문을 한 표로
| 흔히 도는 말 | 원문으로 확인된 것 |
|---|---|
| BIP-125의 다섯 조건이 현행 규칙이다 | BIP-125는 그 다섯 줄을 "The initial implementation expected in Bitcoin Core 0.12.0 uses the following rules"라고 소개해요 |
| 조건은 다섯 개다 | 현행 정책 문서에서 1번과 2번은 (Removed)이고 살아 있는 조건은 네 개(3·4·5·6)예요 |
| 신호를 켜지 않으면 절대 못 바꾼다 | 현행 문서 History에 "Signaling for replace-by-fee is no longer required as of [PR 30592]"라고 적혀 있어요 |
| 밀려나는 거래가 100건까지 허용된다 | 현행 규칙 5는 "The number of distinct clusters corresponding to conflicting transactions does not exceed 100"이에요. 세는 단위가 클러스터로 바뀌었어요 |
| 수수료율만 올리면 된다 | 규칙 3은 절대 수수료의 합 이상을 요구하고, 규칙 4는 늘어난 수수료가 대역폭 값을 감당하라고 요구해요 |
| 대체는 취소다 | 문서의 동작은 replace예요. 같은 입력을 쓰는 새 거래가 원거래를 밀어내요 |
| 확인이 붙어도 바꿀 수 있다 | 두 문서가 다루는 대상은 멤풀 안의 거래예요. 확인된 거래는 이 정책의 대상이 아니에요 |
| 거래소 출금도 내가 취소할 수 있다 | 대체 거래는 같은 입력에 서명해야 성립해요. 거래소 지갑의 출력에는 이용자가 서명할 수 없어요 |
이 글에서 확인하지 못한 것
범위를 밝혀 둘게요. 아래는 이번에 확정하지 못한 항목이에요.
- 규칙 5가 세는 클러스터의 범위. "distinct clusters"의 정의는 이 정책 문서 본문에 없어요. 28.0 릴리스 노트가 다른 맥락에서 클러스터를 "a connected component, aka cluster"로 풀어 쓴 줄이 하나 있고, 정책 문서 History에는 클러스터 멤풀 전환이 v31.0이라고 적혀 있어요. 이 두 줄로 규칙 5가 한 덩어리로 묶는 경계까지는 확정하지 못했어요.
- 수수료율 도표의 계산 방식. 규칙 6의 "feerate diagram"이 어떤 절차로 만들어지고 무엇을 비교해 "strictly improved"를 판정하는지는 이 문서에 없어요.
-mempoolfullrbf옵션의 현재 상태. master 브랜치의src/init.cpp한 파일에서 이 문자열을 찾지 못했다는 것까지가 이번에 확인한 범위예요. 어느 버전에서 어떻게 정리됐는지는 확정하지 못했어요.- 네트워크 전체의 실제 동작. 인용한 문서는 Bitcoin Core의 정책과 BIP 규격이에요. 다른 노드 소프트웨어나 다른 설정으로 도는 노드가 얼마나 되는지는 이 문서들로 알 수 없어요.
- 국내 거래소의 출금 대체·취소 정책. 업비트·빗썸·코인원의 공식 안내를 이번에 열지 못했어요. 그래서 개별 거래소가 무엇을 지원하는지는 적지 않았어요.
- 버전별 발효 시점. 인용한 v28.0·v31.0 같은 표기는 문서에 적힌 버전 이름이에요. 이번에 연 문서에서 시기를 적은 자리는 BIP-125의 Deployment 절 한 곳뿐인데, 거기서도 0.12.0에 대해 "(release expected Jan/Feb 2016)"이라고 예상 시기를 월 단위로 적었을 뿐이에요. 실제 배포 일자는 어느 버전에 대해서도 이번에 연 문서들에 없었어요.
자주 묻는 질문 (FAQ)
Q. 지금 보낸 비트코인을 취소할 수 있나요?
확인이 아직 0회이고, 그 거래의 입력에 내가 직접 서명할 수 있는 지갑에서 보냈다면 같은 입력을 쓰는 대체 거래를 만들 여지가 있어요. 확인이 한 번이라도 붙었다면 그 거래는 멤풀에서 빠진 상태라 이 정책의 대상이 아니에요. 거래소 출금 화면에서 보낸 경우라면 입력에 서명할 권한이 이용자에게 없어서 대체 거래를 만들 수 없어요. 세 갈래 중 어디에 있는지부터 확인하는 게 순서예요.
Q. 조건이 다섯 개라고 들었는데 네 개가 맞나요?
두 문서가 다른 것을 적고 있어요. BIP-125의 Implementation Details 절에는 다섯 줄이 있고, 그 앞 문장이 "Bitcoin Core 0.12.0에서 예상되는 초기 구현"이라고 밝혀요. Bitcoin Core master의 doc/policy/mempool-replacements.md에는 번호가 6번까지 있지만 1번과 2번이 (Removed)라서 살아 있는 조건은 네 개예요. "현행 규칙"을 물었다면 네 개, "BIP-125가 적어 둔 것"을 물었다면 다섯 개예요.
Q. 대체 거래를 밀어 넣으면 원래 받는 사람에게 간 코인이 돌아오나요?
대체는 아직 확인되지 않은 거래를 다른 거래로 바꿔치우는 절차예요. 확정된 값을 회수하는 절차가 아니에요. 대체 거래의 출력을 내 다른 주소로 잡으면 결과적으로 값이 나가지 않은 것처럼 보이지만, 그 시점의 원거래는 애초에 확정되지 않은 상태였어요. 받는 쪽이 확인을 기다린 뒤에 지급으로 인정했다면 이 절차가 개입할 자리가 없어요.
Q. 수수료를 더 내면 무조건 대체되나요?
아니에요. 규칙 3은 대체 거래의 절대 수수료가 원거래들이 낸 합 이상일 것을 요구하고, 규칙 4는 늘어난 수수료가 대체 거래의 대역폭 값을 증분 중계 수수료율 이상으로 감당할 것을 요구해요. 두 조건을 채워도 규칙 5·6이 남고, 문서의 동사는 "may replace"예요. 노드가 받아 줄지, 채굴자가 실어 줄지는 각자의 소프트웨어와 설정에 달려 있어요.
Q. 지갑에서 대체 신호를 꺼 두면 안전한가요?
신호를 끄는 방법 자체는 BIP-125에 적혀 있어요. 다만 두 값이 나란한 선택지는 아니에요. 원문은 신호를 켜고 싶지 않은 지갑이라면 nSequence를 최대값 0xffffffff로 두라고 적고, (0xffffffff-1)은 "when they also want to use locktime", 곧 락타임도 함께 쓰고 싶을 때의 값으로 적어요. 뒤쪽에만 조건절이 붙어 있어요. 그리고 현행 정책 문서는 "Signaling for replace-by-fee is no longer required as of [PR 30592]"라고 적어요. 그래서 Bitcoin Core의 기본 정책 아래에서는 신호를 껐다는 사실만으로 대체가 불가능하다고 단정할 근거가 약해졌어요. 받는 쪽이라면 신호 유무보다 확인 여부를 기준으로 삼는 편이 문서에 적힌 판단 기준에 가까워요.
Q. 밀려나는 거래가 100건을 넘으면 안 된다는 말은 여전히 맞나요?
BIP-125 기준으로는 맞고, 현행 정책 문서 기준으로는 세는 대상이 달라요. BIP-125 5번은 밀려날 원거래와 그 자손을 합쳐 100건을 넘지 말라고 적었고, 현행 규칙 5는 "충돌 거래에 대응하는 서로 다른 클러스터 수가 100을 넘지 않을 것"이라고 적어요. 숫자 100은 같지만 세는 단위가 거래에서 클러스터로 바뀌었어요. 클러스터의 정의는 이 문서 본문에 없어요.
Q. 대체가 아예 안 되는 지갑도 있나요?
이 글이 연 두 문서로는 개별 지갑 제품의 지원 여부를 알 수 없어요. 확인되는 것은 Bitcoin Core 쪽 이력뿐이에요. 정책 문서 History에 "RBF enabled by default in the wallet GUI as of v0.18.1"이라는 줄이 있어요. 다른 제품이 이 기능을 화면에 내놓는지, 어떤 이름으로 부르는지는 각 제품 문서를 따로 열어야 해요.
Q. 이 글의 내용이 앞으로도 그대로인가요?
정책 문서 자체가 계속 고쳐지고 있어요. 그 증거가 문서 안의 History 아홉 줄이에요. 조건 1·2번이 지워지고 규칙 6이 새로 붙은 것도 그 과정에서 일어난 일이에요. 그래서 조건의 개수나 문구를 외우기보다, doc/policy/mempool-replacements.md라는 원문의 자리를 기억해 두고 필요할 때 그 문서를 여는 편이 오래가요.
정리
- 비트코인에서 일어나는 동작은 취소가 아니라 대체예요. 정책 문서의 정의는 같은 입력을 쓰는 새 거래가 원거래를 밀어내는 구조예요.
- 흔히 인용되는 BIP-125의 다섯 조건은 그 문서 스스로 "Bitcoin Core 0.12.0에서 예상되는 초기 구현의 규칙"이라고 소개해요.
- Bitcoin Core 현행 정책 문서에서 1번과 2번은
(Removed)이고, 살아 있는 조건은 네 개, 곧 3·4·5·6번이에요. - 바뀐 대목은 세 가지예요. 4번의 기준이 증분 중계 수수료율로 옮겨 갔고, 5번이 세는 단위가 클러스터로 바뀌었고, 규칙 6이 새로 생겼어요.
- 신호 요구는 없어졌어요. 문서에 "Signaling for replace-by-fee is no longer required as of [PR 30592]"라고 적혀 있어요. 다만 이 서술의 범위는 Bitcoin Core의 정책이에요.
- 이 문이 닫히는 기준선은 확인이에요. 두 문서가 다루는 대상은 전부 멤풀 안의 미확인 거래예요.
- 거래소 출금은 구조가 달라요. 대체 거래는 같은 입력에 서명해야 성립하는데, 그 열쇠를 이용자가 쥐고 있지 않아요.
"보내면 절대 못 바꾼다"도, "언제든 취소할 수 있다"도 정확한 문장이 아니에요. 정확한 문장은 조건절을 달고 있어요. 확인이 붙기 전이고, 입력에 내가 서명할 수 있고, 네 규칙을 채우는 대체 거래를 만들었고, 그것을 받아 준 노드와 채굴자가 있을 때 원거래가 밀려나요. 조건이 넷이 아니라 그 앞뒤로 더 붙는다는 점이 이 주제의 실제 모습이에요.
이 글은 BIP 규격 원문과 Bitcoin Core 저장소의 문서를 직접 열어 정리한 정보 제공 글이며 매매를 권유하는 글이 아니에요. 특정 절차를 실행하라거나 하지 말라는 뜻으로 읽지 말아 주세요. 가상자산은 변동성이 크고 원금 손실 위험이 있으며, 거래와 보유의 판단과 책임은 본인에게 있어요.
확인한 자료: bitcoin/bips 저장소의 bip-0125.mediawiki 원문(9,569바이트), bitcoin/bitcoin 저장소 master 브랜치의 doc/policy/mempool-replacements.md 원문(3,623바이트)과 doc/release-notes/release-notes-28.0.md 원문(14,573바이트), 같은 브랜치의 src/init.cpp(134,307바이트). 모두 2026년 8월 16일에 원문 파일을 직접 내려받아 확인했어요.