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

0.14.0 proposed release blog post #340

Merged
merged 7 commits into from Mar 8, 2017
Merged

Conversation

@harding
Copy link
Contributor

@harding harding commented Mar 1, 2017

This PR proposes a blog post to be used for the 0.14.0 release. A preview of the formatted blog post may be seen here: http://imgur.com/a/Jtkji

There are a few FIXMEs left:

  • Add final 0.14.0 release notes in appropriate file
  • Add final block height for assumed valid blocks to FIXME in this file
  • Update FIXME in the permalink URL to use the UTC release date
  • Add shasums for final release to FIXME in bottom of this file

Also, if I find some extra time before the release, I'd like to create a wiki page explaining assumed valid blocks and add a link to that in this PR as I suspect that some people might get confused about the difference between assumed valid blocks and checkpoints.

I know there were many more changes made in 0.14.0 than the ones described in this PR and I'm happy to try describing any ones ya'll think are important---just let me know. I just wanted to get this PR up ASAP so it could get some review in the seemingly-likely case that RC3 becomes the final release.

@harding harding added the blog label Mar 1, 2017
@morcos
Copy link

@morcos morcos commented Mar 1, 2017

Description of the BIP 152 changes isn't quite correct.
In 0.13.1 (or whenever we added BIP 152) we already were using High Bandwidth mode, we just weren't taking advantage of the ability to start the relay before validating the block. HB mode just refers to announcing via cmpctblock instead of announcing via headers and letting the peer request the cmpctblock. The change in 0.14 to relay before validation is still very significant however.


The third feature improved in Bitcoin Core 0.14.0 is the entire set of P2P networking code, which has been refactored to support increased concurrency and throughput. The concurrency improvements help allow newly-received blocks (such as BIP152 compactblocks) to be processed ahead of lower-priority traffic, ensuring that blocks are relayed and validated as fast as possible.

The refactor also now allows network activity to continue on spare CPU processors during validation, providing an improvement in IBD speed that complements the [headers-first sync][] introduced in Bitcoin Core 0.10.0 (see [above][ibd] for more information).

This comment has been minimized.

@theuni

theuni Mar 1, 2017
Contributor

s/on spare CPU processors/in the background/. Even single-core CPUs benefit here.

s/during validation, providing/during message processing, notably providing/. Latency for all message handling is reduced, it's just most apparent during IBD.


This 0.14.0 release includes two more improvements that significantly increase IBD speed:

1. **Assumed valid blocks** takes the optimization introduced in Bitcoin 0.5.0 of skipping verification of historic signatures and separates it from the checkpoints mechanism that was introduced in Bitcoin 0.3.2 to prevent denial-of-service attacks during IBD. Assumed valid blocks allows users to tell Bitcoin Core about a block they consider to be valid so that Bitcoin Core can skip verifying signatures in preceding blocks. Bitcoin Core 0.14.0 also ships with a default valid block ([block FIXME:height][], FIXME:date), which the user can either disable or change. ([Learn more][assumed valid blocks])

This comment has been minimized.

@theuni

theuni Mar 1, 2017
Contributor

I think it's worth mentioning that this is an improvement over checkpoints because it doesn't force a node onto a particular chain, rather, if a node is checking a block that is an ancestor of a known-good one, script checking can be skipped.

That's nice because it allows for developers to assert a fact in code (block X and its ancestors are valid), rather than stating "we strongly believe that Y is the valid chain with the most work at this time"

Edit: I missed your comment in the OP about this. 100% agree with a more detailed wiki page, but it'd be nice if this were a little more clear here.


[assumed valid blocks]: https://github.com/bitcoin/bitcoin/blob/0.14/doc/release-notes.md#introduction-of-assumed-valid-blocks

The speed of the previous release (Bitcoin Core 0.13.2) was compared to the speed of this Bitcoin Core 0.14.0 release using Amazon EC2 virtual private servers, type `t2.xlarge` with four cores and 16 GB memory at a cost of $0.188 USD per hour. All Bitcoin Core settings were left at their defaults.

This comment has been minimized.

@theuni

theuni Mar 1, 2017
Contributor

$0.188 USD per hour (block storage costs excluded).

@molxyz
Copy link

@molxyz molxyz commented Mar 1, 2017

The blog post is great, except maybe the word "send" which should be "sends" in the first sentence of this paragraph: http://i.imgur.com/fvoYNj6.png ?

Suggested by morcos.
@harding harding force-pushed the harding:release-0.14.0 branch from 0fe7a0d to 5018db4 Mar 1, 2017
@harding
Copy link
Contributor Author

@harding harding commented Mar 1, 2017

@morcos Thanks for clarifying! Commit 5018db4 should fix the problem. The revised section looks like this:

2017-03-01-12_26_21_819110617

harding added 2 commits Mar 1, 2017
@harding
Copy link
Contributor Author

@harding harding commented Mar 1, 2017

@theuni commit d84d49c addresses your minor concerns (thanks!).

Everyone, including @theuni, commit 700b4b6 describes assumed valid blocks in more detail, including the fact that they don't lock the chain like checkpoints. I've pasted a screenshot of a preview of the section below for those who prefer to read formatted text.

@molxyz the text you're referring to was coincidentally changed in commit 5018db4 , which I think resolves your issue. Thank you for letting me know, though.

screenshot-127 0 0 1 4000 2017-03-01 16-00-29

@btcdrak
Copy link
Contributor

@btcdrak btcdrak commented Mar 7, 2017

@harding: @laanwj said he was going to tag shortly.

@laanwj
Copy link
Member

@laanwj laanwj commented Mar 7, 2017

@harding: @laanwj said he was going to tag shortly.

Yep. Just tagged.

Great post!

harding added 3 commits Mar 7, 2017
@harding
Copy link
Contributor Author

@harding harding commented Mar 7, 2017

Pushed commits to add the release notes, set the release date everywhere (to today), and to add the release assumedvalid block hash. The only TODO left is to add the release hashes into the file _posts/en/posts/2017-03-07-release-0.14.0.md , which can probably be done at merge time or after. Feel free to squash.

I've been using the RCs and so have already seen many of these nice improvements in action, so thank ya'll for all of your work on them!

@btcdrak btcdrak merged commit 5080221 into bitcoin-core:gh-pages Mar 8, 2017
1 check passed
1 check passed
continuous-integration/travis-ci/pr The Travis CI build passed
Details
btcdrak added a commit that referenced this pull request Mar 8, 2017
5080221 0.14.0 release: rename final to correct date (David A. Harding)
c9eddb8 0.14.0 release: add final assumedvalid block hash (David A. Harding)
dee1869 0.14.0 release: add release notes (David A. Harding)
700b4b6 0.14.0 relase blog: describe assumed valid blocks in more detail (David A. Harding)
d84d49c 0.14.0 release blog: minor fixes (David A. Harding)
5018db4 0.14.0 blog: edits to compactblock section (David A. Harding)
d5f75f2 0.14.0 release blog post (David A. Harding)
@btcdrak
Copy link
Contributor

@btcdrak btcdrak commented Mar 8, 2017

Added commit hashes in 1536a4d

@btcdrak
Copy link
Contributor

@btcdrak btcdrak commented Mar 8, 2017

@harding Again, thank you so much for stepping forward. It's always a pleasure and an incredible help.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

6 participants
You can’t perform that action at this time.