lnproxy: A trustless way to improve pubkey privacy on lightning \ stacker news ~bitcoin

pull down to refresh

lnproxy: A trustless way to improve pubkey privacy on lightning

7959 sats \ 19 comments \ @lnproxy 21 Sep 2022 bitcoin

Lightning network privacy will improve. In the meantime, users of custodial lightning wallets, like Wallet of Satoshi or Strike, reveal the destination of every lightning payment they make to their custodian. With lnproxy, these users can instead generate and pay wrapped invoices to hide the destinations of their payments from their custodians.

Users that operate public lightning network nodes, reveal the identity of their node with every lightning invoice they generate. With lnproxy, users can instead generate and give out wrapped invoices to obfuscate the identity of their lightning network nodes from their transaction counterparties.

Learn more at: https://github.com/lnproxy/lnproxy

And try it at: https://lnproxy.org

view all related items

966 sats \ 2 replies \ @TonyGiorgio 21 Sep 2022

Awesome! Glad finally someone created something like this, had been thinking for awhile something with the privacy enhancing features of Muun but with your own node would be nice. A few comments.

Are you generating the fee based on the route information back to the node asking for the wrapped invoice? Not a static fee. Muun and others get away with a base static/percentage because they are the LSP right before the user being the next hop. But in this case, the user could be very far away from you.

Just a comment that this is trustless in terms of security but privacy-wise it's trusting you, much like a VPN provider. You could aggregate and publish that information and thus defeat the purpose that they are trying to acheive by hiding behind you. But still, a better version of WoS or BlueWallet in that you're trusting them with both security and privacy, so kudos to that!

120 sats \ 1 reply \ @lnproxy OP 21 Sep 2022

Thank you!

Yes, the fee is tricky. Currently it's set at 0.7% but for small payments that's sometimes not enough to complete the route. This makes the UX worse, but I'd rather not overcharge on fees too much either. I'm thinking now that the right way to do it would be to add an option on the web interface and the api to let the user set the max fee.

Your second point is good but the service is actually quite a bit better than a VPN since the onion routing prevents the lnproxy server from knowing who paid the wrapped invoice. Thus, reconstructing the full payment details would require collusion between the lnproxy server and one of the payment counter-parties. (In the case of a VPN, the VPN provider knows everything: your IP address and the IP addresses of the sites you visit.)

662 sats \ 0 replies \ @TonyGiorgio 21 Sep 2022

That would be a good way to handle fee, I think trampolines would do a similar thing when that feature gets added to LN. One thing about them and the model you laid out is that you could not guarantee that less of a fee is paid. If a user sets a max fee, that's basically the fee charged to the sender that they probably won't get back if it's actually less than that in practice.

Perhaps you could do JIT route calculations to make it dynamic, or even do a probe to find a route that would work first. Maybe a route doesn't even exist, so you could fail fast and not provide an invoice back to the user at all. Either way, I think it's a great service.

Yeah you have a good point, it's like half of the visibility the VPN has if you want to think of it that way.

663 sats \ 1 reply \ @timechain 22 Sep 2022

Great idea! The next time there is a "trucker's movement" or politically sensitive cause that collects lightning payments, using one of these should be encouraged, especially when using fully KYC'd wallets with lightning capabilities, like Strike or Cashapp.

211 sats \ 0 replies \ @lnproxy OP 22 Sep 2022

Thanks for saying that, it made my day. I hope that it can at least serve as a stop gap until we get blinded paths or widespread adoption of hosted channels or any of the other privacy improvements being developed.

662 sats \ 1 reply \ @And1 22 Sep 2022

That sounds great! Do custodian wallet providers only see a hodl invoice for a lnproxy instance or what do they see?

121 sats \ 0 replies \ @lnproxy OP 22 Sep 2022

hodl invoices are indistinguishable from standard invoices so all the custodian sees is an invoice for a random node (hopefully other people run proxy servers too).

662 sats \ 5 replies \ @kale 22 Sep 2022

I wonder if it is possible to wrap LNURL?

Munn wallet can not send to LNURL, maybe this is a workaround.

Also if that works, i can create a service which listening to the payment status and send webhook.

162 sats \ 4 replies \ @lnproxy OP 22 Sep 2022

Interesting. Muun should support lnurl-pay, it's so simple. I guess that means I should too, I'll give it a go this weekend.

It's actually a really great idea since the generated lnurl pay code could be reusable. No need to interact with the site and make new barcodes for each invoice. And you could receive donations without revealing your wallet custodian. Thank you!

739 sats \ 2 replies \ @jake 23 Sep 2022 freebie

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 👀.

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

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.

100 sats \ 0 replies \ @kale 22 Sep 2022

Actually what I want to build is like stripe payment link. It's a no-code tool people has lightning address can generate link and sell anything.