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

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 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).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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])
Copy link
Contributor

@theuni theuni Mar 1, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@molxyz
Copy link

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 ?

@harding
Copy link
Contributor Author

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
Copy link
Contributor Author

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 commented Mar 7, 2017

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

@laanwj
Copy link
Member

laanwj commented Mar 7, 2017

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

Yep. Just tagged.

Great post!

@harding
Copy link
Contributor Author

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
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 commented Mar 8, 2017

Added commit hashes in 1536a4d

@btcdrak
Copy link
Contributor

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
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants