The current implementation of publsp autogenerates new keys at startup if none are found, then saves those to file. Each subsequent startup will try reading that file to see if keys are there to use. I figured that was a reasonable trade-off to reduce friction, and to avoid potential confusion if the tool automatically regenerates new keys each time. But you bring up a good point. This could just be a new option the user sets to deliberately create new keys each time, or the opposite, to keep the existing keys each time. I guess either opt-in or opt-out but the user is made aware.
On the receiving LN node privacy issue, I think that's a separate problem to tackle. In the end, the LSP needs to know where to open the channel so it can't be avoided, but there's no reason that the receiving nodes can't be one-offs, for example.
Login to reply
Replies (2)
I wonder if it'd be possible to obfuscate the receiving node pubkey similar to how NIP-17 private messages obfuscate the receiver key?
That's what I'm thinking. I believe mutiny wallet creates a new pubkey for every channel it requests, and the transLND project shows that you can spin up new pubkeys on LND and pretend those belong to your node, so I think its possible, at least on lnd