0.14.0 proposed release blog post #340
Conversation
|
Description of the BIP 152 changes isn't quite correct. |
|
|
||
| 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). |
There was a problem hiding this comment.
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]) |
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
$0.188 USD per hour (block storage costs excluded).
|
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.
|
@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.
|
|
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 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! |
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)
|
Added commit hashes in 1536a4d |
|
@harding Again, thank you so much for stepping forward. It's always a pleasure and an incredible help. |
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:
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.