channel_reserve_satoshis는 상대방이 커밋먼트 거래에서 늘 남겨 두라고 요구하는 최소 잔액이고, dust_limit_satoshis는 그 커밋먼트 거래의 출력과 HTLC를 잘라낼지 정하는 기준입니다. 두 값은 같은 제한이 아닙니다. 실제로 보낼 수 있는 금액은 로컬 잔액에서 상대가 요구한 예비금(reserve), 내가 부담할 커밋먼트 수수료, 진행 중인 HTLC, 구현이 두는 안전 여유를 뺀 값으로 봐야 합니다. HTLC가 체인 위 출력으로 남는지는 방향별 더스트 한도에 타임아웃 또는 성공 수수료를 더한 BOLT 3 임계값으로 판단합니다.
예비금과 더스트 한도는 서로 다른 제한입니다
BOLT 2에서 채널을 제안하는 쪽은 dust_limit_satoshis와 channel_reserve_satoshis를 함께 보냅니다. 앞의 값은 자기가 들고 있는 커밋먼트 거래에 너무 작은 출력이 생기지 않게 막는 기준이고, 뒤의 값은 상대가 그 커밋먼트에서 지켜야 할 최소 잔액입니다. 그래서 예비금을 비트코인 네트워크의 더스트 정책과 같은 값으로 취급하면 잔액 계산이 어긋납니다.
각 참여자는 상대가 정한 예비금을 지켜야 합니다. 채널 방향에 따라 들여다보는 커밋먼트와 적용되는 더스트 한도의 주인도 달라집니다. 한쪽 화면에 10만 사토시가 찍혀 있어도 상대 예비금 1만 사토시, 수수료 부담분, 이미 묶인 HTLC가 있으면 10만 사토시를 전부 보낼 수 없습니다.
채널 잔액은 통장 잔액 한 숫자가 아니라, 어느 commitment를 누가 게시하는지에 따라 잠기는 몫까지 포함한 상태입니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 예비금과 더스트 한도는 서로 다른 제한입니다
BOLT 2에서 채널을 제안하는 쪽은 dust_limit_satoshis와 channel_reserve_satoshis를 함께 보냅니다.
- 누가 무엇을 제한하는지 표로 나눕니다
예비금은 채널 상대가 일방 폐쇄 뒤에도 경제적 이해관계를 지니도록 만드는 프로토콜 제약입니다.
- HTLC를 잘라내도 오프체인 HTLC가 사라지지는 않습니다
BOLT 3 커밋먼트 형식에서, 내가 제안한 HTLC의 금액이 dust_limit_satoshis와 htlc_timeout_fee의 합보다 작으면 그 HTLC 출력은 생략됩니다.
설명을 위한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
누가 무엇을 제한하는지 표로 나눕니다
예비금은 채널 상대가 일방 폐쇄 뒤에도 경제적 이해관계를 지니도록 만드는 프로토콜 제약입니다. 더스트 한도는 노드가 자기 커밋먼트에 넣지 않을 작은 출력의 기준을 선언하는 값입니다. 반면 Bitcoin Core 멤풀의 더스트 정책은 표준 거래 중계 정책의 문맥이므로, 채널 협상 필드와 숫자가 자동으로 같지 않습니다.
BOLT는 상대 잔액이 예비금 아래로 내려가는 갱신을 보내지도 받아들이지도 말라고 규정합니다. 다만 채널을 연 직후에는 자금 조달 비용과 초기 이전 금액 때문에 예비금이 곧바로 채워지지 않는 과도기가 있을 수 있어, 구현은 규격이 허용하는 시점과 현재 커밋먼트 상태를 함께 봅니다.
| 요소 | 설정·부담 주체 | 실무 영향 |
|---|---|---|
| 채널 예비금 | 상대가 요구 | 그 아래로는 잔액을 보내지 못함 |
| 더스트 한도 | 커밋먼트 보유자가 선언 | 작은 HTLC 출력을 잘라내는 기준 |
| 커밋먼트 수수료 | 기본적으로 채널 개설자가 부담 | 수수료율이 오르면 쓸 수 있는 잔액 감소 |
| 진행 중 HTLC | 방향별 결제 | 정산 전까지 가용 잔액을 차지 |
| 최대 진행 중 금액 | 상대가 수신 한도 제시 | 예비금과 별개인 HTLC 합계 제한 |
HTLC를 잘라내도 오프체인 HTLC가 사라지지는 않습니다
BOLT 3 커밋먼트 형식에서, 내가 제안한 HTLC의 금액이 dust_limit_satoshis와 htlc_timeout_fee의 합보다 작으면 그 HTLC 출력은 생략됩니다. 받은 HTLC는 더스트 한도와 htlc_success_fee의 합보다 작을 때 생략됩니다. 수수료는 협상된 feerate_per_kw와 HTLC 거래별 무게로 계산되므로, 수수료율이 바뀌면 임계값도 함께 움직입니다.
잘려 나갔다고 해서 오프체인 HTLC가 사라지는 것은 아닙니다. 커밋먼트가 체인에 올라갈 때 별도 HTLC 출력으로 되찾을 수 없고, 그 금액이 커밋먼트 수수료 쪽으로 흡수된다는 뜻입니다. 이런 소액 HTLC가 많이 쌓이면 체인 위 출력 수와 실제로 되찾을 수 있는 금액을 오해하기 쉬우므로 방향별 목록을 따로 관리해야 합니다.
- 현재 커밋먼트의 보유자와 그쪽 더스트 한도를 확인합니다.
- HTLC가 내가 제안한 것인지 받은 것인지 분류합니다.
- 현재 수수료율로 타임아웃 또는 성공 수수료를 계산합니다.
- HTLC 금액을 방향별 임계값과 비교합니다.
- 잘려 나간 금액과 별도 출력으로 남을 금액을 따로 합산합니다.
12만 사토시 잔액 예제로 실제 송금 가능액을 봅니다
가정해 보겠습니다. 로컬 잔액 120,000 사토시, 상대가 요구한 예비금 10,000 사토시, 내가 부담할 커밋먼트 수수료 예산 3,000 사토시, 아직 끝나지 않은 제안 HTLC 20,000 사토시라면 단순 가용 상한은 87,000 사토시입니다. 계산식은 120,000-10,000-3,000-20,000입니다. 실제 단일 결제는 라우팅 수수료, 상대의 htlc_minimum_msat와 max_htlc_value_in_flight_msat, 경로 유동성 때문에 이보다 더 작아질 수 있습니다.
수수료 급등으로 커밋먼트 수수료가 3,000 사토시에서 8,000 사토시로 오르면, 같은 상태의 상한은 82,000 사토시로 줄어듭니다. 이는 자금이 사라진 것이 아니라 최신 커밋먼트를 유효하게 게시하는 데 드는 수수료 부담분이 늘어난 결과입니다. 지갑이 예비금과 수수료 예비분을 묶어 ‘채널 예비금’ 하나로 보여 준다면, 진단 API의 원시 필드로 다시 나눠 봐야 합니다.
잔액 부족 오류는 순서대로 좁혀 갑니다
먼저 로컬 잔액과 상대의 channel_reserve_satoshis를 비교하고, 다음으로 누가 채널 개설자라서 커밋먼트 수수료를 내는지 봅니다. 이어서 대기 중인 HTLC 합계, 허용되는 최대 HTLC 개수, 최대 진행 중 금액, 최소 HTLC 금액을 확인합니다. 마지막으로 경로별 송신 용량과 라우팅 수수료를 반영합니다.
강제 폐쇄로 예비금을 꺼내 쓰려는 방법은 해결책이 아닙니다. 일방 폐쇄에는 CSV 지연, 채굴 수수료, HTLC 처리 비용이 따르고, 현재 채널 상태에 따라 회수 시점도 달라집니다. 채널을 운영할 때는 목표 결제액 외에 예비금과 수수료율 상승분을 남겨 두는 정책이 필요합니다.
자주 묻는 질문
예비금은 언제 돌려받나요?
채널을 정상적으로 협력 폐쇄하면 최종 정산 거래의 출력으로 돌아옵니다. 일방 폐쇄에서는 커밋먼트 구조, CSV 지연, 수수료 조건에 따라 회수합니다.
더스트 한도 아래의 HTLC는 상대가 가져가나요?
단순히 상대에게 넘어가는 개념이 아닙니다. 체인에 올라간 커밋먼트에서 별도 HTLC 출력이 빠지고, 그 금액이 거래 수수료에 더해지는 구조입니다.
표시 잔액이 있는데 결제가 실패하는 이유는 무엇인가요?
예비금, 커밋먼트 수수료, 대기 중인 HTLC, 상대의 HTLC 한도와 경로 유동성이 따로따로 적용되기 때문입니다.
양쪽 더스트 한도는 항상 같나요?
아닙니다. 각자 자기 커밋먼트에 적용할 값을 제시하므로 서로 다를 수 있습니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
