BOLT 12

수취인이 offer를 공개하면 송금인이 invoice_request를 보내 새 invoice를 받습니다. 그다음 결제할 수 있습니다. 제안 하나를 여러 사람이나 반복 결제에 쓸 수 있습니다. fetchinvoice 등으로 청구서를 받아도 결제되지는 않으며 공개 QR은 상시 인출 권한이 아닙니다. [BOLT 12 — Negotiation protocol] [Core Lightning — Fetching an invoice] [BOLT 12 — Project overview]

BOLT 12는 필드를 TLV로 저장합니다. 텍스트 제안은 lno, 요청은 lnr 접두사를 사용하며 문자 집합은 Bech32와 비슷하지만 끝 체크섬이 없습니다. Offer 자체는 서명되지 않습니다. 요청과 청구서의 BIP340 Schnorr 서명은 필드의 Merkle 루트를 검증하며 판매자의 신원을 검증하지 않습니다. [BOLT 12 — Negotiation protocol]

지갑은 invoice_request에서 invoice로 복사된 필드, 금액, 체인과 서명을 비교합니다. invoice_node_id는 offer_issuer_id 또는 해당 마지막 blinded_node_id와 일치해야 합니다. 무관한 유효 서명만으로는 부족합니다. Merkle 구조는 필드의 선택적 증명을 허용하지만 서명 조건을 임의로 바꾸지는 못합니다. [BOLT 12 — Negotiation protocol]

Bitcoin invoice_amount는 msat 단위이며 1000 msat는 1 satoshi입니다. offer_currency로 ISO 4217의 다른 통화를 지정할 수 있고 USD는 센트 단위입니다. 수량과 발행 시 환산이 가격에 영향을 줍니다. invreq_amount가 정해져 있으면 일치해야 하고 아니면 허가된 범위를 확인합니다. [BOLT 12 — Negotiation protocol] [Core Lightning — Fetching an invoice]

offer_paths는 요청 메시지를, invoice_paths는 결제를 운반합니다. 현재 invoice에는 수취인까지 직접 가더라도 blinded paths와 해당 invoice_blindedpay가 있어야 합니다. 경로 블라인딩은 구조 노출을 줄이지만 완전한 익명성, 가용성이나 유동성은 보장하지 않습니다. 청구서 요청에 일반 HTTPS 결제 서버는 필요하지 않습니다. [BOLT 12 — Negotiation protocol] [BOLT 4 — Route blinding]

offer_absolute_expiry는 제안 사용을 제한합니다. invoice_created_at과 invoice_relative_expiry는 특정 청구서를 제한하며 후자가 없으면 7200초입니다. 재사용 제안이 청구서에 무한한 유효기간을 주지는 않습니다. 알 수 없는 짝수 필수 기능 비트는 거절하고 홀수 비트는 무시합니다. [BOLT 12 — Negotiation protocol]

환불할 때 돈을 보내려는 쪽이 offer 없는 invoice_request를 공개할 수 있습니다. 받을 쪽은 자신의 invoice로 응답하며 송금인은 필요하다면 프로토콜 밖에서 의도한 수취인을 확인해야 합니다. 이는 원래 결제 취소가 아닌 새 결제입니다. 요청 스캔만으로 권리나 결제 승인을 증명하지 않습니다. [BOLT 12 — Negotiation protocol]

Invoice, 결제 상태와 해당 preimage를 보관합니다. Preimage는 청구서 정산을 증명하지만 어떤 사람이 냈는지는 단독으로 밝히지 못합니다. 응답을 잃으면 다시 내기 전에 상태를 확인합니다. 제안 지원은 모든 확장이나 자동 정기 결제를 지원한다는 뜻이 아닙니다. 수신, 송신과 앱 권한을 따로 확인하세요. [BOLT 12 — Negotiation protocol] [Core Lightning — Fetching an invoice]