라이트닝 채널 reserve와 dust limit가 사용 가능 잔액을 줄이는 이유

channel_reserve_satoshis는 상대방이 commitment transaction에서 유지하도록 요구하는 최소 잔액이고, dust_limit_satoshis는 그 commitment의 출력과 HTLC를 잘라낼 기준입니다. 두 값은 같은 제한이 아닙니다. 실제 송금 가능액은 로컬 잔액에서 상대가 요구한 reserve, 자신이 부담할 commitment fee, 진행 중 HTLC와 구현의 안전 여유를 뺀 값으로 봐야 하며, HTLC가 on-chain 출력에 남는지는 방향별 dust limit에 timeout 또는 success fee를 더한 BOLT 3 임계값으로 판단합니다.

Reserve와 dust limit은 reserve를 비트코인 네트워크의 dust 정책과 같은 값으로 취급하면

BOLT 2에서 채널을 제안하는 쪽은 dust_limit_satoshis와 channel_reserve_satoshis를 전달합니다. 전자는 자신이 보유하는 commitment transaction에서 너무 작은 출력이 만들어지지 않도록 하는 기준이고, 후자는 상대가 그 commitment에서 유지해야 할 최소 잔액입니다. 따라서 reserve를 비트코인 네트워크의 dust 정책과 같은 값으로 취급하면 잔액 계산이 어긋납니다.

각 참여자는 상대가 정한 reserve를 지켜야 합니다. 채널 방향에 따라 보는 commitment와 적용 dust limit의 주체도 달라집니다. 한쪽 UI에 10만 sat가 표시되어도 상대 reserve 1만 sat, fee 부담분과 이미 묶인 HTLC가 있으면 10만 sat 전부를 보낼 수 없습니다.

채널 잔액은 통장 잔액 한 숫자가 아니라, 어느 commitment를 누가 게시하는지에 따라 잠기는 몫까지 포함한 상태입니다.

JOBCOIN 해설

출발 체인의 기록과 메시지 검증, 도착 체인의 기록을 연결한 개념도 — **그림과 함께 짚어볼 본문 내용**
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.

누가 무엇을 제한하는지 표로 나눕니다

Reserve는 채널 상대가 일방 폐쇄 뒤에도 경제적 이해관계를 갖도록 만드는 protocol constraint입니다. Dust limit은 노드가 자신의 commitment에 넣지 않을 작은 출력을 선언하는 값입니다. 반면 Bitcoin Core의 mempool dust 정책은 표준 거래 relay 정책 문맥이므로 채널 협상 필드와 숫자가 자동으로 같지 않습니다.

BOLT는 remote balance가 reserve 아래로 내려가는 update를 보내거나 받아들이지 않도록 규정합니다. 다만 채널 개설 직후에는 funding 비용과 push amount 때문에 reserve가 즉시 충족되지 않는 과도 상태가 있을 수 있어, 구현은 규격의 허용 시점과 현재 commitment state를 함께 봅니다.

잔액 제한 요소 비교
요소	설정·부담 주체	실무 영향
channel reserve	상대가 요구	그 아래로 잔액을 보내지 못함
dust limit	commitment 보유자가 선언	작은 HTLC 출력을 trim하는 기준
commitment fee	기본적으로 채널 initiator가 부담	feerate가 오르면 spendable 감소
진행 중 HTLC	각 방향 결제	정산 전 available balance를 점유
max in-flight	상대가 수신 한도 제시	reserve와 별개의 HTLC 합계 제한

HTLC trimming은 off-chain HTLC가 사라지는 것은 아닙니다

BOLT 3 commitment 형식에서 offered HTLC의 금액이 dust_limit_satoshis와 htlc_timeout_fee의 합보다 작으면 해당 HTLC 출력은 생략됩니다. Received HTLC는 dust limit과 htlc_success_fee의 합보다 작을 때 생략됩니다. 수수료는 협상된 feerate_per_kw와 각 HTLC transaction weight로 계산되므로 feerate가 변하면 임계값도 변합니다.

Trim되었다고 off-chain HTLC가 사라지는 것은 아닙니다. Commitment가 체인에 올라갈 때 별도 HTLC output으로 회수할 수 없고 그 금액이 commitment fee 쪽으로 흡수된다는 뜻입니다. 이런 소액 HTLC가 너무 많이 쌓이면 on-chain 출력 수와 실제 회수 가능액을 오해하기 쉬우므로 방향별 목록을 유지해야 합니다.

현재 commitment owner와 그쪽 dust limit을 확인합니다.
HTLC가 offered인지 received인지 분류합니다.
현재 feerate로 timeout 또는 success fee를 계산합니다.
HTLC 금액을 방향별 임계값과 비교합니다.
Trimmed 금액과 별도 출력으로 남을 금액을 따로 합산합니다.

12만 sat 잔액 예제로 실제 송금 가능액을 봅니다

가정 예로 로컬 잔액 120,000 sat, 상대가 요구한 reserve 10,000 sat, 로컬이 부담할 commitment fee 예산 3,000 sat, 미결 offered HTLC 20,000 sat라면 단순 가용 상한은 87,000 sat입니다. 산식은 120,000-10,000-3,000-20,000입니다. 실제 단일 payment는 routing fee, 상대의 htlc_minimum_msat와 max_htlc_value_in_flight_msat, 경로 liquidity 때문에 더 작아질 수 있습니다.

Fee spike가 commitment fee를 3,000 sat에서 8,000 sat로 올리면 같은 상태의 상한은 82,000 sat로 줄어듭니다. 이는 자금이 분실된 것이 아니라 최신 commitment를 유효하게 게시하기 위한 fee 부담분이 늘어난 결과입니다. 지갑이 reserve와 fee reserve를 한데 묶어 ‘채널 예비금’이라고 표시한다면 진단 API의 원시 필드로 다시 나눠야 합니다.

잔액 부족 오류는 순서대로 좁힙니다

먼저 local balance와 remote channel_reserve_satoshis를 비교하고, 다음으로 누가 channel initiator라 commitment fee를 부담하는지 봅니다. 이어 pending HTLC 합계, max accepted HTLCs, max in-flight와 최소 HTLC를 확인합니다. 마지막으로 경로별 outgoing capacity와 routing fee를 반영합니다.

Force close로 reserve를 꺼내 쓰려는 접근은 해결책이 아닙니다. 일방 폐쇄에는 CSV 지연, miner fee와 HTLC 처리 비용이 붙고 현재 channel state에 따라 회수 시점이 달라집니다. 채널을 운영할 때는 목표 결제액 외에 reserve와 feerate 상승분을 남기는 정책이 필요합니다.

자주 묻는 질문

Reserve는 언제 돌려받나요?

채널을 정상적으로 협력 폐쇄하면 최종 정산 거래의 출력으로 반영됩니다. 일방 폐쇄에서는 commitment 구조와 CSV 지연, 수수료 조건을 따라 회수합니다.

Dust limit 아래 HTLC는 상대가 가져가나요?

단순히 상대에게 이전되는 개념이 아닙니다. On-chain commitment에서 별도 HTLC output이 생략되고 그 금액이 거래 수수료에 더해지는 구조입니다.

표시 잔액이 있는데 결제가 실패하는 이유는 무엇인가요?

Reserve, commitment fee, pending HTLC, 상대의 HTLC 한도와 경로 유동성이 별도로 적용되기 때문입니다.

양쪽 dust limit은 항상 같나요?

아닙니다. 각자가 자신의 commitment에 적용할 값을 제시하므로 서로 다를 수 있습니다.

더 깊이 읽기

본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.