BOLT12 오퍼

오퍼는 지불된 뒤에도 그대로 남는 지불 요청이므로, 한 번 인쇄한 코드 하나로 모든 고객을 처리할 수 있습니다. 오퍼에는 서명도 체크섬도 없으며, 그 필드들은 TLV 유형 2부터 22까지를 차지합니다. 이는 저사양 휴대폰 카메라로도 읽을 수 있도록 의도적으로 짧게 설계된 것입니다. 비트코인을 받는 입장이라면, 이것이 한 번 인쇄해 두는 코드와 그 코드가 발행하는 인보이스(7200초 후에 만료됩니다) 사이의 차이입니다.

작동 방식

BOLT12 오퍼는 사람이 읽을 수 있는 접두사 lno, 구분 기호 1, 그리고 이어서 이 레코드들을 순서대로 담은 bech32 스타일 문자들로 작성된 유형-길이-값 레코드의 나열입니다.

끝에는 6자리 체크섬이 없습니다. 명세는 QR 코드에는 자체 체크섬이 있으며, 손상된 오퍼는 지불 유실이 아니라 파싱할 수 없는 문자열을 만들어 낸다는 이유로 체크섬을 제외합니다. 긴 오퍼는 문자 수 제한이 있는 텍스트 필드에 붙여넣어도 살아남도록 더하기 기호와 그 뒤의 선택적 공백으로 나눌 수 있으며, 읽는 쪽은 디코딩 전에 더하기 기호와 공백을 제거해야 합니다. 쓰는 쪽은 모두 소문자나 모두 대문자를 사용해야 하며, QR 코드에는 대문자를 선택하는 것이 좋습니다.

필드 자체에는 번호가 붙습니다. offer_chains는 2, offer_metadata는 4, offer_currency는 6, offer_amount는 8, offer_description은 10, offer_features는 12, offer_absolute_expiry는 14, offer_paths는 16, offer_issuer는 18, offer_quantity_max는 20, offer_issuer_id는 22입니다. 쓰는 쪽은 1부터 79까지의 유형 안에 머물러야 하며, 1000000000부터 1999999999까지의 두 번째 범위는 실험용으로 남겨 둡니다. 그 목록에 서명은 없으며, 이는 의도된 것입니다. 서명하면 아무 이득도 없이 문자열만 길어지는데, 서명이 아닌 모든 필드는 뒤따르는 요청에 복사되므로 변조된 오퍼는 그저 인보이스를 만들어 내지 못할 뿐입니다.

그다음 지불에는 메시지 두 개가 더 필요합니다. 지갑이 접두사 lnr을 붙인 invoice_request를 어니언 메시지로 보내며, 이해하지 못하는 필드를 포함한 모든 오퍼 필드를 복사하고 그 결과에 머클 루트에 대한 BIP340 서명을 붙입니다. 발행자는 서명된 인보이스로 응답합니다. 머클 구성은 각 필드의 리프를 논스 리프와 짝짓는데, 이것이 지불하는 쪽이 나중에 분쟁 중인 인보이스의 필드 하나를 이웃 필드를 노출하지 않고 공개할 수 있게 해 줍니다. 문자열 전체에 대한 BOLT11 서명으로는 할 수 없는 일입니다.

이 세 메시지 중 두 개는 환불과 현금 자동 입출금기를 위해 반대 방향으로 작동합니다. 판매자가 보내려는 금액을 명시한 invoice_request를 게시하면, 받는 쪽이 인보이스로 응답하고, 판매자는 지불 전에 invoice_node_id를 확인합니다.

비트코인을 구매할 때 이것이 중요한 이유

오퍼는 대금을 받는 방법을 게시하는 방식을 바꾸며, 대금을 받는 데 드는 비용은 전혀 바꾸지 않습니다.

이 사이트의 Phoenix 리뷰를 보십시오. ACINQ는 이용자가 직접 알아내게 두지 않고 수수료 표를 게시합니다. 라이트닝 네트워크로 보내면 0.4%에 4사토시를 더한 금액이 들고, 이미 인바운드 유동성이 있으면 받는 것은 무료이며, 지갑이 자리를 만들기 위해 온체인으로 가야 할 때 받는 것은 채굴 수수료에 1%를 더한 금액이 들고, 새 채널은 1,000사토시입니다. 인보이스 대신 오퍼를 건네는 것은 그 숫자 중 어느 것도 건드리지 않습니다. 없애는 것은 지불하는 사람마다 새 코드를 발행하는 단계이며, 누군가 유동성 비용을 지불하는 단계가 아닙니다.

프라이버시 이득은 실재하지만 좁습니다. 라이트닝 주소는 인보이스 요청을 모두 누군가의 도메인에 있는 웹 서버로 라우팅하며, 그 운영자는 금액과 시점을 봅니다. 오퍼는 요청을 라이트닝 네트워크를 통해 어니언 메시지로 라우팅하며, offer_paths 덕분에 채널이 모두 비공개인 노드도 노드 ID를 전혀 공개하지 않고 연결 가능한 상태로 남을 수 있습니다. 그것으로 얻지 못하는 것은 자기 공급자로부터의 프라이버시입니다. 이 사이트의 Phoenix 리뷰는 ACINQ의 FAQ가 지불의 최종 목적지와 금액을 안다고 명시하고 있음을 인용합니다.

실무적인 경고는 붙여넣기에 관한 것입니다. 거래소의 출금란은 라이트닝 인보이스를 요구하며, lno1 문자열은 인보이스가 아닙니다. 이 사이트에 등재된 63건의 거래소 레코드 중 하나인 Strike는 라이트닝 네트워크 네이티브이며 100개국이 넘는 국가로의 송금에 자체 수수료를 추가하지 않는데, 바로 그런 흐름에서 두 형식이 혼동됩니다. 이 사이트의 41개 지갑 리뷰나 63건의 거래소 레코드 중 현재 오퍼 지원을 기능으로 문서화한 것은 없으므로, 당연하게 여기지 말고 본인 지갑의 릴리스 노트에서 확인해야 할 사항으로 다루십시오.

모자 노점의 오퍼와 그것이 만들어 내는 인보이스

25 달러에 모자를 파는 노점이 offer_currency를 USD로, offer_amount를 2500으로 설정한 오퍼를 작성합니다.

이는 비트코인이 아닌 통화에 대한 명세의 규칙입니다. 세 글자 ISO 4217 코드를 쓰고, 금액은 ISO 4217 지수로 조정한 통화 단위로 표시하며, 달러의 경우 이는 센을 뜻합니다. offer_amount를 설정하는 것만으로 offer_description이 필수가 되는데, 특정 상품에 대한 대금을 청구받는 지불하는 쪽은 그것이 무엇이었는지 알아야 하기 때문입니다. 모자가 세 개 남아 있으면 offer_quantity_max는 3이고, 노점에 고정 한도가 없으면 0입니다. 1이라는 값도, 보기에는 어색하지만, 재고 시스템이 마지막 품목에 대해 특별 처리를 할 필요가 없도록 명시적으로 허용됩니다. 명세가 도메인을 먼저 쓰고 공백 뒤에 원하는 안내 문구를 쓰도록 요구하므로, offer_issuer는 hats@example.com Hat Stall로 표시될 수 있습니다.

지갑이 이를 읽고 25 달러를 견적한 뒤, 모자 두 개에 대해 invreq_quantity를 2로 설정하고 invreq_payer_id와 선택적으로 invreq_payer_note를 담은 invoice_request를 보냅니다. 그러면 지불 해시, 생성 타임스탬프, 하나 이상의 블라인드 경로, 그리고 경로별로 기본 수수료, 비례 수수료, CLTV 델타, 전달할 가장 작은 HTLC와 가장 큰 HTLC를 포함한 수수료 견적이 담긴 인보이스가 돌아옵니다. 여기서 두 가지 규칙이 이용자를 보호합니다. 지갑은 0부터 159까지 범위의 필드 중 어느 하나라도 보낸 내용과 일치하지 않으면 인보이스를 거부해야 하며, 밀리사토시 금액이 오퍼가 제시한 달러 견적과 크게 다르면 경고해야 합니다. 발행자가 invoice_relative_expiry를 설정하지 않는 한, 인보이스는 생성된 뒤 7200초가 지나면 거부되어야 합니다.

BOLT12 오퍼 vs BOLT11 인보이스

BOLT12 오퍼는 지불 요청에 대한 요청이고, BOLT11 인보이스는 지불 요청입니다.

BOLT12 문서는 선행 기술에 대한 여덟 가지 불만으로 시작하며, 지불하는 쪽이 체감하는 것은 다음과 같습니다. BOLT11 인보이스는 전체로 서명되므로, 필드 하나를 증명하려면 모든 필드를 드러내야 합니다. 명세의 판단에 따르면 사람이 읽을 수 있는 금액 표기는 문제가 많았습니다. p 승수는 자주 잘못 처리되었고, 피코비트코인은 사토시보다 세기 어렵습니다. payment_secret은 인보이스가 지불하는 쪽과 받는 쪽 사이에서 비공개로 유지되는 동안에만 탐색을 막았는데, 공개된 인보이스는 그렇지 않습니다. 그리고 명세 자체의 말로, 인보이스는 사용자별로 주어져야 하며 같은 사용자에 대해 두 번의 지불 시도가 이루어지면 실제로 위험합니다. 오퍼는 인보이스가 아니라는 사실만으로 이 네 가지에 모두 답합니다.

BOLT12 오퍼 vs 라이트닝 주소

BOLT12 오퍼는 스스로 완결된 문자열이고, 라이트닝 주소는 누군가의 서버가 이용자를 대신해 해석해 주는 이름입니다.

둘 다 재사용할 수 있기 때문에 혼동됩니다. 주소는 도메인, 인증서, 그리고 서비스를 계속 운영하는 운영자에 의존하며, 이 셋 중 어느 하나라도 문제가 생기는 날 작동을 멈춥니다. 오퍼는 양쪽 노드가 어니언 메시지를 주고받는 것에만 의존하며 다른 것에는 의존하지 않아 실패 지점이 더 적습니다. 다만 본인 지갑이 이를 지원하는지 당연하게 여기지 말고 확인해야 합니다. 주소는 소리 내어 말할 수 있다는 점에서 앞섭니다. 긴 lno1 문자열은 QR 코드이지 마이크에 대고 읽는 것이 아닙니다.