-
Notifications
You must be signed in to change notification settings - Fork 377
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
peg-in witness invalid blocks disk at on start cause log spam/DoS #424
Comments
Actually it's even more subtle. Since we're not actually marking these types of blocks as permanently failed( When would a corruption possible block be reconsidered/asked for again? One possible solution is to mark the failure as corruption not possible, but only when the RPC call specifically fails, then have the re-evaluation queue take over. |
In our case, the witness data is attested to by the witness commitment in the coinbase, and we're not going to ban relayers for relaying a bad peg-in in the mempool(witness could be tampered with), so there's no reason to mark it as corruption possible when failing peg-in witness checks of any sort. |
I believe this is a regression introduced by #260 since previously it was done in script. |
FindMostWorkChain
is used during import of blockchain to find if there's something in chainstate that has more height and isn't provably bad.Due to our RPC-dependency(and the fact that a previously invalid block can become valid just by Bitcoin confirmations. This makes the block "Corruption possible". This means that
FindMostWorkChain
will select these blocks that have failed.During ThreadImport, it goes in a loop trying to validate this block that is on disk, failing, and retrying as fast as possible forever, or until confirmations/RPC connection is re-attained.
The text was updated successfully, but these errors were encountered: