-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[bug]: Fail to chain sync on testnet3
& mainnet
errors relating to: script witness item is larger than the max allowed size
#7002
Comments
😬 |
Looks like lnd/btcd has a bug in their taproot implementation. In BIP342:
I am surprised this wasn't caught by tests. Are they not using the static test vectors? |
Having this with LND Version v0.15.1 on mainnet:
|
Got the same error on mainnet:
|
I also also seeing on mainnet v0.15.0:
|
Same |
Same here. Why it suddenly happened to all of us? Answer: a transaction came in the Blockchain that LND was not able to manage, thus all nodes went down at the same block |
See this on v0.15.1/mainnet
|
This seems to be the tx that can't be parsed https://mempool.space/tx/7393096d97bfee8660f4100ffd61874d62f9a65de9fb6acf740c4c386990ef73 |
Posted about here: https://twitter.com/brqgoo/status/1579216353780957185 |
Same here. Running on testnet. bitcoind v22.0, lnd v0.15.1.
seeing this printed over and over in bitcoind debug.log
|
if this is a mainnet tx, why is it impacting nodes running on testnet? |
A similar transcation happened on testnet |
testnet3
errors relating to: script witness item is larger than the max allowed sizetestnet3
& mainnet
errors relating to: script witness item is larger than the max allowed size
makes sense. figured he must have tried it on testnet first. but the testnet block referenced doesn't appear to have a tx at the same scale as the one on mainnet |
ahh, few, thought i broke my node for a second . |
The bad tx on testnet is https://mempool.space/testnet/tx/44692bc2da73192cd0b89bc7a43c0ce43578f6b3567bc945e46e6952e8ec5ca5 |
Ahh, thanks. I see, its rescanning starting at block height 2350075 meaning the tx is in the next block. Got it. Well damn, I finally got my testnet node up-and-running and was about to make some taro assets and now this 😞 |
Bug is actually in btcd code: |
With BIP-342, the maximum script size limit of 10000 bytes no longer applies. The witness script size is only implicitly bounded by the block weight limit. |
Hey y'all, thanks for bringing this to our attention. I've identified the issue in the AFAICT, the consensus code wasn't the issue here, it was instead that the wire parsing library was erroneously still enforcing a prior check to limit witness sizing left over from segwit v0.
btcd is/was using this test vectors. The issue here is that the code the parsed the witnesses for these test vectors isn't the same code that's used to read blocks off the wire. When a new block comes in, we fetch the raw block then attempt to decode it, which triggered this issue. |
Same problem. Have stopped the node now until further notice. 0.15.1 Logs when starting the node Oct 10 00:34:36 indomitusbtc lnd[1922]: 2022-10-10 00:34:36.014 [INF] LTND: Waiting for chain backend to finish sync, start_height=757941 Oct 10 00:34:36 indomitusbtc lnd[1922]: 2022-10-10 00:34:36.399 [INF] LNWL: Started rescan from block 00000000000000000007477b90ff0ea53cdd1db88e03799af18ff58df0cebaa7 (height 757921) for 2056 addresses Oct 10 00:34:36 indomitusbtc lnd[1922]: 2022-10-10 00:34:36.685 [ERR] LNWL: Unable to complete chain rescan: readScript: script witness item is larger than the max allowed size [count 33970, max 11000] |
The fix to the btcd wire parsing logic can be found here: btcsuite/btcd#1896 This should be safe to apply to those running btcd nodes, which'll allow them to resume validating the main chain (the block was accepted as this wasn't a consensus issue persay). Once this passes CI and a few more sniff checks, we'll issue a hotfix release for lnd: 0.15.2. This release will only contain the dependency update to the wire parsing library. |
Is a bump for neutrino needed too? I think a consumer can hoist the required version themselves, but they might have to require btc directly to do so. |
I confirm that my LND nodes are stuck at block 757921 despite I can send and receive Stas normally through established channels, I am proceeding to implement fix.
|
We need a fast update to the newest lnd version as there was a security issue detected. lightningnetwork/lnd#7002 As the bug was part of the btcd dependencies the fix applied in btcsuite/btcd#1896 brings a long tail of dependency updates. This commit updates the dependencies and adapts for all changes that are introduced by this new dependencies.
Background
Fail to chain sync on
testnet3
.The node does show it is up to the tip of the chain , but remains unsynced due to errors
Your environment
0.15.0-beta commit=v0.15.0-beta
Linux ip-10-21-2-70 5.13.0-1031-aws #35~20.04.1-Ubuntu SMP Mon Jun 13 22:30:30 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
bitcoind v23.0.0
Steps to reproduce
Unknown
Expected behaviour
"synced_to_chain": true
Actual behaviour
"synced_to_chain": false with following errors in logs:
The text was updated successfully, but these errors were encountered: