It only effects lnd nodes using btcd (a golang implementation) not bitcoin-core afaict. The changeset was confirmed to fix the problem and is available on master.
My node is effected and I'm using bitcoin-core, so this isn't isolated to btcd as the ticket alludes.
After uninstalling the default raspian verison of go, and manually installing go 1.18 as per lnd compile instructions, then compiling and installing LND v0.15.2-beta branch, my node is back up and running.
I'm afraid this procedure isn't for the passive noderunner and the lightning network is going to be crippled until a new lnd package is released.
If you are seeing this now - Update lnd version to v0.15.2-beta immediately. Not doing so, will make your lnd node stuck in "syncing to blockhain" mode forever.
This problem is actually caused by a missing specification in BIP144 to put some kind of a reasonable limit on the size of transaction witness data.
By my estimation, with a ~$600 fee, and a 127999 of 128000 a person can delay all transaction processing by one block.
This could be used in addition to a DoS attack on a channel counterpart to perform a sniper attack on a channel in the last hour of its HTLC timeout. It would start to become economic somewhere around channel size of 0.5 BTC.
Interesting approach to this attack vector. We are in the
Lightning Network´s infancy, we take advantage of the
same network that has allowed Visa and Mastercard
to monopolize payments and thus we are subject to
some attacks as well.
We should be keeping an eye and testing as much
as possible.
The only thing to be done about it at this point is simply use small channels that can't be economically attacked. Putting a really big fee on the closure transaction would also possibly give a strong chance of displacing the giant tx.
I'm sure some kind of countermeasure will be devised in the future but for now best to just keep channels small like no bigger than 0.5btc maybe, if you aren't very sure about your counterparty, 0.1. In any case, more links are better so 10 0.1btc channels is probably better for the network than 2 at 0.5.
Another reason I run CLN...
Too many RPis nodes with LND, run by noobs.
I stopped running LND few time ago. I use it only for testing stuff when is needed but not on my long run private node.
The "bug" was a reasonable DoS and processing bounds measure just not in the spec for the majority of bitcoin nodes operating. Roasbeef put it in there when Segwit was rolled out. 5 years passed until someone blew it up.
it worked!! Node went down this morning did this fix after restarting and about 10 mins wait all my peers and channels came back. For your assistance I tipped 5k sats.
Curious with LND going to 15.3 how do I find the image file on the GitHub to manually update my node? One of my channels is not working and my node isn’t routing any payments anymore.
sudo ./umbrel/scripts/repo set https://github.com/MaxKotlan/umbrel-appssudo ./umbrel/scripts/repo updatesudo ./umbrel/scripts/repo default-repo./umbrel/docker-compose.ymlfile manually.sudo ./umbrel/script/startsudo ./umbrel/scripts/repo update