IRC meeting summary for 2017-06-01
Notes / short topics
- Luke-jr raises the concern that blocks cause DoS penalties for invalid prev-blocks and for sending headers that “don’t” connect (because we rejected an earlier invalid header), which might be a problem for softforks. There’s been a different issue raised before around DoS protection, which might have similar solutions. Therefore Sdaftuar recommends to continue the discussion in #9530.
- Everything for 0.14.2 is backported and merged, so 0.14.2 can be tagged for release and RC1 can be created.
- High priority features for 0.15
High priority features for 0.15
Bitcoin Core 0.15 is scheduled for release around 2017-09-01. Sdaftuar wants to talk about which features should get high priority for the 0.15 release.
- Jtimon would like to get his PR #8994 (testchains) in.
- Sdaftuar would like to see BlueMatt’s #10192 (script cache) go in, as it is a huge validation win. Luke-jr notes it might be problematic for his proposed future softforks where script features require chain-context like CHECKBLOCKVERSION and possibly CHECKBLOCKATHEIGHT. Sipa thinks it’s solvable by storing the context-dependent script validation flags along with the entry in the cache.
- Cfields wonders if removing openSSL for 0.15 is still a goal. Sipa thinks it shouldn’t be a priority, but that it should happen eventually. It will probably come naturally once the pseudorandom number generator has undergone a few more improvements
High priority review
- Jonasschnelli wants to have PR #10240 (HD wallet auto-restore) in Bitcoin Core 0.15.
- Jtimon still asks for PR #10339 (Calculate block hash less times) to be reviewed.
- Sipa is currently squashing PR #10195 ( Switch chainstate db and cache to per-txout model) and would like to request review on PR #10321 (Use FastRandomContext for all tests) after that.
- Ryanofsky wants to add #10244, however that should be done after the multiwallet base gets in.
- Jtimon notes #7729 (label API for wallet) needs a rebase. Gmaxwell worries it might be difficult to extend the API later to support multiple labels per transaction. Jonasschnelli clarifies it can be extended perfectly, but we should get it done as we’ve been talking about deprecating the account system for a long time now.
|wumpus||Wladimir van der Laan|
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.