Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
Already on GitHub? Sign in to your account
Full node guide: describe blocks-only mode #1596
Conversation
wbnns
added
the
Merge Scheduled
label
May 13, 2017
|
Thanks Mr. Dave. Unless others object, this will be merged on Sunday, May 14th (tomorrow). |
wbnns
self-assigned this
May 13, 2017
wbnns
merged commit b9ca0ca
into
bitcoin-dot-org:master
May 14, 2017
1 check passed
continuous-integration/travis-ci/pr
The Travis CI build passed
Details
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
harding commentedMay 13, 2017
Closes #1544 (CC: @chris-belcher )
I tried checking my assertions about bandwidth usage by starting my node with
-blocksonlyand then usingbitcoin-cli getnettotals, but the bandwidth reported used by that was 20% less than the combined size of the blocks I downloaded during the 90 minute test according tobitcoin-cli getblock <hash> | jq .size.It's possible this is for some reason I don't know, but my guess is that it's because I had a saved mempool from before my restart so my node was able to make use of compact blocks. However, the overhead for the upload bandwidth is consistent with the 1 MB I estimated and so I think we're fine saying 150 MB download bandwidth to account for changing peer connections and occasional stale blocks, plus the occasional fun times when someone running Bitcoin Unlimited produces and relays invalid blocks with sufficient PoW that we download them.