PPPs: Week 2 - protocol blues

This week, most of my free time was spent thinking about two issues that I think could become problematic if not dealt with properly. I'll describe them below:

Problems ✋

• It's becoming increasingly clear that the default base and proportional budget (designed that way to mimic routing fee rates) does not work for all payment sizes. Small payments to wrapped invoices with the default routing budget fail often. Last week I introduced the ability to set a custom routing budget to get around this issue but that's not a very user friendly solution. Since I want lnproxy to provide opt-in privacy for even non-technical users of custodial lightning wallets, I need a better solution. I've been running some numbers on payments and working on a better way to calculate the routing budget.

• The announcement that amboss.space will offer to collect real time channel balances from nodes that want more insights woke me up to the need for increasing the robustness of a solution like lnproxy. In a worst-case scenario where amboss has access to most large routing node's balances, it would be trivial to deanonymize the intended payment destination of payment wrapped by lnproxy. Amboss could simply follow the chain of settled balances from the real destination, to the lnproxy node and back to the payment initiator. There are many ways to improve the privacy robustness of a tool like this but it will take some time to think about their trade-offs.

Progress ✅

• Contributed a short article on improving lightning network privacy using proxy wallets to the robosats project.

• Increased default routing budget for lnproxy-address (which handles routing to [email protected]). This is a reasonable stop-gap until

• Updated contact page on lnproxy.org to point to mempool.space rather than amboss.space and made some aesthetic improvements to the site while I was at it.

• Zero fee routing announced they'd be shutting down their node. Services like zero fee routing's that allow users to purchase inbound channels are great for privacy but they involve some level of trust since the seller can always close the channel early (though I think lightning labs' Pool has some way to prevent this). I drained the inbound liquidity on lnproxy's channel with zero fee routing and purchased a new channel from yall's.

Plans 📆

• Develop better routing budget estimation.

• More research on the effects of random delays and payment splitting for improving privacy of payments using lnproxy.

• Tackle unfinished plans from week 1 😅