Lightning Watchtower

Anna와 Pavel은 결제 채널을 가지고 있습니다. 자금은 Bitcoin에 함께 잠겨 있고 Lightning 결제로 그 배분이 바뀝니다. Pavel이 Anna에게 결제하고 두 사람은 새로운 잔액에 합의한 뒤 이전 상태를 철회합니다. 그런데 Anna의 인터넷이 끊겼습니다. Pavel이 예전 상태를 게시한다면 이미 쓴 돈을 되찾으려 할 수 있습니다. Anna는 이런 상황에 대비해 Lightning Watchtower를 이용할 수 있습니다. 노드는 철회된 상태를 보호할 암호화 자료를 미리 보냅니다. 서비스가 체인에서 해당 트랜잭션을 인식하면 Anna가 접속하지 않아도 자금 회수 트랜잭션을 전파할 수 있습니다. Anna 대신 결제하거나 노드의 연결을 복구해 주는 것은 아닙니다. [1] [8]

합의한 자금 배분마다 commitment transaction이 있습니다. Bitcoin 체인에서 채널을 닫는 데 쓸 수 있는 서명된 트랜잭션입니다. 상태를 갱신할 때 참여자들은 이전의 철회된 상태가 게시되면 벌칙을 적용할 수 있는 정보를 교환합니다. 여기서는 이런 벌칙 기반 채널을 설명합니다. Pavel이 현재의 유효한 상태를 사용한다면 Anna가 오프라인인 동안에도 일방적으로 채널을 닫을 수 있습니다. Watchtower는 이런 종료를 막기 위한 서비스가 아닙니다. 의도적으로 게시했든 오래된 백업에서 실수로 게시했든, 특정한 철회 상태에 대응합니다. 중요한 것은 상태의 철회 여부이지 트랜잭션의 생성 시점가 아닙니다. [1] [8]

Seed Phrase는 단어로 기록한 백업으로, 결제에 서명하는 데 필요한 개인키를 복구할 때 사용합니다. LND는 Lightning 노드를 운영하는 프로그램 중 하나입니다. Anna는 서비스에 Seed Phrase나 지갑 전체의 개인 키를 넘기지 않습니다. 특정 대응에 필요한 제한된 자료와 서명만 제공합니다. LND에서는 이 묶음을 JusticeKit이라고 합니다. justice transaction이라는 자금 회수 트랜잭션은 미리 마련한 조건에 따라 보호 대상 자금을 돌려줍니다. 그렇다고 Watchtower가 Anna의 다른 코인을 마음대로 쓸 권한을 얻지는 않습니다. 서비스에 보상을 주지 않는 모델에서는 보호 금액에서 Bitcoin 트랜잭션 수수료를 뺍니다. 코드에는 감시탑 보상을 포함하는 유형도 있지만, 이것만으로 특정 운영자가 유료 서비스를 제공한다고 볼 수는 없습니다. [3] [4] [5]

Watchtower가 도움을 주려면 필요한 자료를 실제로 받아야 합니다. 설정에 주소를 입력하거나 전송 대기열에 작업이 보이는 것만으로는 부족합니다. 감시탑과 통신하는 Anna 노드의 부분인 클라이언트는 갱신 자료의 수신 응답을 받아야 합니다. 연결이 끊기거나 session이라는 저장 약정의 용량이 소진되거나 백업이 거절될 수 있습니다. 따라서 Anna는 미전달 갱신 자료와 오류도 살펴야 합니다. 자료를 받았다고 성공이 보장되는 것도 아닙니다. 감시탑은 올바른 체인을 계속 추적하고 대응 트랜잭션이 제때 블록에서 확인되도록 해야 합니다. [6] [8]

Anna가 기기를 잃어버려도 Watchtower에서 기기를 복원하지는 않습니다. 서비스는 철회된 상태의 악용을 감시하며 지갑을 복원하거나 키 도난을 해결하지 않습니다. LND는 채널 복구에 Static Channel Backup(SCB)을 사용합니다. 지갑 seed와 함께 채널을 닫아 자금을 되찾는 데 도움을 주며, 노드가 멈췄던 바로 그 상태에서 재개하는 방식은 아닙니다. SCB는 매 갱신의 사본도, 감시탑에 보내는 암호화 자료도 아닙니다. 올바른 복구 절차 없이 오래된 channel.db를 실행하면 자신의 철회 상태를 게시할 수 있어 특히 위험합니다. 사용하는 지갑과 해당 버전의 문서에 따라 백업을 준비하세요. [7]

트랜잭션 출력에는 금액과 그 돈을 쓰기 위해 충족해야 할 조건이 담겨 있습니다. 이 보호는 자신의 채널 상태를 게시한 사람이 지연 조건이 있는 자기 출력을 즉시 쓸 수 없다는 점을 이용합니다. BOLT 3에서는 이 출력을 to_local, 대기 기간을 to_self_delay라고 합니다. CSV는 출력이 확인된 때부터 이 지연을 블록 수로 재는 규칙입니다. 올바른 철회 키를 가진 상대방은 기다리지 않고 벌칙 경로를 쓸 수 있습니다. 덕분에 Watchtower는 먼저 대응할 시간을 얻습니다. 지연이 끝나도 벌칙 경로가 사라지지는 않지만 이제 상대방도 같은 자금을 쓸 수 있습니다. 충돌하는 지출 중 어느 것이 유효하게 확인되는지에 따라 결과가 달라집니다. 회수 트랜잭션을 전파하는 것만으로는 부족하며 블록 수가 정확한 시간 수를 뜻하지도 않습니다. [1] [9]

서비스를 고르기 전에 무엇을 실제로 보호하는지 확인하세요. HTLC는 채널 안에서 완료를 기다릴 수 있는 조건부 결제입니다. 잔액을 감시한다고 이런 결제까지 보호되는 것은 아닙니다. 여기서 Dust는 해당 트랜잭션에 포함하기에 너무 작은 출력을 뜻합니다. 검증한 LND v0.21.3-beta의 backupTask는 철회된 commitment에 존재하는 dust가 아닌 to_local 및 to_remote 출력을 준비합니다. 모든 HTLC 출력에 대한 일반적인 보호를 포함하지 않으며 관련 문서는 이를 향후 확장으로 설명합니다. Bitcoin Script는 출력을 쓰기 위한 조건을 표현하는 언어입니다. 페널티 경로로 출력을 쓸 수 있다는 사실만으로 특정 타워가 필요한 데이터를 받았거나 그 보호를 실행할 수 있다고 볼 수는 없습니다. [3] [5]

암호화된 자료 덕분에 감시탑이 Anna의 모든 잔액을 계속 읽을 필요는 없습니다. 짧은 식별자로 일치 여부를 찾고 인식한 트랜잭션의 정보로 데이터를 복호화합니다. 다음은 특정 LND 버전의 기술 참고 자료입니다. txid는 트랜잭션 식별자, blob은 데이터 묶음입니다. LND v0.21.3-beta에서 BreachHint는 바이너리 txid의 SHA-256 중 첫 16바이트입니다. BreachKey는 같은 바이너리 txid를 두 번 이어 붙인 뒤 SHA-256을 계산합니다. 표시된 txid의 첫 16글자나 단순한 앞쪽 절반이 아닙니다. 클라이언트가 JusticeKit을 암호화하며, 일치하는 트랜잭션을 알면 키를 파생하여 데이터를 복호화할 수 있습니다. [2] [3]

다른 사람을 위한 감시탑 운영과 자신의 채널 감시 요청은 다릅니다. 다음 설정은 LND 운영자를 위한 것이며, RPC는 프로그램이 명령을 받는 인터페이스입니다. LND는 서버용 watchtower.active와 클라이언트용 wtclient.active를 구분합니다. 서버를 켜는 것만으로 자기 채널을 다른 타워에 백업하도록 설정되지는 않습니다. lncli tower info는 서버의 pubkey, listeners, uris를 보여 주고 lncli wtclient add는 클라이언트에 타워를 등록합니다. 타워 공개 키는 Lightning 노드 키와 다릅니다. 네트워크, 주소 접근성, 사용 빌드의 RPC 지원을 확인하세요. [5]

대응하려면 Bitcoin 블록 공간의 비용을 내야 합니다. satoshi는 비트코인의 최소 단위입니다. 가상 바이트는 트랜잭션 각 부분에 적용되는 서로 다른 가중치를 반영해 크기를 측정하는 단위입니다. 요율은 트랜잭션의 가상 바이트당 satoshi이며 보호 금액의 일정 비율이 아닙니다. LND v0.21.3-beta의 policy와 session에 있는 sweep_sat_per_vbyte 필드는 sat/vB 단위 수수료율입니다. 수수료는 반환 금액을 줄입니다. backupTask는 가치가 너무 작거나 session 매개변수가 부적합한 상태를 거부할 수 있어 모든 준비 작업이 적격 백업은 아닙니다. 나중에 설정을 바꿨다고 이전에 서명한 트랜잭션이 바뀌었다고 볼 수 없으며, 너무 낮은 수수료율은 대응을 지연시킬 수 있습니다. [3] [6]

첫 감시탑이 멈췄을 때 두 번째 감시탑이 도움을 주려면 그곳도 필요한 데이터를 받아야 합니다. 독립성에는 서비스 이름뿐 아니라 연결망과 운영자도 포함됩니다. 독립적인 여러 타워와 자체 감시는 한 번의 장애가 미치는 영향을 줄일 수 있습니다. 다만 각 타워가 실제로 받은 업데이트를 확인해야 합니다. 여러 주소를 등록한 것만으로 모든 상태의 복제가 입증되지는 않습니다. 별도 장비, 네트워크, 위치는 공통 장애를 줄입니다. 암호화된 blob과 인증된 연결은 잔액 노출을 제한하지만 메타데이터, 업데이트 빈도 노출, 상관 분석 위험을 없애지는 않습니다. [5] [8]

점검할 때는 보낸 갱신 자료와 실제로 수신된 자료를 구분하세요. 다음 명령과 필드는 LND 관리자를 위한 상세 참고 자료입니다. 감시탑의 백업 수신 응답은 블록에서의 트랜잭션 확인과 다릅니다. lncli wtclient towers, lncli wtclient tower, lncli wtclient stats, lncli wtclient policy를 사용하세요. LND v0.21.3-beta에서 num_backups와 num_pending_backups를 구분해야 하며 후자는 타워 확인을 기다리는 백업 수입니다. stats 응답의 num_failed_backups는 실패하여 확인받지 못한 백업 수입니다. 통계는 클라이언트 시작 이후의 기간에 해당합니다. active_session_candidate는 sessions의 후보임을 뜻할 뿐 완전한 보호의 증거가 아닙니다. [6]

올바른 설정은 시작입니다. 테스트는 철회된 상태의 인식부터 보호 자금의 회수까지 전 과정을 다뤄야 합니다. 실제 돈으로 이런 실험을 하지 마세요. 클라이언트와 타워의 정확한 릴리스, 지원 채널 및 session 유형, 데이터 최신성, 수수료, 체인 동기화를 확인하세요. 대응 기능은 격리된 테스트 환경에서 시험하세요. 일반적인 일방적 종료(force close)는 철회된 상태에 대한 대응을 입증하지 못합니다. 철회된 상태의 공개(breach), 재구성된 justice transaction, 확정된 출력이 결과의 증거입니다. 시연에 성공해도 향후 가용성을 보장하거나 Lightning의 모든 위험을 없애지는 않습니다. [1] [3] [6]