IRC meeting summary for 2017-01-12

• Link to this week logs
• Meeting minutes by meetbot

Main topics

• 0.14 feature freeze

0.14 feature freeze

background

Bitcoin Core 0.14 is scheduled to be released around March 2017. Open pull request aimed for 0.14 are tagged with a 0.14 tag.

meeting comments

The feature freeze for 0.14 is scheduled for Monday 2017-01-16.

PR’s #9499 (Use recent-rejects, orphans, and recently-replaced txn for compact-block-reconstruction), #9375 (Relay compact block messages prior to full block connection) and #9441 ( Massive speedup. Net locks overhaul) are probably close enough to make it.

Multiwallet is at least 2 PR’s away and not not something that’s safe enough to merge last minute and let people test it in a release candidate.

Bugfixes can still go in after Monday. BlueMatt thinks #9519 (Exclude RBF replacement txs from fee estimation) and #9512 (Fix various things -fsanitize complains about) are bugfixes that should still go in. Wumpus worries about the +/- 1.5% performance hit on hashing the latter gets from these changes. Sipa thinks he has a version that fixes the issues without the performance hit (even a very slight performance increase).

#9484 (Introduce assumevalid setting) which is a way of skipping script validation without using checkpoints, would also be nice to get in.

Morcos thinks it’s important to consider #9380 (Separate different uses of minimum fees) for 0.14 as well, since currently if a miner changes the -minrelaytxfee it automatically changes their definition of dust, which occasionally leads to transactions with high feerates not being minable by some portion of miners. It also hurts fee estimation which is potentially more serious.

BlueMatt wonders if some PR’s should be untagged for 0.14, like #8456, #8501, #8654, #8723 or #8755.

Jonasschnelli would like to see #9294 (Use internal HD chain for change outputs) going in as well as #9377 (fundrawtransaction: Keep change-output keys by default), but the latter is a bugfix, which can go in later. The former would avoid creating more single-chain HD wallets, so it’s valuable to get it in sooner than later. The downside is newly created wallets can’t be used on old software for versions 0.13, 0.14 and probably 0.15 which will introduce flexible keypaths. As long as a wallet being touched by a new version doesn’t automatically make it incompatible, everyone is fine with that.

Jonasschnelli thinks #9461 (Improve progress display) is a simple change that can get into 0.14.

BlueMatt realizes he forgot about the cs_vSend split which was included in #9419 (Stop Using cs_main for CNodeState/State()) but is a big win by itself.

meeting conclusion

• Don’t do multiwallet in 0.14
• Review #9484, #9380, net related: #9499, #9375, #9441 and wallet related: #9294, #8456
• Untag #8501, #8654, #8723 and #8755

Comic relief

jonasschnelli    The sad thing is, it will be another feature that is not downward compatible.
sipa             breaking backward compatibility in major releases is fine
wumpus           don't you mean forwards compatible? backwards compatible means that it can use old wallets, which should always be possible
jonasschnelli    wumpus: right. My fault.
sipa             backward compatible means that old software can use new wallets
jonasschnelli    perspective thing. :)
wumpus           huh? I thought the other way around.
sipa             forward compatible is what you normally always have
wumpus           I don't understand it anymore then
sipa             oopz
sipa             maybe i am wrong too
sipa             i will shut up
jtimon           all these backwards and forwards compatibility is confusing, softfork and hardforks are much more clear :p

Participants

Disclaimer

This summary was compiled without input from any of the participants in the discussion, so any errors are the fault of the summary author and not the discussion participants.