Nostr Web Client

Just the proofs for now. The deposit command polls until the quote is paid. As for the proofs, they are removed immediately after being spent, and I swap all remaining proofs into a single event. To keep the token amount low, I calculate the least power of 2 summand and swap everything into new outputs. For example if I have 1,2,4,8,1 across 3 events, those get swapped into 16 and 1 event. The old events are deleted.

thesimplekid 1y ago

What are you considering spent? When the proof is sent from one person to the other. Or when the receiver actually claims it from the mint.

Reply to this note

Please Login to reply.

Discussion

Tim Bouma 1y ago

Right now, I have it receiving and sending Lightning payments only. My initial motivation is to first build a persistent back end for my custodial Lightning payment service.

The next step is to receive tokens directly, likely through a DM. Once I get all of the basic mechanics worked out, I will build in the multi-mint capability. I was happy to get all of the swapping and consolidation working. That was a big job.

David Caseria 1y ago

Have you looked into NIP-60 yet? Your idea sounds more general purpose, but we are working on a cashu-specific one: https://github.com/nostr-protocol/nips/pull/1369

Tim Bouma 1y ago

Yep. NIP-60 was my starting point, but I realized I could do more general stuff. My primary motivation is to swap out an internal custodial wallet component I built that relies on a Postgres database. I realized I could use a relay, and with better security (removing my database as a honeypot of data). I implemented the proof storage as per the NIP and added in some lightning capabilities.