The stack handles on-chain privacy cleanly but the wallet service is still a surveillance point – a third-party operator accumulates a complete payment graph regardless of what BIP-352 does on-chain. Posted a design note on splitting the wallet service into two blind TEE-attested components so neither operator can reconstruct who paid whom.
The TEE guarantee is probabilistic not mathematical and doesn’t touch amount privacy or timing correlation – but it closes the operator surveillance gap. Curious if this maps to anything you’ve been thinking about on the OpenETR side.
Trying to create a eBay listing automation workflow for my dad using Google Lens & Gemini (based on his preference) which involves using their API keys
and came across this for the first time. What the f?
I worked on the NIP spec last night and just uploaded the updated version - let me know what you think of it & also left you a technical question that needed clarification
I think your npub-derivation approach is the most trust-minimized implementation of the other iterations, but there’s still some work to do on client-side guidance
But for now, the foundation of NSW seems promising
The question is the derivation method. Your diagram shows BIP32. The NIP draft uses BIP340 tagged hashes: scan_privkey = int(tagged_hash(“nostr-sp/scan”, sk)) mod n. Same tag strings, different operation, different output keys.
Which does your code actually use? If it’s BIP32 I can align the NIP to match.