BOLT 11

안나가 전자책을 산다고 해 봅시다. 상점은 은행 계좌 대신 Lightning 인보이스를 보여 주고, 지갑이 결제 정보를 읽습니다. 안나는 긴 문자열을 이해할 필요 없이 승인 전에 금액과 용도, 수수료를 확인하면 됩니다. 자발적인 후원처럼 금액이 정해지지 않은 인보이스도 있습니다. 이때는 지불하는 사람이 금액을 입력하며, 금액이 없다고 아무것도 내지 않아도 된다는 뜻은 아닙니다. 조금 더 살펴보면 lnbc는 메인넷, lntb는 testnet, lntbs는 signet, lnbcrt는 regtest를 나타내며 뒤의 것들은 테스트 환경입니다. 인코딩된 금액의 단위는 satoshi가 아니라 BTC이고 필요하면 m, u, n, p 배율이 붙습니다. p를 쓸 때는 정수 millisatoshi가 되도록 숫자가 0으로 끝나야 합니다. 1000 msat = 1 sat입니다. [1]

설명은 기술적인 요청을 안나의 책값 같은 구체적인 목적과 연결합니다. 인보이스에는 d 필드의 텍스트나 h 필드의 디지털 지문 중 하나가 들어갑니다. 이 지문은 SHA256으로 계산하며, 지갑은 따로 받은 설명에서도 같은 결과가 나오는지 확인해야 합니다. 텍스트에서 계산한 이 짧은 확인용 값을 해시라고 합니다. 지문만 보고 주문 내용을 읽을 수는 없습니다. 유효한 서명은 설명을 수취인의 키와 연결하지만 판매자가 책을 보내 준다고 약속하지는 않습니다. 개발자에게는 또 다른 주의점이 있습니다. 설명은 외부에서 받은 텍스트이므로 안전하게 데이터로 표시해야 하며 코드로 실행해서는 안 됩니다. [1]

안나가 주문 창을 열어 둔 채 나중에 돌아오면 지갑이 만료를 알릴 수 있습니다. 그때는 새 인보이스를 요청해야 합니다. 만료 시점은 생성 시각 timestamp와 기간 x를 더해 계산합니다. x가 없으면 기본값은 3600초, 즉 한 시간입니다. 만료되어도 완료된 결제가 취소되지는 않습니다. c 필드, 정식 이름 min_final_cltv_expiry_delta는 다른 시간을 정합니다. 경로의 마지막 조건부 결제 HTLC에 주는 시간 여유입니다. HTLC는 정해진 시간 안에 올바른 비밀값을 제시해야 정산되도록 합니다. 이 여유는 인보이스 유효 기간의 초가 아니라 블록 수로 측정하며 c가 없으면 지불자는 최소 18블록을 사용합니다. 두 시간 조건을 혼동하면 안 됩니다. [1]

Lightning 결제는 결제 채널을 통과합니다. 채널 안에서는 두 당사자가 자금의 배분을 갱신하므로 일반적인 결제마다 Bitcoin 메인 블록체인에 기록할 필요가 없습니다. 성공하려면 사용 가능한 경로와 각 채널의 알맞은 쪽에 충분한 자금, 즉 유동성이 있어야 합니다. r 필드에는 마지막 구간을 찾는 단서인 routing hints가 들어갈 수 있습니다. 수취인을 찾는 데 도움이 되지만 실시간 가용 용량을 보여 주지는 않습니다. 노드 공개키, 채널 식별자, 수수료 조건을 드러낼 수도 있으므로 인보이스 전체를 비공개 문서로 생각하지 마세요. 선택 사항인 f 필드는 일반 Bitcoin 주소를 대안으로 제시할 수 있습니다. 그곳으로 지불하면 메인 체인을 사용하고 별도 수수료와 확인 절차를 거칩니다. 같은 전달 방식에서 버튼만 바뀌는 것이 아닙니다. [1] [2] [5]

QR을 스캔했거나 인보이스를 받았다고 영수증이 생긴 것은 아닙니다. 전송 후 지갑의 결과를 확인하세요. 대기 중과 완료는 다릅니다. 정산 증거로는 올바른 preimage도 쓰입니다. 이 비밀값의 해시가 인보이스의 결제 해시와 일치해야 합니다. 인보이스와 함께 결제 증거로 보관할 수 있지만 상품 배송을 보장하지는 않습니다. 앱 연결이 끊기거나 응답을 잃었다면 먼저 원래 결제 상태를 확인하세요. 즉시 새 인보이스를 요청하거나 대체 주소로 지불하면 두 번 내게 될 수 있습니다. 일부 지갑은 재시도를 알아보지만, 형식 자체가 앱과 결제 경로를 가로지르는 보편적인 중복 방지를 제공하지는 않습니다. [2] [4]

긴 문자열은 Bech32 인코딩을 사용합니다. 체크섬은 옮겨 적는 과정의 오류를 찾는 데 도움이 되지만 암호화가 아니며 내용을 숨기지도 않습니다. secp256k1 기반 ECDSA 디지털 서명은 다른 일을 합니다. 결제 정보가 수취인 키에 대응하고 나중에 변경되지 않았는지 확인합니다. 그 키를 가진 사람의 법적 신원이나 정직함을 증명하지는 않습니다. Bitcoin Bech32 주소와 달리 BOLT 11은 90자를 넘을 수 있습니다. QR에는 대문자가 적합하지만 유효한 문자열에서 대문자와 소문자를 섞으면 안 됩니다. 사람은 보통 스캔하거나 복사하고, 이 검사는 지갑이 수행합니다. [1]

payment hash는 비밀값 payment preimage를 SHA256으로 계산한 디지털 지문으로 p 필드에 저장됩니다. 정산에 성공하면 지불자는 preimage를 받아 지문이 일치하는지 확인할 수 있습니다. 반면 s 필드는 payment_secret을 담습니다. 지불자는 이미 인보이스에서 이 값을 읽고 경로의 마지막 구간에서 수취인에게 전달합니다. 이는 중계 노드의 탐지 시도로부터 수취인을 보호하는 데 도움이 됩니다. Secret은 preimage도, 지갑 seed도 아닙니다. QR에서 읽었다고 결제가 증명되거나 지갑을 복구할 권한이 생기지는 않습니다. 현재 BOLT 11은 p와 s를 모두 요구합니다. 비슷한 이름 아래 결제 식별, 필요한 값 전달, 정산 증명이라는 서로 다른 역할이 있습니다. [1] [2]

지갑은 요청된 결제를 수행할 수 있는지도 알아야 합니다. 9 필드에 기능 플래그가 들어갑니다. 알 수 없는 짝수 비트는 필수 기능을 뜻하므로 결제를 거절해야 하고, 알 수 없는 홀수 비트는 선택 기능이므로 무시할 수 있습니다. 알려진 기능 사이의 의존 관계도 충족해야 합니다. 예를 들어 Basic MPP는 하나의 결제를 여러 부분으로 나누어 수취인에게서 합칩니다. 인보이스가 basic_mpp를 제공할 때만 사용할 수 있습니다. 나눴다고 독립된 인보이스 여러 개가 되는 것도, 각 부분을 다시 지불할 이유가 되는 것도 아닙니다. 초보자가 기억할 점은 간단합니다. 지원하지 않는다는 경고를 인보이스 수동 수정으로 우회하지 말고 먼저 지갑의 호환성을 해결하세요. [1] [3]