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.
There's now a pull request from Roasbeef:
build: update to version of btcd with wire parsing bug fix #7004 https://github.com/lightningnetwork/lnd/pull/7004
UPDATE
📢 lnd v0.15.2 hotfix has just been released — update ASAP #79472 https://github.com/lightningnetwork/lnd/releases/tag/v0.15.2-beta
At first glance it sounds serious but it seems to be a bug in btcd and not a taproot bug
This is likely the transaction that caused problems for the nodes https://mempool.space/tx/7393096d97bfee8660f4100ffd61874d62f9a65de9fb6acf740c4c386990ef73
Its a 998-of-999 tapscript multisig https://twitter.com/brqgoo/status/1579216353780957185
Correct, it's not a bug in taproot, it's a bug in LND. CLN is unaffected https://twitter.com/Core_LN/status/1579258808161153025
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 running LND with a Bitcoin core backend was affected. Upgrading to current release fixed the issue.
No, it affects lnd nodes that uses bitcoind backend as well. The bug is in the transaction parser.
looks like you can check your node with the "lncli getinfo" command line
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.
That's unfortunate, and yes, this is no walk in the park...
view on twitter.com.
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.
Lnd Release 0.15.2 - https://github.com/lightningnetwork/lnd/releases/tag/v0.15.2-beta
I was wondering why everything stopped working for me.
Maybe there is a good lesson here. If running an LND node, use a CLN watchtower (and vice versa).
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.
Also, to be clear, you can run LND with bitcoind instead of btcd.
it'd be tested out before releasing, software engineering
Fix is in: #79472
for anyone using umbel you can fix it by doing the following
ssh into your machine
sudo ./umbrel/scripts/repo set https://github.com/MaxKotlan/umbrel-appssudo ./umbrel/scripts/repo updatethen go to the umbrel app store and update lnd
this fix hasn't been merged in yet, but once an official umbrel update is created you can
sudo ./umbrel/scripts/repo default-repoto set it back to the official repo.
Submitted this change as a pull request to umbrel https://github.com/getumbrel/umbrel-apps/pull/190
I'm assuming I can't just pull this on an Umbrel running on 0.4.X, right?
Do you perphaps have a guide around to migrate to 0.5.X if that is necessary?
Yeah this won't work for that. You'll have to update to 0.5.X or manually fix it.
For umbrel 0.4.x you'll have to edit the
./umbrel/docker-compose.ymlfile manually.In that file you'll see a list of services.
If you scroll down to the lnd section
... networks: default: ipv4_address: $BITCOIN_IP lnd: container_name: lnd image: lightninglabs/lnd:v0.14.1-beta@sha256:810f290f4da51adaf57d53bc1f1e65b52b03c543f322da0b98fb8c47be94a27a user: 1000:1000 depends_on: [ tor_proxy, manager ] volumes: - ${PWD}/lnd:/data/.lnd environment: HOME: /data restart: on-failure stop_grace_period: 5m30s ports: - "9735" - "$LND_REST_PORT:$LND_REST_PORT" - "$LND_GRPC_PORT:$LND_GRPC_PORT" networks: default: ipv4_address: $LND_IP dashboard: container_name: dashboard ...you should be able to manually edit the container (on line 7 here) to
lightninglabs/lnd:v0.15.2-beta@sha256:a011b06c622c947a3039d76a5a08b4896fc6a02dea6add3afd345019f8737923and then restart the node, or run
sudo ./umbrel/script/startto just apply the update
Thank you so much!!! I don’t want to upgrade my umbrel to 0.5.X will try this manual update for my node
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.
Wow thank you so much! Really appreciate it. Happy your node is fixed.
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.
Thanks a lot. This is exactly what I did a few hours ago and it worked fine. No further steps were needed.
Awesome! Glad to hear the fix worked
As or upgrading to 0.5.X, you should be able to go to the settings menu and click the update button if you are on 0.4.18. https://github.com/getumbrel/umbrel/issues/1422
If not, then I'm not then in all honesty not sure what the procedure is. It might let you update to 0.4.18 and then after 0.5.X.
If not, you may need to manually apply the fix or reinstall 0.5.X.
Update: the PR has been merged. These steps should not be needed. You should be able to update from the umbrel app store.
If you don't see it try
sudo ./umbrel/scripts/repo update