pull down to refresh

Welp, might be time to just turn off my routing node after nearly three years of running it.
It's never turned a profit anyway.
Since this attack requires the channel to be closed to work, a simple mitigation is to just reduce the maximum amount that can be in flight in HTLCs to some %, eg 10%. I don't know off the top of my head if LND can do that. But it should if it doesn't.
reply
Yes LND and CLN can do that. Here I explained in my routing fees experiment that is even indicated to do that (limit min/max HTLC) and also Rene Pickhardt came to the same conclusion in his latest study (link is in my article)
reply
Not quite. I'm not suggesting that a single HTLC be limited in size. I'm suggesting that the sum of all simultaneous HTLCs for a given channel be limited.
Of course, setting the maximum HTLC value and the maximum number of HTLCs does that indirectly. But not as efficiently as a max HTLC sum limit.
Also, in your article you have links to specific lines in files on GitHub. Those links are broken because you linked to master, rather than a specific git commit. You can hit the "y" key to get a stable URL for a specific git commit in GitHub.
reply
I run mine for privacy reasons... Not keen to turn it off.
reply
I do too, but I may just use mutiny and then get my sats out of lightning immediately with a swap whenever it's a significant amount.
Kinda sad.
reply
Yeah my issue is with spending privately though, I want to pay LN invoices in a self custodial and private manner. Mutiny (the hosted version) can't give me that unfortunately.
reply
What gives you the view that you can't use mutiny to spend self custodially and privately?
reply
Hey Tony an honor to answer a question from you.
Pretty much the main things giving me this view are
  1. accidentally leaking my IP to Mutiny's web servers. My daily driver is (gasp) iOS and I can't enforce kill switch VPN, so there is a possibility of leaking my IP. Using Zeus and Tor-only mode I can eliminate operator (me) errors
  2. 2 hop scenario listed here https://abytesjourney.com/lightning-privacy/ (I just re-read the solution about opening additional public channels, and not entirely sure how that mitigated this)
reply
Thanks for that answer. We don't know anything about individual users or lightning payments since we don't run an LSP and thus don't process payments.
But we came out with a self hosting guide here so you can limit the IP concerns.
We could also probably add something for people to enforce that payments sent are at least 2 public hops before the destination. You wouldn't be able to pay other mutiny users with this setting if they share the same LSP but it would protect you from that edge case. Alternatively you can open your own channels too and go without an LSP in mutiny.
Having at least 2 public channels means that the source of funds might not have originated from you, but from someone beyond the other public channel. Only having unannounced channels aren't routeable by others so when you make a payment, it's clear it's from you. So a direct unannounced channel to unannounced channel payment with one up in the middle makes it clear who the sender and final destination was.