강제 종료는 한쪽이 최신 commitment transaction을 온체인에 게시하는 절차입니다. 게시한 쪽의 로컬 출력에는 상대가 폐기 상태 게시를 감시할 시간을 주는 `to_self_delay`가 적용되며, pending HTLC는 성공·timeout 조건에 따라 별도 거래와 확인이 필요할 수 있습니다. 채널이 closed로 보이는 시점과 모든 출력이 지갑에서 spendable이 되는 시점은 다릅니다.
강제 종료는 최신 채널 상태를 체인에 올립니다
채널 양측은 결제마다 최신 잔액을 반영한 commitment transaction을 보유합니다. 협력 종료에서는 양측이 pending HTLC 없이 최종 분배와 수수료에 합의한 closing transaction을 서명합니다. 상대가 오프라인이거나 합의가 되지 않으면 한쪽이 자신이 가진 commitment를 게시할 수 있습니다.
BOLT 5는 상호 종료, 현재 commitment 게시, 폐기된 commitment 게시를 구분합니다. 정상적인 강제 종료도 프로토콜이 준비한 복구 경로이지 곧바로 해킹 증거는 아닙니다. 다만 온체인 수수료와 잠금 대기, 여러 출력 처리 비용이 생깁니다.
채널 종료 완료와 자금 지출 가능은 같은 이벤트가 아니라 여러 온체인 출력이 차례로 성숙하는 과정입니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 강제 종료는 최신 채널 상태를 체인에 올립니다
채널 양측은 결제마다 최신 잔액을 반영한 commitment transaction을 보유합니다.
- to_self_delay는 폐기 상태 처벌 시간을 확보합니다
commitment를 게시한 당사자의 `to_local` 출력은 상대가 과거 상태 게시 여부를 확인하고 필요하면 penalty 경로를 사용할 수 있도록 CSV 지연 을 둡니다.
- pending HTLC는 각기 다른 성공·timeout 경로를 가집니다
종료 시 진행 중 HTLC가 있으면 payment preimage를 가진 성공 경로와 CLTV 만료 뒤 timeout 경로가 나뉩니다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
to_self_delay는 폐기 상태 처벌 시간을 확보합니다
commitment를 게시한 당사자의 `to_local` 출력은 상대가 과거 상태 게시 여부를 확인하고 필요하면 penalty 경로를 사용할 수 있도록 CSV 지연을 둡니다. 상대의 즉시 출력과 같은 시각에 쓸 수 있다고 보면 안 됩니다. 정확한 delay는 채널 협상 값과 출력 스크립트에서 확인합니다.
가정으로 delay가 144블록이라면 평균 10분을 곱해 약 하루라고 설명할 수 있지만 정확히 24시간을 보장하지 않습니다. 시작점도 앱에서 close 버튼을 누른 시각이 아니라 commitment가 확인된 블록입니다. 현재 높이와 성숙 목표 높이를 기록하세요.
| 상황 | 게시 거래 | 주요 대기 |
|---|---|---|
| 협력 종료 | 합의 closing 거래 | 일반 온체인 확인 |
| 내 commitment 강제 종료 | 최신 commitment | to_self_delay와 sweep |
| 상대 강제 종료 | 상대 commitment | 내 출력·HTLC 조건별 처리 |
| 폐기 상태 게시 | 오래된 commitment | 감시와 penalty 경로 |
pending HTLC는 각기 다른 성공·timeout 경로를 가집니다
종료 시 진행 중 HTLC가 있으면 payment preimage를 가진 성공 경로와 CLTV 만료 뒤 timeout 경로가 나뉩니다. 일부 출력은 두 단계 거래를 거쳐야 하고 dust 한도 아래 HTLC는 commitment 수수료에 포함돼 별도 출력으로 남지 않을 수 있습니다.
그래서 채널 잔액 합계와 첫 commitment 출력 합계가 화면상 바로 맞지 않을 수 있습니다. 노드의 pending channels, limbo balance, sweep 목록과 각 outpoint를 확인하세요. 하나의 close txid만 보고 모든 자금 회수가 끝났다고 기록하지 않습니다.
- channel point와 close transaction을 확인합니다.
- 게시된 commitment가 최신 상태인지 노드 로그로 확인합니다.
- 각 출력의 CSV·CLTV 조건과 성숙 높이를 기록합니다.
- sweep 거래의 수수료와 확인 상태를 추적합니다.
- 모든 출력이 spendable일 때만 회수 완료로 표시합니다.
오프라인 노드는 감시 공백을 만들 수 있습니다
상대가 폐기된 상태를 게시하면 정직한 노드는 지연 기간 안에 이를 감지해 penalty 거래를 내야 합니다. 노드를 장기간 끄는 운영에서는 watchtower 같은 감시 위임이나 충분한 온라인 가동 전략이 필요합니다. 백업만 보유했다고 실시간 감시가 자동 수행되는 것은 아닙니다.
watchtower도 등록된 상태와 blob, 연결 정책에 따라 보호 범위가 다릅니다. 사용 중인 구현에서 실제 세션이 활성인지, 최신 채널 업데이트가 업로드됐는지 확인해야 합니다. 단순 설정 토글 화면을 보호 성공 증거로 삼지 마세요.
수수료가 높을 때도 임의 재방송을 피합니다
강제 종료 출력은 anchor, CPFP와 sweep fee bump 정책 등 구현별 방식으로 확인을 촉진할 수 있습니다. 사용자가 원시 거래를 임의 수정하거나 충돌 거래를 여러 서비스에 방송하면 노드 상태와 지갑 추적이 어긋날 수 있습니다. 공식 fee bump 명령과 로그를 사용하세요.
온체인 수수료가 높다고 delay 자체를 수수료로 단축할 수는 없습니다. CSV·CLTV는 유효성 조건이고 수수료는 유효해진 거래의 채굴 우선순위 문제입니다. 성숙 전과 성숙 후 미확인을 구분해 대응합니다.
지원 요청에는 비밀 대신 출력 상태를 제공합니다
지원 담당자에게 시드, channel.db, macaroon 원본을 보내지 마세요. channel point, 공개 txid, 출력 인덱스, 현재·목표 높이, 노드 버전과 비밀을 제거한 오류 로그면 1차 진단이 가능합니다. 백업 파일은 공개 채널로 공유하지 않습니다.
종료 전에는 가능하면 노드 데이터의 안전한 백업과 공식 진단 결과를 확보하세요. 상대가 온라인이면 협력 종료가 일반적으로 단순하지만 수수료 조건을 확인해야 합니다. 이미 강제 종료가 시작됐다면 프로세스를 되돌리려 하지 말고 출력별 회수 상태를 끝까지 추적합니다.
자주 묻는 질문
강제 종료하면 비트코인을 잃나요?
최신 상태를 정상 게시하면 복구 경로가 있지만 수수료와 지연이 생깁니다. 오래된 상태 게시나 백업 오용은 별도 위험입니다.
144블록은 정확히 하루인가요?
아닙니다. 블록 간격은 변동하며 commitment 확인 블록부터 실제 블록 수를 셉니다.
close 거래 확인 뒤 왜 잔액이 0인가요?
to_self_delay나 HTLC 출력이 아직 성숙하지 않았거나 sweep 거래가 미확인일 수 있습니다. 출력별 상태를 확인하세요.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
