Nostr Web Client

I wonder what would be a better way to solve this issue…

npub.cash will hold many many proofs for its users. If someone wants to withdraw, the server needs to send all those proofs over in a big response.

The obvious choice is to run clean up and consolidation jobs that merge proofs together, but once P2PK is adopted this will no longer work (as the server cannot do anything with the proofs)…

I’ll keep thinking about this, but maybe one of you has a bright idea ✌️ nostr:note1gtyyg5p7njtlhvvzj5gp6dxe5tnx46kd7mc5wmrej3psgxrz8cus7m2k99

Reply to this note

Please Login to reply.

Discussion

calle 1y ago

The problem is qr codes right?

Egge 1y ago

QR codes & token string length. Also overhead on both client and server for things like decoding etc.

water783 1y ago

Is it possible to generate the P2PK token only at the time of the claim/withraw?

Egge 1y ago

That defeats the purpose. At some point all proofs in npub.cash should be locked to the users pubkey to minimize the trust required in the server operator

water783 1y ago

I see, I see, an idea: send a nutzap (nip61 kind 9321) event to the relays when sats are received. This way, your service would require almost no trust, and you wouldn't need to handle token storage or claim operations.

Egge 1y ago

Yes definitely! I am already working on that as an opt-in feature