Large lightning vulnerability concern \ stacker news ~bitcoin

Large lightning vulnerability concern lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022032.html

6349 sats \ 28 comments \ @nicosey 20 Oct 2023 bitcoin

43 sats \ 7 replies \ @ek 20 Oct 2023

Those types of changes are the ones necessitating the utmost transparency and buy-in of the community as a whole, as we're altering the full-nodes processing requirements or the security architecture of the decentralized bitcoin ecosystem in its integrality.

On the other hand fully explaining why such changes would be warranted for the sake of lightning and for designing them well, we might need to lay out in complete state practical and critical attacks on a ~5 355 public BTC ecosystem.

Hard dillema.

Mhh, very interesting and I get the dilemma.

Can't easily convince people who support ossification like @jimmysong (/cc @nerd2ninja) (for valid reasons!) about soft forks.

But explaining in detail why we need a soft fork to fix a vulnerability effectively discloses the vulnerability before it's fixed.

4468 sats \ 3 replies \ @petertodd 20 Oct 2023

But explaining in detail why we need a soft fork to fix a vulnerability effectively discloses the vulnerability before it's fixed.

This is one reason we have layered systems. If Lightning devs have in fact screwed up, better that Bitcoin continues operating while Lightning figures out how to fix things with full disclosure and many competent people understanding the issue.

Right now, Antoine hasn't even published an easy to read explanation of what the problem actually is. He seems to have convinced a decent number of people involved in lightning development that there is an issue. But he hasn't convinced many people who aren't intimately involved with LN/BTC development. Nor is his "we're all doomed" view on it shared widely.

Anyway, there's no way this issue actually wrecks all of Lightning. You can do routing just fine through semi-trusted node relationships. It's not as decentralized as we want. But even in the worst case a large proportion of usage of lightning will work fine.

32 sats \ 1 reply \ @Wumbo 20 Oct 2023

You can do routing just fine through semi-trusted node relationships

I agree, that is what I understand from the write up (https://github.com/ariard/mempool-research/blob/2023-10-replacement-paper/replacement-cycling.pdf).

An amateur node operator (one who has not already put in place some of the mitigation options) might want to review what channels they currently have open and may not want to accept new channels. Depending on there risk profile.

100 sats \ 0 replies \ @rleed 20 Oct 2023

From the very beginning, I always saw the Lightning layer as a replacement for the bank layer in the fiat system. Banks can and should have selected, trusted relationships with each other. Operating a Lightning node, I have always been frustrated with the assumption that a node operator wants to network willy nilly in a trustless world. I want to choose my channels wisely, not entirely trustlessly, and in my opinion the tooling for that is poor at present, (although admittedly I haven't spent enough time trying all available tools).

Some argue this semi-trust tends toward centralization, but the counterargument is that anyone can start up a Lightning node to fill in the gap anytime one feels like centralization is getting out of control. We still have complete freedom.

10 sats \ 0 replies \ @patrick1 20 Oct 2023

This just leads to further centralization.

121 sats \ 1 reply \ @nerd2ninja 20 Oct 2023

I know I was only cc'd, but I want to make it clear that I don't necessarily support ossification. I know and respect the process of upgrades, of communicating to everyone involved to get on board, and to spend years on explanations, demo's, and pentesting on test networks. I currently like CTV and APO for example.

121 sats \ 0 replies \ @ek 20 Oct 2023

Oh didn't mean to make it look like that

I CC'd you because you made me aware of @jimmysong's note on nostr where he mentioned he supports ossification and you mentioned you disagreed :)

0 sats \ 0 replies \ @Rsync25 20 Oct 2023

Interesting point

0 sats \ 3 replies \ @shyfire 21 Oct 2023

I basically set all my channels max htlc to 100k sats for now

0 sats \ 2 replies \ @anon 21 Oct 2023

[htlc] max_htlc_msat=100000

This gives: failed to load config: lnd.conf:61: unknown option: max_htlc_msat

Any idea how to set this using Umbrel latest version?

0 sats \ 0 replies \ @shyfire 21 Oct 2023

I'm a CLN user so not sure.

0 sats \ 0 replies \ @anon 21 Oct 2023

Found this https://bitcoin.stackexchange.com/questions/116772/where-does-the-max-htlc-msat-field-in-the-getchaninfo-results-come-from

But if anyone has a better solution please share 🙏

0 sats \ 13 replies \ @patrick1 20 Oct 2023

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.

171 sats \ 2 replies \ @petertodd 20 Oct 2023

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.

70 sats \ 1 reply \ @DarthCoin 20 Oct 2023

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)

172 sats \ 0 replies \ @petertodd 20 Oct 2023

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.

40 sats \ 8 replies \ @shyfire 20 Oct 2023

I run mine for privacy reasons... Not keen to turn it off.

0 sats \ 7 replies \ @patrick1 20 Oct 2023

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.

0 sats \ 6 replies \ @shyfire 20 Oct 2023

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.

10 sats \ 5 replies \ @TonyGiorgio 21 Oct 2023

What gives you the view that you can't use mutiny to spend self custodially and privately?

0 sats \ 4 replies \ @shyfire 21 Oct 2023

Hey Tony an honor to answer a question from you.

Pretty much the main things giving me this view are

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 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)

210 sats \ 3 replies \ @TonyGiorgio 21 Oct 2023

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.

0 sats \ 2 replies \ @shyfire 22 Oct 2023

I sat down now to test out your self hosting instructions, but I'm staring at this $12/month Digital Ocean cost and thinking about ROI and now my head is spinning.

I saw a "should be OK with 1GB/1CPU" so giving that a whirl on Linode. Found 1 or 2 issues in the setup instructions but made notes and will write it up.

Just a quick Q: if I don't want any old random to use my server, I was thinking of locating the site at https://mysite.net/uuid instead of just https://mysite.net However seems the Mutiny stack is expecting a lot stuff at /

Any suggestions for locking it down a bit? basic auth UX sucks ass on mobile so anything but that

Thanks for clearing up the 2 hop thing, I'll definitely open another public channel in that case.

view replies

10 sats \ 0 replies \ @DarthCoin 20 Oct 2023

run private nodes https://darthcoin.substack.com/p/private-lightning-nodes

31 sats \ 1 reply \ @Zepasta 20 Oct 2023

deleted by author

96 sats \ 0 replies \ @rhombus 20 Oct 2023

Courtesy of ChatGPT:

The attack referred to is a transaction-relay jamming attack which could cause a loss of funds in lightning channels, specifically during the routing of Hashed Timelock Contracts (HTLC) traffic. The author mentions this attack as a "replacement cycling attack" which doesn't require significant resources from an attacker, just access to basic Bitcoin and Lightning Network software, albeit with a decent amount of technical know-how. This attack creates a situation where certain transactions in the Lightning Network could get jammed, making it hard for nodes to properly settle their transactions, which in turn could lead to loss of funds.

The "replacement cycling attack" is a sophisticated attack aimed at exploiting the transaction relay mechanisms within the Bitcoin network, especially as it pertains to the Lightning Network. Here's how it's performed, based on the detailed explanation provided in the email:

Initiation of Attack: A malicious channel counterparty initiates the attack by broadcasting a transaction known as an HTLC-preimage transaction, with both a higher absolute fee and a higher fee rate compared to the honest HTLC-timeout transaction broadcasted by the victim lightning node, triggering a replacement in the mempool (the holding area for transactions before they get confirmed).
Manipulation of Transactions: In both legacy and anchor output channels, an HTLC-preimage on a counterparty commitment transaction is malleable, meaning additional inputs or outputs can be added. This HTLC-preimage spends an unconfirmed input from an unrelated parent transaction and conflicts with its child transaction.
Replacement in Mempool: Due to the higher fees associated with the malicious HTLC-preimage transaction, it gets accepted in the mempool, replacing the honest HTLC-timeout transaction which is then evicted from the mempool.
Further Malicious Replacement: The malicious counterparty can then replace the parent transaction with another candidate transaction that satisfies the replacement rules, triggering the eviction of the malicious HTLC-preimage from the mempool since it was a child of the parent transaction.
Cycling the Attack: This process can be repeated for each rebroadcast attempt of the HTLC-timeout by the honest lightning node until the expiration of the inbound HTLC timelock. Once this height is reached, a new HTLC-timeout is broadcast by the malicious counterparty, colluding with another party on the outgoing link who broadcasts its own HTLC-preimage.
Double-Spending: The honest Lightning node ends up being "double-spent" in its HTLC forwarding due to this cycling attack, creating a loss of funds scenario.
Impact and Connectivity: The success of this attack could be further exacerbated if the malicious transactions are included in the block template of the miner winning the block race. A replacement cycling attack might over-connect to miners' mempools and public reachable nodes to succeed in a fast eviction of the honest transactions.