라이트닝 채널 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 해설

VISUAL GUIDE체인 사이의 검증 과정

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

   BOLT 2에서 채널을 제안하는 쪽은 dust_limit_satoshis와 channel_reserve_satoshis를 전달합니다.

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

   Reserve는 채널 상대가 일방 폐쇄 뒤에도 경제적 이해관계를 갖도록 만드는 protocol constraint입니다.

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

   BOLT 3 commitment 형식에서 offered HTLC의 금액이 dust_limit_satoshis와 htlc_timeout_fee의 합보다 작으면 해당 HTLC 출력은 생략됩니다.

AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.

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

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

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

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 상승분을 남기는 정책이 필요합니다.

자주 묻는 질문