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

Tweaks to BIP 157/158 #699

Merged
merged 2 commits into from Aug 9, 2018
Merged

Tweaks to BIP 157/158 #699

merged 2 commits into from Aug 9, 2018

Conversation

@jimpo
Copy link
Contributor

jimpo commented Jul 10, 2018

With filter sizes at ~2% of block size, reducing getcfilter request size to 100 corresponds to a response with equal bandwidth to ~2 blocks.

@jimpo jimpo force-pushed the jimpo:bip-157-158 branch from 2c1a666 to b88d5b6 Jul 10, 2018
@jimpo

This comment has been minimized.

Copy link
Contributor Author

jimpo commented Jul 23, 2018

@luke-jr luke-jr merged commit fa7035f into bitcoin:master Aug 9, 2018
1 check passed
1 check passed
continuous-integration/travis-ci/pr The Travis CI build passed
Details
Roasbeef added a commit to Roasbeef/bips that referenced this pull request Oct 25, 2019
In this commit, we effectively revert bitcoin#699 by allow clients to request
filter for up to 1k consecutive blocks. Testing in the field has shown
that applications are able to reduce perceived latency from syncing to
full functionality after an app has been offline for several days by
batching requests for filters. A value of 100 would mean each additional
day behind adds an additional round trip, resulting in 10s of
seconds of lag after just a few days of being offline. A value of ~1k
allows implementations to catch up with roughly a week's worth of
filters in a single round trip.
Roasbeef added a commit to Roasbeef/bips that referenced this pull request Oct 25, 2019
In this commit, we effectively revert bitcoin#699 by allow clients to request
filter for up to 1k consecutive blocks. Testing in the field has shown
that applications are able to reduce perceived latency from syncing to
full functionality after an app has been offline for several days by
batching requests for filters. A value of 100 would mean each additional
day behind adds an additional round trip, resulting in 10s of
seconds of lag after just a few days of being offline. A value of ~1k
allows implementations to catch up with roughly a week's worth of
filters in a single round trip.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.