pull down to refresh

739 sats \ 2 replies \ @jake 23 Sep 2022 freebie \ parent \ on: lnproxy: A trustless way to improve pubkey privacy on lightning bitcoin
And you could receive donations without revealing your wallet custodian.
Are you thinking in this case that lnproxy would act as an lnurl-pay provider itself, and relay the request to the payee's lnurl-pay provider behind the scenes?
If so, wouldn't this remove the ability for the payee to confirm that the wrapped invoice is valid? In terms of Lightning Addresses (for simplicity), having ex. me@lnproxy.org -> me@me.com would mean that there's no way for the payee to confirm that nothing fishy is going on with the invoices generated for me@lnproxy.org, since they'd be provided directly to the payer by lnproxy.
To keep that ability for the payee to inspect the wrapped invoice, I'd think you'd need to have the payee's lnurl-pay provider call out to lnproxy, rather than the other way around. It's interesting to think about if something like this could exist as an lnurl sub-spec so that the expectations for both a proxy client and proxy provider could be codified 👀.
write
preview
0 sats \ 0 replies \ @lnproxy OP 7 Oct 2022
What do you think about integrating into a bridge server so that me@me.com would first access the lnproxy api to hide the @me.com public key? Then the owner of me.com could trust the bridge server code they're running to make sure that the payment hashes always match and the "max fees" don't change.
https://github.com/lnproxy/lnproxy/issues/7
reply
0 sats \ 0 replies \ @lnproxy OP 23 Sep 2022
That's an excellent point. Without the ability to verify that the payment hashes match, you should not trust the proxy server.
But there's also not much point in using a proxy in that case.
I'll have to think more on this.
reply