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

Jump to bottom

Check that new headers are not a descendant of an invalid block (more effeciently) #11531

Merged
merged 6 commits into from Nov 1, 2017
Merged

Check that new headers are not a descendant of an invalid block (more effeciently) #11531

merged 6 commits into from Nov 1, 2017

Commits on Oct 31, 2017

  1. Rewrite p2p-acceptblock in preparation for slight behavior changes 

    Removes checking whitelisted behavior (which will be removed, the
difference in behavior here makes little sense) and no longer
requires that blocks at the same work as our tip be dropped if not
requested (in part because we *do* request those blocks).
    @TheBlueMatt
    TheBlueMatt committed Oct 31, 2017
    Copy the full SHA
    3b4ac43 View commit details
    Browse the repository at this point in the history

  2. Stop always storing blocks from whitelisted peers 

    There is no reason to wish to store blocks on disk always just
because a peer is whitelisted. This appears to be a historical
quirk to avoid breaking things when the accept limits were added.
    @TheBlueMatt
    TheBlueMatt committed Oct 31, 2017
    Copy the full SHA
    3d9c70c View commit details
    Browse the repository at this point in the history

  3. Accept unrequested blocks with work equal to our tip 

    This is a simple change that makes our accept requirements the
same as our request requirements, (ever so slightly) further
decoupling our consensus logic from our FindNextBlocksToDownload
logic in net_processing.
    @TheBlueMatt
    TheBlueMatt committed Oct 31, 2017
    Copy the full SHA
    932f118 View commit details
    Browse the repository at this point in the history

  4. Reject headers building on invalid chains by tracking invalidity 

    This tracks the set of all known invalid-themselves blocks (ie
blocks which we attempted to connect but which were found to be
invalid). This is used to cheaply check if new headers build on an
invalid chain.

While we're at it we also resolve an edge-case in invalidateblock
on pruned nodes which results in them needing a reindex if they
fail to reorg.
    @TheBlueMatt
    TheBlueMatt committed Oct 31, 2017
    Copy the full SHA
    015a525 View commit details
    Browse the repository at this point in the history

  5. [qa] test that invalid blocks on an invalid chain get a disconnect

    @TheBlueMatt
    TheBlueMatt committed Oct 31, 2017
    Copy the full SHA
    00dcda6 View commit details
    Browse the repository at this point in the history

  6. Make p2p-acceptablock not an extended test

    @TheBlueMatt
    TheBlueMatt committed Oct 31, 2017
    Copy the full SHA
    f3d4adf View commit details
    Browse the repository at this point in the history