IRC meeting summary for 2016-07-28
Notes / short topics
- Jtimon would like to see the removal of ISM, talked about in last weeks meeting, merged quickly as it is important for other libconsensus refactors.
- NicolasDorier asks to review/test PR #8422 (Cache hashes), which needs to be merged and backported to 0.13 before segwit release.
- boost threads/sync replacement for master
PR #8408, which fixes a bug in compactblocks, is the only thing remaining that’s tagged for 0.13.
Jtimon made PR #8412, which he thinks should be included in 0.13. Everyone agrees.
Luke-jr reiterates the release notes have a bad policy of encouraging changing blockmaxsize to blockmaxweight for which he has a pull request including some codechanges. Wumpus notes not everyone agrees on what is ‘bad policy’. Luke-jr argues if that’s the case the release notes should not recommend anything. Gmaxwell thinks it’s foolish we’re still releasing with default settings that don’t reflect near ubiquitous network usage as in practice nearly every miner will set blockmaxsize and blockmaxweight to the maximum allowed value. Default has been 750k, however there are no 750k blocks to be seen. (at this point in the discussion luke-jr has to catch his plane)
Wumpus thinks a positive consequence of these settings is that it forces miners to not use the default settings. Gmaxwell also notes changing the value of blockmaxweight is more complicated as it needs to be 4 times the desired blockmaxsize, explaining how to set this to the maximum value in the release notes might be seen as a recommendation though. Eliel_ suggests the option of making the mining part refuse to function without the user manually setting the required configuration values, therefor avoiding setting default values, which is something luke-jr argued for years.
- review PR #8408 (Prevent fingerprinting, disk-DoS with compact blocks)
boost threads/sync replacement for master
Bitcoin Core is working towards removing the dependency on the boost library. Cfields has a pull request ready to move away from boost threads.
Cfields asks if he should do the replacements one chunk at the time, or all in one go. Wumpus states it makes the most sense to do it all at once, to make it just a one-time pain.
|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.