Skip to content

Conversation

@sipa
Copy link
Member

@sipa sipa commented Feb 24, 2015

With headers-first we can compare against the best header timestamp, rather than using checkpoints which require code updates to maintain.

With headers-first we can compare against the best header timestamp, rather
than using checkpoints which require code updates to maintain.
@gavinandresen
Copy link
Contributor

Code review ACK; I didn't try to test.

@jgarzik
Copy link
Contributor

jgarzik commented Feb 24, 2015

ut ACK

@sdaftuar
Copy link
Member

Tested; works as expected.

@laanwj
Copy link
Member

laanwj commented Feb 26, 2015

utACK

@laanwj laanwj merged commit 85da07a into bitcoin:master Feb 26, 2015
laanwj added a commit that referenced this pull request Feb 26, 2015
85da07a Better fingerprinting protection for non-main-chain getdatas. (Pieter Wuille)
sipa added a commit that referenced this pull request Feb 26, 2015
With headers-first we can compare against the best header timestamp, rather
than using checkpoints which require code updates to maintain.

Rebased-From: 85da07a
Github-Pull: #5820
@laanwj
Copy link
Member

laanwj commented Feb 26, 2015

Backported to 0.10 as aeb9279

@gmaxwell
Copy link
Contributor

gmaxwell commented Mar 7, 2015

@SergioDemianLerner How about an nbits test?

@sipa
Copy link
Member Author

sipa commented Mar 7, 2015

@SergioDemianLerner I would really prefer avoiding checkpoints for this. Wouldn't a nHeight-based check be just as good to prevent that, similar to the check added in this patch?

@SergioDemianLerner
Copy link
Contributor

We have several possibilities:

  1. Some basic housekeeping that can be done when a block is received during download to prevent strange things like blocks with a current time-stamp but low height. Assume for a moment that blocks before a checkpoint have a nTime field that are lower than the checkpoint time (generally this requires to check only about 12 previous blocks, although theoretically one should have to check up to the genesis block).
    This would be a check like:

pcheckpoint = last check point
if ((block->nHeight < pcheckpoint->nHeight) && (block->GetBlockTime() > pcheckpoint->Time))
reject the block/header

  1. Prevent node finger-printing altogether: do not advertise nor return a block or header that is not in the best chain. (but store them, as currently the node does)
  2. Limit the extent of fingerprint to some maximum depth relative to the current best chain height (sipa's proposal).
  3. Force node fingerprinting to require at least some PoW (gmaxwell's proposal).
  4. Limit the blocks to advertise/return based on the same check of 1, but done at the time the block is asked by a peer (my first proposal)

Option 3 has sense only if the relative height is less than 1-month of time (current fingerprinting window). This limits the re-org depth. I like option 1.

@sipa
Copy link
Member Author

sipa commented Mar 7, 2015 via email

reddink pushed a commit to reddcoin-project/reddcoin-3.10 that referenced this pull request Jul 11, 2020
With headers-first we can compare against the best header timestamp, rather
than using checkpoints which require code updates to maintain.

Rebased-From: 85da07a
Github-Pull: bitcoin#5820
(cherry picked from commit aeb9279)
reddink pushed a commit to reddcoin-project/reddcoin-3.10 that referenced this pull request Jul 14, 2020
With headers-first we can compare against the best header timestamp, rather
than using checkpoints which require code updates to maintain.

Rebased-From: 85da07a
Github-Pull: bitcoin#5820
(cherry picked from commit aeb9279)
@bitcoin bitcoin locked as resolved and limited conversation to collaborators Sep 8, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants