I am thinking about coining the term “nsac” to refer to a wallet-like thing that can exist on #nostr holding your valuable things, such as ecash tokens. I have already implemented a prototype #cashu ecash wallet which looks to be promising. 

So you would have:
#npub - your identity
#nsec - your private key
#nsac - your valuables 

Your #nsac could be the same as your #nsec but better case is to generate as many #nsacs as required.

Happy to hear feedback!


For reference, what a ‘sac’ is in the biological sense:

A **sac** is a biological term referring to a pouch or cavity in an organism that is typically enclosed and may contain fluid, air, or other substances. Sacs can serve various functions depending on their location and role in the body, such as protecting a developing embryo, facilitating the exchange of gases in the lungs, or reducing friction between moving parts in joints 

 looks too similar to nsec imo 

 Agree. But it rolls off tongue well. Another possibility is #npurse or #npocket 

 Agree. What about #nsat 

 I like that! 

 How does a nsac differ from nsec? Is your prototype public? 

 The code is here. It’s called ‘safebox’ for now. The code is still pretty gross, but it works. I got the main pieces working (barely) - minting proofs, storing in events, retrieving and melting for lightning payment. Lots of work ahead. 

https://github.com/trbouma/safebox 

 Are only the proofs stored on nostr not quotes etc?  

And it's just the one replaceable event so each time a transaction is made that event is replaced removing spent proofs and adding new unspent proofs? 

Cc nostr:nprofile1qqsxkxud4s60l3sagexlamcquj5y5czwzuh0vwglkc5jj0t0zenpfrqpz4mhxue69uhk2er9dchxummnw3ezumrpdejqzrthwden5te0dehhxtnvdakqzyrhwden5te0dehhxarj9emkjmn9z82hk2 

 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. 

 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.  

 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. 

 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 

 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. 

 🤣 nsac is much more user friendly over nutsack 🤣 

  https://image.nostr.build/e1040c901546fcbc86a5d90cadc2c60247d6a5b440c7a1253a8fa5f2f0776ae0.jpg  

 LOL 

 I’ll take 7 

 @vrod merch store 

 @vrod 

 really want a damoose shirt first 😍  

 It’s going to happen in the fall I promise. I’m just finalizing designs. Will share at Nostriga 

 Where do I order these? Just the thing to wear when picking the newspaper off the front lawn every morning. 

 Imho this is much better use of nostr + ecash than nutsack is.
I've read he specs and it seems to me that nutzaps make the transactions  effectively always linkable. I understand that maybe you don't care about privacy with nutzaps but then in that case why use ecash in the first place. 

 Nostr can offer a use case of storing ecash somewhere safe where it's much difficult to lose it. This whould make all the wallet recovery shenanigans obsolete.
 

 In my implementation I am encrypting and obfuscating absolutely everything, including the ‘d’ tags. I also might implement zaps differently, when I get there. Right now I am focused on building a component that can drop into any Lightning address provider, so they can take care of the zaps there. Much to do! 

 Posting this stuff on stacker news. The freaks deserve to know.