Better fingerprinting protection for non-main-chain getdatas. #5820

1. 
   sipa commented at 12:52 pm on February 24, 2015: member

   With headers-first we can compare against the best header timestamp, rather than using checkpoints which require code updates to maintain.
2. Better fingerprinting protection for non-main-chain getdatas.

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

   85da07a5a0
3. 
   gavinandresen commented at 4:20 pm on February 24, 2015: contributor

   Code review ACK; I didn’t try to test.
4. 
   jgarzik commented at 5:05 pm on February 24, 2015: contributor

   ut ACK
5. 
   sdaftuar commented at 9:04 pm on February 24, 2015: member

   Tested; works as expected.
6. 
   laanwj commented at 4:07 pm on February 26, 2015: member

   utACK
7. laanwj merged this on Feb 26, 2015
8. laanwj closed this on Feb 26, 2015

   ---

9. laanwj referenced this in commit 59310f1c02 on Feb 26, 2015
10. sipa referenced this in commit aeb9279228 on Feb 26, 2015
11. 
    laanwj commented at 4:16 pm on February 26, 2015: member

    Backported to 0.10 as aeb92792281b4cb9958f3defc9e36f63e65b778a
12. 
    gmaxwell commented at 1:56 am on March 7, 2015: contributor

    @SergioDemianLerner How about an nbits test?
13. 
    sipa commented at 1:07 pm on March 7, 2015: member

    @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?
14. 
    SergioDemianLerner commented at 3:27 pm on March 7, 2015: 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.

15. 
    sipa commented at 5:22 pm on March 7, 2015: member

    Another alternative is using “equivalent PoW-days”. You look at the difference in nChainWork between the requested block and the best known header, divided by the best difficulty seen, multiplied by the block interval. This yields something with time units: the amount of time an attacker with 100% of the current observable hash rate would need to expend to build on top of the fork to beat the main chain. Accept requests of a block when this time value is less than some constant.

    Also, I don’t believe this actually hurts reorganizations. The new blocks to reorg to can always be requested from the peer who has already switched to it. The only reason why you’d allow requests for blocks outside of your own best chain, is because during a reorg your own view of the best chain may chain between an inv and the receipt of a getdata in response. Not answering could delay convergence (but only a bit, there are timeouts). One month of desync time is probably serious overkill, but given that the hashrate can hardly drop in such a time frame, it already makes fingerprinting very expensive.

16. reddink referenced this in commit 7c71ddec72 on Jul 11, 2020
17. reddink referenced this in commit 682ed33f9c on Jul 14, 2020
18. MarcoFalke locked this on Sep 8, 2021

Contributors
sipa gavinandresen jgarzik sdaftuar laanwj gmaxwell SergioDemianLerner