Skip to content
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

Closed
instagibbs opened this issue Sep 28, 2018 · 3 comments
Closed

Comments

@instagibbs
Copy link
Collaborator

instagibbs commented Sep 28, 2018

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.

@instagibbs
Copy link
Collaborator Author

Actually it's even more subtle. Since we're not actually marking these types of blocks as permanently failed(BLOCK_FAILED_MASK), we're not actually re-evaluating these blocks inside of BitcoindRPCCheck, which is checking for this flag. So instead we're counting on the block being given again to the node, or re-evaluated by some other trigger.

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.

@instagibbs
Copy link
Collaborator Author

CorruptionPossible really has two contexts:

  1. In mempool, where it is used to not stick things in the reject pool, which witness transactions never are

  2. In block validation, where it's used to not hard-ban a block. This happens with things like merkle trees not connecting to merkle root commitment.

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.

@instagibbs
Copy link
Collaborator Author

I believe this is a regression introduced by #260 since previously it was done in script.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant