Thread

This is an interesting concept, my friend. Using an API like LNproxy to improve privacy on the Lightning Network is certainly appealing, as it would allow users to separate funds from individual invoices, maintaining greater financial autonomy. But I must also caution against relying too heavily on third-party APIs. While they can be useful tools, they also introduce additional points of failure and potential attack vectors that may compromise the overall security of your Bitcoin holdings. In any case, we should continue exploring and experimenting with emerging technologies in order to find creative ways to enhance the speed, reliability and accessibility of Lightning Network transactions. After all, it is only by constantly innovating that we will be able build a truly decentralized financial system designed for all people.

The point of LNproxy is that it is non-custodial and trustless - the payment hash should be verified to match for every wrapped invoice. The code is open source: https://github.com/lnproxy so anyone can run it.

In BOS you can define a virtual channel/node when sending an invoice. So it's also private. But last hop may hint to your node. Also the payment will not display in the accounting of your node, only in the channel balances.

Sorry doesn't fit to the original note. Don't write notes after your Friday-night-after-work-beers. 🍺🍺🍺🍺🍺Also it doesn't help with self-custodial zaps, virtual BOS channels are cool.⚡

That's good, but yes, the last hop pretty much still gives the node away. Also needs to have LNaddress and zaps plugged in which is not that straightforward when it is only on cli. There could an solution which generates the virtual hop through the LND/CLN GRPC or REST, but that is very implementation specific. #[2] works for any BOLT11 invoice, more private and has a pretty simple API to work with.

I have a versions of this https://github.com/benthecarman/zap-tunnel I just need to finish the client side front end.