Release 0.13.0: Add release notes and announcement blog post #199
Conversation
- New page with release notes from Bitcoin Core source tree - New post with description of some notable changes
| {% include _toc.html %} | ||
| {% include _references.md %} | ||
|
|
||
| We're pleased to announce the official release of Bitcoin Core 0.13.0. During the six-month development cycle leading to this release, [dozens of contributors][release notes contributors] have made [hundreds of notable improvements][release notes changelog] to Bitcoin Core. Among the many upgrades available in this release, the following may be especially interesting to miners, node operators, and wallet users: |
There was a problem hiding this comment.
The links don't seem to work in the github rendered view (https://github.com/bitcoin-core/bitcoincore.org/blob/4d1897a01e4f136d2916d248c3c71d0d78479999/_posts/en/posts/2016-08-05-release-0-13-0.md), but I assume that is intentional.
|
Nice work! Only a few nits above. |
|
|
||
| - **Preparation for segregated witness** to increase capacity, eliminate unwanted transaction malleability, and enable new ways to upgrade Bitcoin's Script language using soft forks. The code in this release prepares for segwit only; it does not activate segwit on mainnet and will not behave differently when segwit is activated. | ||
|
|
||
| - **Compact block relay** on the peer-to-peer network to eliminate a major source of redundant data transfer among nodes that relay transactions, as well as reduce the peak amount of bandwidth those nodes use when downloading newly-generated blocks. |
There was a problem hiding this comment.
perhaps mention propagation speedup as well
|
LGTM aside from all the links. |
harding
force-pushed
the
release-0.13.0
branch
from
2bccd28 to
10bb8e2
Compare
|
Pushed commit 7514929 which I believe resolves all feedback from @sipa and @instagibbs . Also pushed commit 10bb8e2 which updates the 0.13.0 release notes to the same content as bitcoin/bitcoin@a402396 . I also rendered the page locally and verified that all reference-style links ( Thanks for the reviews! |
|
|
||
| ## Fee filtering | ||
|
|
||
| For several years now, Bitcoin Core nodes have used a minimum relay fee rate to determine what unconfirmed transactions they'll process, relay, and store in their individual memory pools. Each node gets to decide its own minimum relay fee rate, and if they receive a transaction whose fee rate is below that limit, they don't add it to their memory pools or relay it to their other peers. |
There was a problem hiding this comment.
I think the language in this paragraph and the next are slightly confusing. The min relay fee that Bitcoin Core nodes have historically had isn't a true minimum, in that free transactions would still get relayed (though rate-limited) by default.
It's only due to the mempool limiting introduced in 0.12 that causes nodes to get into a state where no new transactions are accepted below some "minimum mempool fee" (which is a function of the minimum relay fee, the transactions which have been evicted from the mempool, and how much time has passed).
Specifically, it's the minimum mempool fee that is broadcast in fee filter messages. If the mempool fee is not in effect, eg because the mempool isn't full and hasn't been for a while, then no feefilter messages would be sent, regardless of what the -minrelaytxfee is.
There was a problem hiding this comment.
The min relay fee that Bitcoin Core nodes have historically had isn't a true minimum, in that free transactions would still get relayed (though rate-limited) by default.
I've added commit 2d0d7af to mention tx priority, which hopefully clears up this inaccuracy.
It's only due to the mempool limiting introduced in 0.12 that causes nodes to get into a state where no new transactions are accepted below some "minimum mempool fee"
If I understand your comment correctly, I think it's only correct if we assume that every node uses the same minimum relay fee. Prior to 0.12, I almost always customized my minrelayfee, and I believe in one of the 0.11.x releases it was recommend for low-memory users to customize their minrelayfee (and, IIRC, in another 0.11.x, the default minrelayfee was temporarily increased). This leads me to believe that even if I'm the only weirdo who customized his minrelayfee policy that historically a significant number of nodes were connecting to peers who had different minrelayfees and so bandwidth was being wasted when a node with a higher minrelayfee setting relayed transactions to a peer with a lower minrelayfee setting.
I wrote this section with that in mind, generalizing the situation across all modern releases to help keep it both correct, simple, and short for this announcement blog post which is almost certain too long already. :-) I understand that the fixed-size mempools introduced in 0.12.0 with their variable minrelayfees aggravated the historic problem with wasted bandwidth and helped motivate the development of feefilter, but I'm not sure we need to go into that level of detail (but we can, if you think it's important).
If I've misunderstood your comment (or the technology), please let me know and I can make additional edits. Thanks!
There was a problem hiding this comment.
@harding Yeah I can appreciate that the nuance here is hard to get right for a general audience! On further thought, I think your text is fine as-is -- the details here are probably not so important to anyone.
Since I started this comment though I might as well clarify the technology to make sure we're all on the same page: When an 0.13.0 node is started up, no fee filter messages are sent, no matter what you set your minrelaytxfee to. It's not until the mempool fills up and some stuff gets evicted from it that a node will start sending feefilter messages.
So no bandwidth is saved until the mempool fills up. Once the mempool does fill up, then it is true that the feefilter message will be generated, and its value will be at least as large as your minrelaytxfee (or higher, if transactions with feerates higher than your minrelayfee are getting evicted from the mempool). But I'd imagine that if you set your minrelaytxfee to be very high, then you'd not save any bandwidth at all, because your mempool would never get full, so you'd never send a feefilter message.
Given that (a) mempools are generally full, and (b) we're even contemplating changing the behavior to be more along the lines of what you described anyway (maybe even for 0.13.1), the micro-detail about this only kicking in currently when mempools are full is not so important.
Thanks for writing this up!
|
ACK the HD wallet part. The only thing that's missing is the possible xpriv export over dumpwallet, but not urgently required. |
|
|
||
| - [BIP32: Hierarchical Deterministic Wallets][BIP32] | ||
|
|
||
| ## Child pays for parent mining |
There was a problem hiding this comment.
I don't think we should think of this as "child pays for parent mining", but instead as "ancestor fee rate mining", or something akin to that (which highlights the actual transaction selection algorithm).
In my view, "child pays for parent" is a wallet behavior, not a mining algorithm. The mining algorithm introduced in 0.13 generally optimizes miner revenue better than the old algorithm, regardless of user behavior.
It is of course the case that wallets engaging in behaviors like "child pays for parent" -- ie putting a higher fee on a transaction that has an unconfirmed, lower fee parent -- should benefit from miners using 0.13.0 being smart enough to mine such transactions when optimal to do so. But the right way of thinking about the mining algorithm is not in terms of particular user behavior we want to pick out; we should generally be thinking about how to make the mining code more optimal in general, and robust to any kind of user behavior.
So my suggestion for this section would be to describe the mining algorithm more along the lines of how it actually works (which could be as simple as saying it considers transactions for inclusion after sorting them by their feerate with unconfirmed parent transactions). And then only use the term CPFP to describe wallet behaviors that will now work better as a result of this change.
In particular I'd strike the word "mining" from the title of this section (so it's just "Child pays for parent").
|
I think this should be ready to go. Filenames and metadata have been updated to assume a release date of 2016-08-23 UTC, and I've tried to address the most recent feedback. |
|
@harding Looks good, thanks! |
|
Looks great, thanks! |
|
ACK from me. Once the announcement is made I would also like to add the signed PGP release announcement both to the website, and linked to the ML. I can do that post merge. |
5203632 0.13.0 Release: Update file names (David A. Harding) ba8717a 0.13.0 Release: CPFP -> ancestor fee rate mining (David A. Harding) 2d0d7af 0.13.0 Release: mention tx priority for allowing low-fee txes (David A. Harding) 10bb8e2 Release 0.13.0: update release notes (David A. Harding) 7514929 Release 0.13.0: minor edits to release blog (David A. Harding) 4d1897a Release 0.13.0: Add release notes and announcement blog post (David A. Harding)
Similar to previous releases, this PR adds the following two new pages to the site:
Todo
Edit 2016-08-22: If 0.13.0 is released on August 23rd, then both of the todos below are done.
_posts/en/posts/2016-08-23-release-0-13-0.mdshould have its filename and thepermalinkfield in its YAML header changed to the actual release date_posts/en/releases/2016-08-23-release-0.13.0.mdshould have its filename changed to the actual release date_posts/en/releases/2016-08-23-release-0.13.0.mdto the current release notes. It is currently on bitcoin/bitcoin@a402396s/- #/- \\#/I'll try to keep on top of both of the above todos so that this stays ready for merge when 0.13.0 is released.