Rusty Russell은 Lightning Network 노드를 운영하는 프로그램 Core Lightning에 크게 기여한 오픈소스 개발자입니다. 공통 BOLT 명세를 만드는 데도 참여했고, 재사용 가능한 제안에서 새로운 결제 요청을 받아오는 BOLT 12를 꾸준히 추진했습니다. Lightning은 결제 채널을 통해 bitcoin 결제를 전달하는 네트워크입니다.
큰 프로젝트도 조용한 시도로 시작하곤 합니다. Blockstream의 2026년 6월 9일 회고 글은 Russell이 2015년 5월 26일 남긴 첫 커밋을 소개합니다. 채널 개설 메시지를 만드는 작은 도구였습니다. 커밋은 코드 이력에 기록된 변경입니다. 초기 실험은 Core Lightning으로 자랐고, Russell은 프로그램과 테스트, 다른 개발자의 성장에도 기여했습니다. 글은 십일 년 뒤 그의 떠남도 설명합니다. 그렇다고 앞으로의 모든 오픈소스 기여를 끝낸다는 발표는 아니며, 과거의 지도적 역할이 네트워크 전체에 대한 영구 권한이 되는 것도 아닙니다. [1]
카페와 고객이 다른 프로그램을 쓰는 상황을 생각해 보세요. 결제하려고 같은 공급자를 고를 필요는 없어야 합니다. 메시지 형식과 의미에 대한 공통 규칙이 필요합니다. BOLT 명세는 Lightning의 이런 통신을 설명합니다. Russell은 공동 명세 개발 과정을 이끌고, 서로 다른 구현이 함께 작동하는 상호운용성을 지원했습니다. 공개 저장소는 제안과 의견을 받습니다. 하지만 중요한 기여자도 혼자서 모든 노드에 변경을 강요할 수는 없습니다. 공통 규칙은 실제 소프트웨어와 사용에 반영되어야 합니다. [1] [2]
두 프로그램이 같은 문단을 다르게 해석할 수 있습니다. Russell이 만든 lnprototest는 시나리오를 작성하고 프로토콜 메시지에 대한 반응을 시험할 수 있는 Python 도구를 제공합니다. 프로젝트 안내 문서 README는 모의 실행기와 실제 구현에 대한 테스트를 구분합니다. 모의 실행은 테스트 준비에 유용하지만, 성공했다고 실제 노드의 동작까지 증명되지는 않습니다. 무엇을 실행했고 어떤 상황을 확인했는지가 중요합니다. 시나리오 묶음을 통과해도 모든 가능한 결함에 대한 완전한 감사를 마쳤다는 뜻은 아닙니다. [3]
BOLT 12를 사용하면 카페는 QR 코드 등으로 재사용 가능한 제안을 게시할 수 있습니다. 고객 지갑은 이를 바탕으로 invoice_request를 보내고, 해당 결제 정보가 담긴 인보이스, 즉 결제 요청을 받습니다. 실제 결제는 그다음입니다. 제안은 반복해서 사용하되 인보이스는 각각 받는 구조입니다. 이미 사용한 인보이스 하나를 매번 새로운 구매 요청으로 간주한다는 뜻이 아닙니다. 제안, 요청 메시지, 인보이스를 구분하면 서로 다른 결제를 섞지 않으면서 편리하게 이용할 수 있습니다. [4]
Core Lightning은 이 구분을 명확히 보여 줍니다. fetchinvoice 명령은 제안 발행자에게 연락해 인보이스를 가져옵니다. changes 항목에는 금액이나 설명처럼 원래 제안과 다른 부분이 표시될 수 있습니다. 성공 응답을 받았다고 돈이 보내지는 것은 아닙니다. 카페에서 계산서를 받고 무엇에 얼마를 내는지 확인하는 단계와 비슷합니다. 지갑은 반환된 조건을 처리하고 결제를 별도로 시작해야 합니다. 요청을 받아오는 작업의 완료와 결제 완료를 혼동해서는 안 됩니다. [5]
pay 문서는 complete, pending, failed를 구분합니다. 각각 완료, 대기, 실패이며 대기 중이라는 것은 결제 성공이 아닙니다. amount_msat는 받는 쪽이 받은 금액이고, amount_sent_msat는 수수료를 포함해 보낸 총액입니다. msat는 millisatoshi로, satoshi의 천분의 일입니다. 따라서 고객은 카페가 받은 액수보다 수수료만큼 더 쓸 수 있습니다. 문서는 이미 pay를 사용 중단 예정인 인터페이스로 표시하고 xpay로의 전환을 설명합니다. 여기서는 상태와 금액을 설명할 뿐 특정 버전 설치를 안내하지 않습니다. 결과는 실제 사용하는 프로그램에 맞게 읽어야 합니다. [6]
카페가 돈을 돌려줄 때 원래 결제를 되감지는 않습니다. BOLT 12는 반대 방향도 설명합니다. 가게가 보내려는 금액을 알리면 고객이 인보이스를 제공하고, 가게는 지급할 노드의 식별자인 invoice_node_id를 확인한 뒤 새 결제를 보냅니다. 원래 송금을 취소하는 것도, 자동으로 환불 권리를 만드는 것도 아닙니다. 프로토콜은 실행 방법을 제공합니다. 환불 이유와 조건은 당사자들이 별도로 정해야 합니다. [4]
분쟁이 생기면 증명이 정확히 무엇을 보여 주는지 알아야 합니다. BOLT 12는 결제 요청의 해시에 대응하는 비밀값 preimage로 인보이스가 지불되었음을 증명할 수 있다고 설명합니다. 하지만 그 값이 공개되면 다른 사람도 제시할 수 있으므로 누가 송금했는지 단독으로 밝혀 주지는 않습니다. 요청에 포함된 키는 누가 인보이스를 요청했는지 증명하는 데 쓰일 수 있지만, 그 사람의 법적 신원까지 자동으로 확인하지는 않습니다. 지불된 인보이스, 키의 통제권, 고객 신원은 서로 다른 정보입니다. [4]
더 정확히 이해하려면 이 항목과 함께 다음도 읽어 보세요 Andrew Poelstra, Tadge Dryja, Lightning Network. 다음 항목에서도 이 글을 참조합니다 Andrew Poelstra, Tadge Dryja.