Lightning Address

안나는 자신의 팟캐스트를 후원받고 싶습니다. 청취자마다 새로운 긴 인보이스를 보내는 대신 Lightning Address를 공개합니다. 예시인 anna@example.com은 기억하기 쉽습니다. @ 앞부분은 서비스 안의 수취인을, 뒷부분은 지갑에 응답하는 도메인을 나타냅니다. 이메일을 닮은 형태는 의도한 것이지만 돈이 이메일로 전송되지는 않습니다. 기존 이메일이 자동으로 Lightning Address가 되지도 않고, 이름만으로 소유자의 신원을 증명할 수도 없습니다. 후원하려는 창작자가 공개한 주소인지 확인해야 합니다. [1] [6]

청취자가 호환 지갑에 이름을 입력하면 지갑은 서비스에서 결제 설명과 허용 금액 범위를 가져옵니다. 사용자가 도메인, 설명, 선택한 금액을 확인한 뒤 지갑은 개별 BOLT 11 인보이스를 요청하고 금액을 검증한 다음 결제합니다. 인보이스를 받았다는 것이 결제 완료를 뜻하지는 않습니다. 이 절차를 LNURL-pay라고 합니다. 서비스는 인보이스 요청 주소인 callback, 설명을 담은 metadata, 한도인 minSendable과 maxSendable을 반환합니다. amount는 satoshi의 천분의 일인 msat 단위입니다. 1000 msat = 1 sat이며 인보이스는 pr 필드에 담겨 옵니다. [2] [3]

안나는 지갑을 대신 관리하는 서비스를 이용할 수도, 자신의 결제를 처리하는 프로그램인 Lightning 노드에 이름을 연결할 수도 있습니다. 주소의 모습으로는 구분할 수 없습니다. 서버가 지갑에 응답하는 지점인 웹 endpoint는 중계 서버를 통해 안나의 노드에 인보이스를 요청할 수 있습니다. 중계자가 반드시 자금을 보관하는 것은 아니며 구성과 권한에 따라 달라집니다. 그래도 서버 응답의 통제권은 중요합니다. 응답을 바꿀 수 있는 사람은 결제자에게 다른 인보이스를 제시할 수 있습니다. 자체 도메인이 있다고 해서 자신의 키를 직접 관리하는 self-custody가 보장되는 것은 아닙니다. [3] [4]

지갑이 Lightning Address로 보내기를 지원해도 사용자에게 자신의 수취 주소를 제공하지 않을 수 있습니다. 받으려면 접근 가능한 웹 서비스, 인보이스 발행 기능, Lightning Network에서 실제로 결제를 받을 조건도 필요합니다. 결제는 채널을 통해 전달됩니다. 채널은 참여자 사이의 연결로, 결제에 따라 양쪽에 배분된 자금이 달라집니다. 여기에는 Inbound Liquidity, 즉 결제 때 수취인 쪽으로 넘어올 수 있는 채널 반대편의 자금도 포함됩니다. 기억하기 쉬운 이름이 이 수취 여력을 만들어 주지는 않습니다. 주소는 열리는데 결제가 실패한다면 이름이 원인이 아닐 수 있습니다. 웹 응답, 인보이스 수신, 실제 입금 확인은 구별해야 합니다. [3] [5]

자체 도메인에서는 결제 담당 서버를 바꾸면서 청취자에게 알려 준 이름을 유지할 수 있습니다. BTCPay 문서에는 HTTP 301로 endpoint를 리디렉션하는 예가 나옵니다. 웹 요청을 다른 곳으로 돌릴 뿐 코인이 이동하는 것은 아닙니다. 타인의 도메인에 속한 이름이라면 이런 통제권이 없을 수 있습니다. 지갑 복구 단어인 Seed Phrase만으로 서비스 계정에 다시 접근할 수 있다고 보장되지는 않습니다. 도메인 관리 권한이나 도메인의 목적지를 정하는 DNS 설정을 백업하는 것도 아닙니다. 변경 후에는 주소가 열리는지뿐 아니라 올바른 인보이스와 시험 결제의 실제 수신까지 확인해야 합니다. 이전 연락 상대가 새 이름을 자동으로 알게 되지도 않습니다. [5] [3]

LUD-16은 이름을 GET 웹 요청, 즉 데이터 요청으로 바꾸는 절차를 설명합니다. 지갑은 도메인의 /.well-known/lnurlp/username 경로를 조회하며 username을 사용자 이름으로 바꿉니다. 일반 웹에서는 HTTPS를, onion 도메인에서는 HTTP를 사용합니다. payRequest 응답을 받으면 LUD-06 절차로 이어집니다. HTTPS는 전송 도중의 변조를 막지만 서비스 자체가 정직하다는 증거는 아닙니다. 서비스는 요청을 처리하고 누구를 위한 인보이스인지 압니다. 따라서 읽기 쉬운 이름 자체가 익명성을 높여 주지는 않습니다. [1] [2]

LUD-16은 사용자 이름에 소문자 a-z, 숫자 0-9와 -_.을 허용합니다. 일반 이메일은 더 다양한 문자를 허용합니다. 선택 기능인 @domain은 /.well-known/lnurlp/_ 경로의 기본 수취인 _@domain을 가리키지만 지갑이나 서비스가 지원하지 않을 수 있습니다. +tag도 보편적 기능은 아닙니다. 지원하는 서비스는 후원의 목적을 구별하고 text/tag로 표시할 수 있습니다. 이것은 새로운 개인 키도, 개인정보 보호의 보장도 아닙니다. 일상적으로는 수취인이 공개한 정확한 이름을 복사하는 것이 좋습니다. [1]

메타데이터는 지갑과 서비스가 구조화된 JSON 형식으로 주고받는 부가 정보입니다. LNURL-pay에는 짧은 결제 설명인 text/plain이 들어갑니다. LUD-16은 이름과의 관계를 나타내는 text/identifier를 추가하며, 실제 이메일에 해당하는 이름에는 text/email을 사용합니다. 이를 통해 지갑이 어떤 결제인지 보여 줄 수 있습니다. 하지만 여전히 서비스가 제공한 정보이지 안나의 실제 신원을 독립적으로 검증한 결과는 아닙니다. 처음 확보한 주소, 도메인, 금액을 확인하는 과정은 여전히 필요합니다. [1] [2]