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

Release 0.13.0: Add release notes and announcement blog post #199

Merged
merged 6 commits into from Aug 23, 2016

Conversation

harding
Copy link
Contributor

@harding harding commented Aug 5, 2016

Similar to previous releases, this PR adds the following two new pages to the site:

  • A new page with release notes from Bitcoin Core source tree (verbatim except for a Markdown formatting change described below)
  • A new blog post announcing the release and describing some of its many improvements. Feedback appreciated. Preview

Todo

Edit 2016-08-22: If 0.13.0 is released on August 23rd, then both of the todos below are done.

  • Update dates in this PR to the actual release date
    • _posts/en/posts/2016-08-23-release-0-13-0.md should have its filename and the permalink field in its YAML header changed to the actual release date
    • _posts/en/releases/2016-08-23-release-0.13.0.md should have its filename changed to the actual release date
  • If necessary, update _posts/en/releases/2016-08-23-release-0.13.0.md to the current release notes. It is currently on bitcoin/bitcoin@a402396
    • If you update, you can just paste the raw contents of the release notes from the Bitcoin Core source tree into the file below the YAML header. After doing that you need to make the following substitution over the whole file to fix a difference between GitHub-flavor Markdown and whatever we use on BitcoinCore.org: s/- #/- \\#/

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.

- 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:
Copy link

Choose a reason for hiding this comment

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

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.

@sipa
Copy link

sipa commented Aug 17, 2016

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

Choose a reason for hiding this comment

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

perhaps mention propagation speedup as well

@instagibbs
Copy link
Contributor

LGTM aside from all the links.

@harding
Copy link
Contributor Author

harding commented Aug 18, 2016

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 ([text][reference]) were correctly rendered into hyperlinks.

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.

Choose a reason for hiding this comment

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

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@sdaftuar

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!

Choose a reason for hiding this comment

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

@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!

@jonasschnelli
Copy link
Contributor

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

Choose a reason for hiding this comment

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

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").

Copy link
Contributor Author

@harding harding Aug 22, 2016

Choose a reason for hiding this comment

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

@sdaftuar I pushed commit ba8717a which I think fully addresses your concerns with a minimum of edits. Thanks!

@harding
Copy link
Contributor Author

harding commented Aug 22, 2016

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.

@sdaftuar
Copy link

@harding Looks good, thanks!

@sipa
Copy link

sipa commented Aug 23, 2016

Looks great, thanks!

@btcdrak
Copy link
Contributor

btcdrak commented Aug 23, 2016

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.

@kanzure
Copy link

kanzure commented Aug 23, 2016

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-August/013055.html

@btcdrak btcdrak merged commit 5203632 into gh-pages Aug 23, 2016
btcdrak added a commit that referenced this pull request Aug 23, 2016
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)
@btcdrak btcdrak deleted the release-0.13.0 branch Jul 16, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants