If you run an lnproxy relay please shut it down ASAP (two SIGINTs with Ctrl-C) and wait for an update.
lnproxy
_@lnproxy.org
npub1ufdg...zcue
A simple lightning privacy tool.
https://simplex.chat/contact#/?v=1-4&smp=smp%3A%2F%2FUkMFNAXLXeAAe0beCa4w6X_zp18PwxSaSjY17BKUGXQ%3D%40smp12.simplex.im%2F_58pkdyvJRFpXcXCUf2U5ul70UQKe97T%23%2F%3Fv%3D1-2%26dh%3DMCowBQYDK2VuAyEASSPeBUbI370XzaUEHTpMp_xBYBa9EmZGWuTGuIM7pSQ%253D%26srv%3Die42b5weq7zdkghocs3mgxdjeuycheeqqmksntj57rmejagmg4eor5yd.onion
Is there a program for testing / benchmarking relays? I've been working on a boltdb backend for github.com/fiatjaf/relayer and I want to see how it stacks up agains the sqls.
More improvements to payment reliability for lnproxy relays: routing budget and cltv delta are now estimated intelligently using the routing graph ( https://github.com/lnproxy/lnproxy/commit/6bcc8dd495d8f6c4bb4a2690e7526c9ff55cba8d ).
Please test and report any issues.
Increased the balance on the https://lnproxy.org/spec relay. If you've been trying to use lnproxy for large payments, it will be more reliable now.
๐


One of the downsides of having only unannounced channels is that routing through public channels give you a lot of plausible deniability when making or receiving payments. Your counter parties can't know if it's you or just someone routing through you.
Since lnproxy works just as well with private channels (the wrapped invoice will just have routing hints), running an lnproxy relay restores this plausible deniability (as well as giving you some potential routing revenue).
Even nodes not running relays benefit, since your counter party now has to assume that it's possible you're running an lnproxy relay they don't know about.
Anyone can run an lnproxy relay and you don't have to trust them with your money.
To make this clearer, I've remove a "feature": lnproxy will no longer accept zero-amount invoices. Only invoices with amounts can be relayed trustlessly.
To whoever is trying to wrap non-mainnet invoices on lnproxy.org, getting a signet / testnet node is still on the todo list, sorry for the inconvenience.
lnproxy will be offline for a bit while lnd 16.1 starts up. Seems to be very slow when the back end node has a small mempool.
:( lnproxy is down while I figure one heck an issue with lnd on openbsd 7.2. Never seen anything like it.
Please reach out if you're running or are willing to run a relay in the meantime. Would be good to point the webui somewhere while I fix this.
Apologies to everyone that was using my relay. It will be back as soon as possible, but it may take a few more days.