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:

This comment has been minimized.


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:

- **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.

This comment has been minimized.

@sipa

sipa Aug 17, 2016

"will not behave differently when segwit is activated" sounds confusing. What about "It does not support segwit on mainnet, so upgrading to a future version will be needed"?

steps](https://bitcoincore.org/en/2016/06/24/segwit-next-steps/)
BitcoinCore.org blog post

- [BIP141: Segregated witness (consensus

This comment has been minimized.

@sipa

sipa Aug 17, 2016

Links to BIP 143, BIP 144, BIP 145?


2. After the transaction was confirmed, as part of a group of transactions contained in a newly-mined block being relayed across the network.

There's no need for the node to receive the transaction a second time if it still has the first copy, so compact block relay (BIP152) allows a node to receive from its peers an ordered list of what transactions are included in a new block so that the node can use the transactions it has already received to partly or fully reconstruct the transactions part of the block for itself. If the node doesn't receive all the transactions it needs to fully reconstruct the block, it requests the missing transactions from its peers, and then uses them to complete the block.

This comment has been minimized.

@sipa

sipa Aug 17, 2016

That's a pretty long sentence.


![Compact Blocks diagram](https://raw.githubusercontent.com/bitcoin/bips/master/bip-0152/protocol-flow.png)

Compact blocks provides two very important benefits to the network:

This comment has been minimized.

@sipa

sipa Aug 17, 2016

"3. Faster propagation of blocks across the network, by dramatically reducing the amount of data that needs to be transported at the time a block is found." ?

This comment has been minimized.

@instagibbs

instagibbs Aug 18, 2016
Contributor

  • "and opportunistically sending small amounts of data to peers that ask for it"?

- [Compact Block Relay FAQ](/en/2016/06/07/compact-blocks-faq/)

- [BIP152][], which describes the compact blocks protocol

This comment has been minimized.

@sipa

sipa Aug 17, 2016

This link does not work?

This comment has been minimized.

@btcdrak

btcdrak Aug 17, 2016
Contributor

It should pick up from the _references.md


Prior to Bitcoin Core 0.13.0, nodes didn't tell each other what minimum fee rate they were using, which could lead to wasted bandwidth. For example, Alice sends Bob a transaction without realizing that the transaction's fee rate is below Bob's minimum. Because of the way Bitcoin transactions are relayed, Bob has no way of knowing that the transaction is below his limit until he has already downloaded the whole transaction, at which point he stops processing the transaction because its fee rate is too low, so both his bandwidth and Alice's bandwidth end up being wasted.

Bitcoin Core 0.13.0 supports a new message that has been added to the peer-to-peer (P2P) protocol, the `feefilter` message, which has been designed to help eliminate this wasted bandwidth. This P2P message allows Bob to tell Alice what he is currently using as his minimum relay fee rate so that Alice will not bother trying to relay to him any transactions that pay a fee below his rate.

This comment has been minimized.

@sipa

sipa Aug 17, 2016

Link to BIP133?

EDIT: nevermind.

@sipa
Copy link

@sipa 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.

This comment has been minimized.

@instagibbs

instagibbs Aug 18, 2016
Contributor

perhaps mention propagation speedup as well

@instagibbs
Copy link
Contributor

@instagibbs instagibbs commented Aug 18, 2016

LGTM aside from all the links.

@harding harding force-pushed the release-0.13.0 branch from 2bccd28 to 10bb8e2 Aug 18, 2016
@harding
Copy link
Contributor Author

@harding 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.

This comment has been minimized.

@sdaftuar

sdaftuar Aug 19, 2016

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.

This comment has been minimized.

@harding

harding Aug 22, 2016
Author Contributor

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

This comment has been minimized.

@sdaftuar

sdaftuar Aug 23, 2016

@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

@jonasschnelli jonasschnelli commented Aug 19, 2016

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

This comment has been minimized.

@sdaftuar

sdaftuar Aug 22, 2016

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

This comment has been minimized.

@harding

harding Aug 22, 2016
Author Contributor

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

@harding
Copy link
Contributor Author

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

@sdaftuar sdaftuar commented Aug 23, 2016

@harding Looks good, thanks!

@sipa
Copy link

@sipa sipa commented Aug 23, 2016

Looks great, thanks!

@btcdrak
Copy link
Contributor

@btcdrak 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.

@btcdrak btcdrak merged commit 5203632 into gh-pages Aug 23, 2016
1 check passed
1 check passed
continuous-integration/travis-ci/push The Travis CI build passed
Details
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
Linked issues

Successfully merging this pull request may close these issues.

None yet

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