Add optional support to hide node pubkey with lnproxy

[lnproxy]

As suggested in #41 and https://github.com/lnproxy/lnproxy/issues/7

This PR adds a config option to allow the address bridge server to hide node pubkeys by first wrapping all invoices with lnproxy (see README here: https://github.com/lnproxy/lnproxy).

[fiatjaf]

Very interesting.

Two questions:

1. Does LNProxy change the invoice amount and description?
2. How does this routing budget thing work?

[lnproxy]

Does LNProxy change the invoice amount and description?

It changes the invoice amount but copies the description from the original invoice.
I hadn't thought carefully about the description though, and now I'm thinking that the validation code should make sure that the descriptions match in addition to checking that the hashes and amounts match.

How does this routing budget thing work?

The routing budget is used to set the FeeLimitMsat when making the payment on the lnproxy node.
The payment will have a higher chance of success if it's higher but you don't want to over charge users either.
The idea is to let whoever operates the bridge server set some reasonable parameters with the envconfig.

[fiatjaf]

If you change the invoice amount it won't work with LNURL/Lightning Address.

It would be nicer if you put a huge fee on your channels instead of changing the invoice amounts, why not?

[lnproxy]

If you change the invoice amount it won't work with LNURL/Lightning Address.

I do change the invoice amount but I have some logic in the PR to subtract the routing budget from the requested amount before requesting an invoice from the user's node so that the wrapped invoice will be exactly the amount that the lnurl payer is expecting.

I'll have a bridge server up later today so you can test it.

It would be nicer if you put a huge fee on your channels instead of changing the invoice amounts, why not?

I hadn't even considered that but it's a great idea. I'd have to use some kind of two node setup so that the last hop could charge the routing budget as a fee. Depending on how big this fee is, some wallets might just reject it but it's worth a try, I'll work on this.

[fiatjaf]

I do change the invoice amount but I have some logic in the PR to subtract the routing budget from the requested amount before requesting an invoice from the user's node so that the wrapped invoice will be exactly the amount that the lnurl payer is expecting.

Interesting, so I think your patch here will work fine.

I hadn't even considered that but it's a great idea. I'd have to use some kind of two node setup so that the last hop could charge the routing budget as a fee. Depending on how big this fee is, some wallets might just reject it but it's worth a try, I'll work on this.

Yes, that's true, you need a two-node setup, but you don't really need an actual second node. You can issue an invoice with a fake route hint on it including the fee. I've done that multiple times in the past. Then on your actual node you intercept that invoice using the htlc_accepted hook (on CLN) or the HTLC Interceptor (on LND).

[fiatjaf]

I tried [email protected] as instructed at #43 (comment) but I am getting this response always when doing the second call:

{
  "status": "ERROR",
  "reason": "error while requesting invoice"
}

[lnproxy]

I think it was a tor issue. I guess maybe it takes too long to both request an invoice over tor and then request a second invoice (the second one is clearnet, but still).
Using a vpn now, seems to be working much better. No failures on SBW.