Lightning Address

LUD-16은 username과 도메인을 사용하지만 이름을 소문자 a-z, 숫자 0-9, -_.로 제한합니다. 더하기 기호는 서비스가 태그를 지원할 때만 허용됩니다. 일반 이메일 문법은 더 넓습니다. 따라서 메일함이 있다고 Lightning Address가 보장되지 않으며 같은 이름이 수신자의 신원을 인증하지도 않습니다. [Lightning Address — LUD-16] [Lightning Address — Project overview]

지갑은 해당 도메인의 /.well-known/lnurlp/username 경로를 GET으로 가져옵니다. HTTPS를 사용하며 onion 서비스에서는 HTTP를 사용할 수 있습니다. 응답은 LUD-06의 payRequest입니다. 실제 도메인과 서비스가 중요하며 골뱅이 앞 부분은 노드의 공개키가 아닙니다. [Lightning Address — LUD-16]

응답에는 callback, metadata, minSendable/maxSendable 한도가 있습니다. 지불자는 msat 단위로 amount를 선택하며 1000 msat는 1 사토시입니다. callback은 pr에 청구서를 반환하고 지갑은 결제 전에 금액이 일치하는지 확인합니다. 주소 조회나 청구서 수신은 정산 완료가 아닙니다. [LNURL — LUD-06 payRequest] [Lightning Address — Implementation guide]

새로운 LUD-16은 _@도메인을 줄인 @도메인과 /_로 끝나는 경로를 선택적으로 허용합니다. 서비스나 지갑의 지원은 필수가 아닙니다. 지원되는 +tag는 경로로 전달되며 서비스는 이를 text/tag 메타데이터로 사용할 수 있습니다. 태그는 새로운 Bitcoin 키나 자동 개인정보 보호 수단이 아닙니다. [Lightning Address — LUD-16]

LUD-16은 metadata에 text/identifier 또는 text/email을 요구하며 text/email은 실제 이메일 주소에 사용합니다. LNURL-pay의 text/plain도 여전히 필수입니다. 표시된 이름과 설명을 도메인 및 의도한 수신자와 비교해야 합니다. 서비스의 주장은 사람의 신원을 독립적으로 검증한 것이 아닙니다. [Lightning Address — LUD-16] [LNURL — LUD-06 payRequest]

서비스는 자체 지갑에서 청구서를 발행하거나 노드에 연결된 브리지 서버를 사용할 수 있습니다. 따라서 형식 자체는 수탁도 자기 보관도 의미하지 않습니다. 브리지에는 기능에 필요한 권한이 필요하며 자동으로 지갑 전체의 무제한 제어가 필요한 것은 아닙니다. endpoint를 제어하는 주체는 지불자가 받는 청구서에 영향을 줄 수 있습니다. [Lightning Address — Implementation guide] [Lightning Address — Bridge server]

지갑은 사용자에게 개인 주소를 제공하지 않으면서도 Lightning Address로 결제할 수 있습니다. 수신하려면 작동하는 웹 서비스, 청구서 생성, 결제를 받을 능력이 필요합니다. 읽기 쉬운 이름 자체가 인바운드 유동성을 만들지는 않습니다. 반복 조회는 제공자에게 수신자와 요청 시점을 드러낼 수 있습니다. [Lightning Address — Implementation guide]

개인 도메인이 있으면 endpoint를 다른 서버로 리디렉션할 수 있습니다. 예를 들어 BTCPay는 HTTP 301을 설명합니다. 타인의 도메인에서는 이름 유지가 제공자에게 달려 있습니다. 시드는 DNS 제어권, 인증서, 계정 연결을 복원하지 않습니다. 서비스 변경 후에는 조회, 목적지 청구서, 수신을 다시 확인하고 기존 연락처가 자동으로 갱신된다고 가정하지 마세요. [BTCPay Server — Address redirection] [Lightning Address — Implementation guide]