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.

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

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.