LNURL

안나가 창작자를 후원하는 코드, 바우처를 사용하는 코드, 웹사이트에 로그인하는 코드를 차례로 스캔한다고 생각해 보세요. 휴대전화를 쓰는 방식은 비슷하지만 매번 다른 행동을 승인합니다. LNURL은 payRequest로 결제를, withdrawRequest로 출금을, login으로 로그인을 구분합니다. 각 절차는 LUD 문서에 설명되어 있습니다. 이는 앱 사이에서 선택적으로 채택하는 약속이지 Bitcoin 규칙의 변경이 아닙니다. 지갑이 한 절차를 지원한다고 다른 절차도 모두 지원하는 것은 아닙니다. [1] [7]

payRequest에서는 서비스가 설명과 허용 금액 범위를 돌려줍니다. 안나는 도메인, 즉 서비스의 웹 주소를 확인하고 설명을 읽은 다음 후원 금액을 고릅니다. 조건에 동의하면 지갑이 구체적인 BOLT 11 Lightning 청구서를 요청하고, 결제하기 전에 금액이 선택한 값과 같은지 확인합니다. 내부적으로는 callback 주소, minSendable·maxSendable 한도, metadata 설명을 사용합니다. 금액은 amount로 보내고 청구서는 pr로 받습니다. 금액 단위는 satoshi의 천분의 일인 msat입니다: 1000 msat = 1 sat. 다른 사람도 같은 공개 QR을 사용할 수 있지만, 스캔했다는 사실만으로 결제가 완료되지는 않습니다. [3]

withdrawRequest에서는 방향이 반대입니다. 안나는 서비스에 돈을 내는 대신 그곳의 잔액을 출금하려고 합니다. 따라서 안나의 지갑이 수취용 청구서를 만들고 서비스가 이를 결제합니다. 서비스는 k1 식별자, callback 주소, msat 단위의 minWithdrawable·maxWithdrawable 한도를 제공하며, 승인 뒤 지갑이 pr로 청구서를 제출합니다. OK 응답은 서비스가 요청을 받았다는 뜻이지 안나가 이미 돈을 받았다는 뜻이 아닙니다. 지갑은 실제 입금을 계속 기다립니다. 출금 코드는 가진 사람이 사용할 수 있는 바우처처럼 작동할 수 있으므로 일반적인 결제 수신 연락처처럼 공개하지 마세요. [4]

다른 사이트에서 안나는 LNURL-auth를 선택합니다. 지갑은 도메인과 tag login이 붙은 요청의 목적을 보여줍니다. 안나가 동의하면 해당 도메인 전용 개인키 linkingPrivKey로 일회성 확인 요청 k1에 서명합니다. 서비스에는 서명과 그에 대응하는 공개키 linkingKey를 보내 서명을 검증할 수 있게 합니다. 개인키는 보내지 않습니다. 서비스는 같은 키의 소유자가 돌아왔음을 알 수 있지만, 이 확인만으로 실제 신원까지 알게 되는 것은 아닙니다. 지갑은 키를 파생하는 출발점이 되는 비밀값 seed나 복구 단어인 Seed Phrase를 서비스에 보내지 않습니다. 기술적으로는 secp256k1 곡선의 ECDSA 서명을 사용합니다. action은 가입, 로그인, 계정 연결 또는 다른 권한 승인을 뜻할 수 있으므로 확인 내용을 끝까지 읽어야 합니다. 이 요청에 서명하는 것 자체는 Bitcoin 결제가 아닙니다. [5]

요청, 서비스 응답, 실제 자금 이동은 서로 다른 단계입니다. 연결이 끊기면 안나는 먼저 지갑에서 원래 결제를 확인합니다. 새 청구서로 다시 시도하면 또 한 번 결제될 수 있습니다. 선택 사항인 LUD-21은 특정 청구서를 조회할 verify 주소를 추가합니다. settled true는 정산되었다는 보고이고 settled false는 아직 정산되지 않았다는 보고입니다. OK만으로는 충분하지 않습니다. 응답에는 결제에 대응하는 원래의 비밀값인 preimage가 포함될 수 있습니다. 지갑은 이 값에서 확인용 값인 해시를 계산하고, 올바른 청구서에 기록된 결제 해시와 비교합니다. 아무 비밀값이나 받으면 되는 것이 아니라 바로 그 결제에 대응하는 값이어야 합니다. 결과 조회가 서비스의 가동이나 수신 지갑까지 돈을 보낼 경로 용량인 인바운드 유동성을 확보해 주지는 않습니다. [6] [3] [4]

HTTPS는 지갑과 서비스 사이의 전송을 보호하지만 서비스 자체로부터 정보를 숨기지는 않습니다. 서비스는 요청과 시각, 반복 사용을 관찰할 수 있습니다. 로그인에는 전체 도메인 이름도 중요합니다. 하위 도메인이 바뀌면 linkingKey가 달라져 사이트가 다른 사용자로 인식할 수 있습니다. 앱마다 키를 파생하는 방식이 달라 다른 지갑으로 옮겨도 같은 로그인을 복구한다는 보장이 없습니다. 중요한 변경 전에는 해당 계정의 접근 권한을 어떻게 복구할지 확인하세요. LNURL 자체는 누가 bitcoin의 키를 보관하는지 정하지 않습니다. 그것은 지갑과 서비스에 달려 있습니다. [2] [5]

기본 LUD-01은 HTTPS 또는 onion URL을 Bech32로 나타냅니다. 이는 인코딩이지 주소 암호화나 BOLT 11 청구서가 아닙니다. 지갑은 링크에서 직접 tag를 읽거나, 데이터를 가져오는 GET 웹 요청을 보내 JSON 응답에서 작업 종류를 확인합니다. JSON은 앱이 읽을 수 있도록 데이터에 이름과 구조를 부여하는 형식입니다. 따라서 QR 이미지 자체가 수신자의 신원을 증명하지는 않습니다. 링크 내용과 이후 표시되는 도메인, 작업, 조건이 중요합니다. [2]

결제 절차에서 metadata는 JSON 배열을 담은 문자열입니다. text/plain 설명은 필수이고 다른 유형은 선택 사항입니다. 사용자가 무엇에 동의하는지 알도록 지갑은 설명을 도메인 및 금액과 함께 보여줘야 합니다. 기본 LNURL은 HTTP 상태 코드만 보는 것이 아니라 JSON 응답 본문을 해석합니다. 따라서 서버가 응답한다고 요청이 성공한 것은 아닙니다. 본문에 ERROR가 있을 수 있습니다. 마찬가지로 pr에서 받은 청구서도 아직 결제된 것은 아닙니다. 앱이 이러한 서로 다른 정보를 하나의 녹색 체크 표시로 뭉뚱그려서는 안 됩니다. [2] [3]