Keysend

Keysend는 수취인이 비밀을 골라 그 해시를 인보이스에 게시하는 일반적인 라이트닝 흐름을 뒤집습니다. 송신자의 비밀은 커스텀 TLV 레코드 5482373484에 실리는데, 이는 짝수 번호이므로 BOLT 1은 keysend를 모르는 노드가 이를 무시하지 않고 거부하도록 정합니다. 왕복 없이 노드 공개 키만으로 결제할 수 있지만, 인보이스가 남겼을 암호학적 영수증을 포기하게 됩니다.

작동 방식

Keysend는 BOLT 1 규칙 중 더 엄격한 쪽에 기대고 있습니다. 판독기는 알 수 없는 홀수 유형의 TLV 레코드를 버리고 계속 진행하지만, 알 수 없는 짝수 유형을 만나면 전체 스트림을 실패시켜야 합니다.

2^16보다 작은 유형 식별자는 BOLT를 위해 예약되어 있고 2^16부터는 커스텀 레코드에 자유롭게 쓸 수 있으며, BOLT 1은 일반 노드가 데이터를 무시해야 할 때는 홀수를, 거부해야 할 때는 짝수를 고르라고 합니다. bLIP-3은 5482373484가 최초의 lnd 구현에서 무작위로 선택되었음을 기록하는데, 끝자리가 4이므로 keysend는 거부하는 쪽에 놓였습니다. 그래서 기능 비트가 필요합니다. 수용하는 노드는 54/55 비트를 광고하며, 이는 keysend라 불리고 var_onion_optin에 의존합니다. bLIP-3은 송신자가 무작정 보내 실패를 지켜보기보다 이 비트를 찾아야 한다고 말합니다.

bLIP-3에 정리된 송신자의 작업은 짧습니다. 암호학적으로 안전한 무작위 32바이트 값을 생성해 그 레코드에 넣고, update_add_htlc의 payment_hash를 그 값의 SHA-256으로 설정합니다. 프리이미지를 재사용해서는 안 되며, 이미 지불한 인보이스의 프리이미지도 재사용해서는 안 됩니다. 패킷은 각 홉에서 난독화되므로 한 홉은 다음 홉의 주소만 복원할 수 있고 그 사이의 누구도 레코드를 보지 못합니다. 최종 노드는 찾은 값을 해시해, 수락하도록 요청받은 해시와 대조한 뒤 정산합니다.

거부는 의도적으로 조용히 이루어집니다. BOLT 4에는 노드가 이해하지 못한 페이로드에 대한 정해진 응답인 PERM|22 invalid_onion_payload가 있으며, 이는 문제가 된 TLV 유형까지 지목할 수 있습니다. bLIP-3은 수취인에게 대신 PERM|15 incorrect_or_unknown_payment_details를 반환하라고 요청하므로, 거부된 keysend는 노드가 발행한 적 없는 결제 해시와 구별되지 않습니다.

확인할 수 있는 곳

Keysend는 팟캐스트 부스트를 떠받치는 기반 구조입니다.

bLIP-10은 원래 Breez가 선택한 두 번째 레코드인 7629169 유형을 정의하며, keysend 결제에 첨부되는 단순한 JSON 덩어리를 담습니다. 팟캐스트 제목, 에피소드, 초 단위 재생 위치를 담는 ts, boost 또는 stream 값이 설정되는 action, 그리고 선택적인 message이며, 이것이 부스트어그램을 만듭니다. 분 단위 스트리밍은 seconds_back을 60으로 설정합니다. 그 레코드는 홀수이므로 bLIP-10은 이전 버전과의 호환성을 가볍게 넘깁니다. 메타데이터를 무시하는 호스트도 사토시는 그대로 받기 때문입니다. 이 레코드가 존재하는 이유는 keysend만으로는 수취인에게 아무것도 알려주지 않으므로 앱이 프로그램 이름을 직접 밝혀야 하기 때문입니다.

같은 공백 때문에 keysend는 구매 경로에 들어오지 못합니다. 거래소 출금은 인보이스를 건네거나 인보이스를 요구합니다. 플랫폼이 결제를 계좌에 연결해야 하기 때문입니다. 그래서 이 사이트에 등재된 63개 거래소 기록과 41개 지갑 리뷰 어디에도 그 단어는 나오지 않습니다. bLIP-3은 그 대가를 솔직하게 밝힙니다. keysend가 더 나은 설계의 자발적 결제, 즉 offers와 AMP로 대체되리라 예상하며, 그동안 포기하는 것들인 지불 증명과 최종 CLTV 만료에 대한 수취인의 발언권을 나열합니다.

Keysend vs 라이트닝 주소

Keysend와 라이트닝 주소는 모두 인보이스를 건네지 않은 상대에게 결제할 수 있게 하지만, 인보이스를 진정으로 건너뛰는 것은 둘 중 하나뿐입니다. user@example.com을 입력하면 지갑이 HTTPS 조회를 수행해 새 BOLT11 인보이스를 받아오므로, 프리이미지는 여전히 수취인이 고른 것이고 사용자는 수취인의 서명으로 뒷받침되는 영수증을 손에 쥐게 됩니다. Keysend는 웹 요청도 서버도 필요하지 않으며 33바이트 노드 공개 키와 그곳으로 가는 경로만 있으면 되고, 비밀이 처음부터 사용자의 것이었으므로 나중에 지불을 증명할 것은 아무것도 남지 않습니다. 지불했다는 사실을 보여줘야 할 일이 있을 수 있다면 인보이스를 택하십시오.