-
Notifications
You must be signed in to change notification settings - Fork 38.7k
Better fingerprinting protection for non-main-chain getdatas. #5820
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
Conversation
With headers-first we can compare against the best header timestamp, rather than using checkpoints which require code updates to maintain.
|
Code review ACK; I didn't try to test. |
|
ut ACK |
|
Tested; works as expected. |
|
utACK |
85da07a Better fingerprinting protection for non-main-chain getdatas. (Pieter Wuille)
|
Backported to 0.10 as aeb9279 |
|
@SergioDemianLerner How about an nbits test? |
|
@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? |
|
We have several possibilities:
pcheckpoint = last check point
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. |
|
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.
|
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)
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)
With headers-first we can compare against the best header timestamp, rather than using checkpoints which require code updates to maintain.