Cashu

Cashu는 하나의 공통 민트가 아닙니다. 토큰은 발행자, 단위, 서명 키 세트를 식별합니다. 같은 숫자 금액이 같은 통화나 채무를 뜻하지는 않습니다. 한 민트의 토큰을 다른 민트에서 자동으로 상환할 수 없습니다. V4 형식은 CBOR를 사용하며 한 민트의 증명만 담습니다. [Cashu — NUT-00: Protocol and tokens] [Cashu — NUT-02: Keysets and fees] [Cashu — Project introduction]

기본 프로토콜은 secp256k1 위에서 BDHKE를 사용합니다. 지갑이 비밀을 만들고 해당 점을 블라인딩하면 민트가 서명하고, 지갑은 블라인딩을 제거합니다. 액면가마다 키가 다르므로 민트는 발행하는 증명의 금액을 압니다. 다만 이후 블라인딩이 제거된 형태는 알 수 없어야 합니다. [Cashu — NUT-00: Protocol and tokens]

일반적인 무조건 토큰은 복사할 수 있습니다. 수신자는 swap으로 이를 자신의 비밀을 가진 새 증명으로 교환하고, 민트는 이전 입력을 무효화합니다. UNSPENT는 한 시점의 상태일 뿐 수신자를 위한 예약이 아닙니다. PENDING은 처리 중, SPENT는 이미 사용된 증명을 뜻합니다. [Cashu — NUT-03: Swap tokens] [Cashu — NUT-07: Token state check]

선택적 확장 NUT-12는 서명이 민트 공개키에 대응함을 보이는 DLEQ 증명을 추가합니다. 필요한 데이터가 있으면 수신자는 오프라인에서 검증할 수 있습니다. 하지만 그사이 누가 토큰을 썼는지, 민트가 응답하는지, 준비금이 있는지는 알 수 없습니다. 따라서 오프라인 검증은 swap을 통한 수령을 대체하지 못합니다. [Cashu — NUT-12: Offline signature validation]

NUT-02는 active=false와 선택적인 final_expiry를 구분합니다. 비활성 키 세트는 새 토큰을 발행하지 않지만 그 증명은 계속 입력으로 수락됩니다. 최종 만료 후에는 명세상 민트가 상환할 의무가 없어집니다. 입력 수수료 input_fee_ppk는 증명의 수와 각각의 요율에 따라 합산한 뒤 올림합니다. [Cashu — NUT-02: Keysets and fees]

melt에서 지갑은 외부 결제를 위해 증명을 제출하며, 흔히 Lightning Network를 사용합니다. 견적은 금액, 단위, 유효기간, 필요한 수수료 예비액을 정하고 입력 수수료가 추가될 수도 있습니다. PENDING 상태의 HTTP 200은 결제 확인이 아닙니다. 요청 수락과 최종 결과를 구분해야 합니다. [Cashu — NUT-05: Melting tokens]

블라인딩은 금액, 시간, 네트워크 연결 정보를 없애지 않습니다. NUT-03은 순서가 결제액과 거스름돈의 구분을 드러내지 않도록 요청한 액면가를 정렬하라고 권고합니다. 송신자가 전달한 증명의 상태를 조회하면 민트가 송신자와 수신자를 연결하기 쉬워질 수 있습니다. [Cashu — NUT-03: Swap tokens] [Cashu — NUT-07: Token state check]

NUT-13은 키 세트와 카운터에 따라 seed에서 비밀과 블라인딩 계수를 파생합니다. 버전 01은 HMAC-SHA256, 이전 00은 BIP32를 사용합니다. 복구에는 원래 키 세트와 NUT-09로 받은 서명이 필요하고 이후 사용 상태를 확인해야 합니다. 민트가 협조하지 않으면 seed만으로 서명 복구나 준비금 인출을 보장할 수 없습니다. [Cashu — NUT-13: Deterministic secrets] [Cashu — NUT-09: Restore signatures]