TL;DR

• 지난 글에서 말한 “라이트닝 인보이스는 보통 한 번의 결제를 위해 사용된다”는 설명은 일반적인 BOLT 11 인보이스를 기준으로 한 표현이다.
• 하지만 라이트닝에는 더 유연한 결제 요청 방식이 논의·구현되어 왔다. 대표적인 흐름이 BOLT 12 Offers다.
• BOLT 12의 핵심은 수취인이 매번 완성된 인보이스를 먼저 만들어 보내는 대신, 재사용 가능한 offer를 제시하고 결제자가 그 offer를 바탕으로 실제 invoice를 받아오는 구조다.
• Core Lightning은 오래전부터 offers 관련 기능을 적극적으로 실험·지원해 온 구현체 중 하나다.
• 사용자는 “QR 코드 하나로 여러 번 받을 수 있나?”보다 한 단계 더 깊게, 누가 invoice를 만들고, 어떤 정보가 언제 공개되며, 결제 요청이 어떻게 갱신되는가를 이해해야 한다.

1. 왜 이 주제가 002번 글의 다음 이야기인가

002번 글에서는 라이트닝 인보이스를 “결제 요청서”로 설명했다.

일반적인 BOLT 11 인보이스에서는 수취인이 먼저 인보이스를 만들고, 결제자는 그 인보이스를 스캔하거나 붙여넣어 결제를 시도한다.

이때 중요한 특징은 다음과 같다.

• 인보이스에는 payment hash가 들어간다.
• 보통 만료 시간이 있다.
• 일반적인 사용에서는 한 번의 결제를 위해 발행된다.
• 결제 성공은 수취인이 올바른 preimage를 공개하는 조건과 연결된다.

하지만 여기서 “보통”이라는 단어가 중요하다.

라이트닝 생태계에는 반복 결제, 고정 QR, 후원 링크, 매장 결제, 구독형 결제처럼 매번 새 인보이스를 사람이 직접 전달하기 불편한 상황이 있다.

그래서 다음 질문이 생긴다.

“라이트닝에서도 온체인 주소처럼 하나의 결제 요청을 여러 번 쓸 수 있을까?”

BOLT 12 Offers는 이 질문에 대한 대표적인 답변 중 하나다.