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

Replace global trickle node with random delays #7125

Merged
merged 1 commit into from Dec 14, 2015

Conversation

Projects
None yet
6 participants
@sipa
Member

sipa commented Nov 28, 2015

This is based upon and partially replaces #5989, and rebased on top of #7100.

We used to have a trickle node, a node which was chosen in each iteration of the send loop that was privileged and allowed to send out queued up non-time critical messages. Since the removal of the fixed sleeps in the network code, this resulted in fast and attackable (see #7123) treatment of such broadcasts.

This pull request changes each of these trickle-dependant mechanisms with a per-node and per-feature random delay timer, improving privacy and performance by making queueing useful again.

The commits are mostly squashed/rebased versions taken from #5989 by @pstratem, except:

  • No randomization of tx invs (more code changes, and may not interact well with transactions that need to be sent after their dependencies).
  • No removal of the "1/4 blast to all" behaviour, as #7123 proposes an alternative.
  • No removal of the "announce yourself to outbound peers" behaviour.
@sipa

This comment has been minimized.

Show comment
Hide comment
@sipa

sipa Nov 29, 2015

Member

Rebased on top of #7125, and make blocks not use the vInventoryToSend system anymore (making it safer to make it filter like #7100).

Member

sipa commented Nov 29, 2015

Rebased on top of #7125, and make blocks not use the vInventoryToSend system anymore (making it safer to make it filter like #7100).

@sipa

This comment has been minimized.

Show comment
Hide comment
@sipa

sipa Nov 30, 2015

Member

Rebased on top of #7133.

Member

sipa commented Nov 30, 2015

Rebased on top of #7133.

@gmaxwell

This comment has been minimized.

Show comment
Hide comment
@gmaxwell

gmaxwell Dec 5, 2015

Member

Could use some rebasing love, as the bloomy stuff was merged.

Member

gmaxwell commented Dec 5, 2015

Could use some rebasing love, as the bloomy stuff was merged.

@sipa

This comment has been minimized.

Show comment
Hide comment
@sipa

sipa Dec 5, 2015

Member

Rebased.

Member

sipa commented Dec 5, 2015

Rebased.

@laanwj laanwj added this to the 0.12.0 milestone Dec 9, 2015

@laanwj

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Dec 9, 2015

Member

Some nodes connect to to as many peers as possible and flood them with pings, apparently to trigger the issue where pings interfere with trickle delays. So this is being actively exploited.

Added 0.12 milestone.

Member

laanwj commented Dec 9, 2015

Some nodes connect to to as many peers as possible and flood them with pings, apparently to trigger the issue where pings interfere with trickle delays. So this is being actively exploited.

Added 0.12 milestone.

@gmaxwell

This comment has been minimized.

Show comment
Hide comment
@gmaxwell

gmaxwell Dec 10, 2015

Member

I am currently testing this on top of 0.12.

Member

gmaxwell commented Dec 10, 2015

I am currently testing this on top of 0.12.

@morcos

This comment has been minimized.

Show comment
Hide comment
@morcos

morcos Dec 10, 2015

Member

utACK

Member

morcos commented Dec 10, 2015

utACK

@sdaftuar

View changes

Show outdated Hide outdated src/main.cpp
{
if (pto->nNextLocalAddrSend < nNow) {
AdvertizeLocal(pto);

This comment has been minimized.

@sdaftuar

sdaftuar Dec 11, 2015

Member

Should we be guarding this with a !IsInitialBlockDownload() as before?

@sdaftuar

sdaftuar Dec 11, 2015

Member

Should we be guarding this with a !IsInitialBlockDownload() as before?

@sipa

This comment has been minimized.

Show comment
Hide comment
@sipa

sipa Dec 11, 2015

Member

Addressed @sdaftuar's comment, rebased, and switched to Poisson-distributed sends, so nobody can ever make a guess about when the next send will happen.

Member

sipa commented Dec 11, 2015

Addressed @sdaftuar's comment, rebased, and switched to Poisson-distributed sends, so nobody can ever make a guess about when the next send will happen.

Replace trickle nodes with per-node/message Poisson delays
We used to have a trickle node, a node which was chosen in each iteration of
the send loop that was privileged and allowed to send out queued up non-time
critical messages. Since the removal of the fixed sleeps in the network code,
this resulted in fast and attackable treatment of such broadcasts.

This pull request changes the 3 remaining trickle use cases by random delays:
* Local address broadcast (while also removing the the wiping of the seen filter)
* Address relay
* Inv relay (for transactions; blocks are always relayed immediately)

The code is based on older commits by Patrick Strateman.
@gmaxwell

This comment has been minimized.

Show comment
Hide comment
@gmaxwell

gmaxwell Dec 14, 2015

Member

ACK

Member

gmaxwell commented Dec 14, 2015

ACK

@laanwj laanwj merged commit 5400ef6 into bitcoin:master Dec 14, 2015

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

laanwj added a commit that referenced this pull request Dec 14, 2015

Merge pull request #7125
5400ef6 Replace trickle nodes with per-node/message Poisson delays (Pieter Wuille)

sipa added a commit that referenced this pull request Dec 14, 2015

Replace trickle nodes with per-node/message Poisson delays
We used to have a trickle node, a node which was chosen in each iteration of
the send loop that was privileged and allowed to send out queued up non-time
critical messages. Since the removal of the fixed sleeps in the network code,
this resulted in fast and attackable treatment of such broadcasts.

This pull request changes the 3 remaining trickle use cases by random delays:
* Local address broadcast (while also removing the the wiping of the seen filter)
* Address relay
* Inv relay (for transactions; blocks are always relayed immediately)

The code is based on older commits by Patrick Strateman.

Github-Pull: #7125
Rebased-From: 5400ef6

@ghost ghost referenced this pull request Jan 17, 2016

Closed

Improve 0-conf tracking #16

@laanwj laanwj removed the Needs backport label Feb 4, 2016

@laanwj

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Feb 4, 2016

Member

This is cherry-picked to 0.12 as 10b88be

Member

laanwj commented Feb 4, 2016

This is cherry-picked to 0.12 as 10b88be

@dgenr8

This comment has been minimized.

Show comment
Hide comment
@dgenr8

dgenr8 Mar 17, 2018

Contributor

Where was the discussion of the choice of 5 seconds as the mean delay between inventory broadcasts? This was 7-10x the median transaction propagation time of the entire network at that time.

Contributor

dgenr8 commented Mar 17, 2018

Where was the discussion of the choice of 5 seconds as the mean delay between inventory broadcasts? This was 7-10x the median transaction propagation time of the entire network at that time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment