IRC meeting summary for 2016-12-15

• Link to this week logs
• Meeting minutes by meetbot

Notes / short topics

• Sipa and gmaxwell have been experimenting with a per-txout UTXO cache approach instead of grouping the UTXOs per transaction, but so far the results don’t look too promising. When it’s operating entirely in memory it’s 15% faster, however when levelDB comes into play it is slower. The real gains should come from making the cache smarter though, but further testing is needed for that. The reason for wanting a per-txout cache is that the current behavior may be good on average, but terrible for big transactions.

Main topics

• PR backlog/urgent PRs for 0.13.2

PR backlog/urgent PRs for 0.13.2

background

Bitcoin Core 0.13.2 brings various bugfixes and performance improvements. RC1 is estimated to be released at the end of the month or early next month.

meeting comments

PR #9322 (Don’t set unknown rpcserialversion), which returns an error if you ask for a serialization version higher than the one supported by your software, had a comment by Luke-jr who’d like to allow setting future serialization versions beyond the default. It is assumed though the default is always the latest version. Wumpus notes this can be done in a later pull request and this can be merged.

PR #9352 (Attempt reconstruction from all compact block announcements) needs to move forward quickly for FIBRE/some current network issues. Gmaxwell explains that right now, if someone sends us a header, we request a block and mark the block in flight. If a compact block (e.g. from a high-bandwidth mode sender that sends unsolicited ones) shows up while we’re waiting, we just ignore it, instead of trying to reconstruct the block. This means that if a peer is broken and slowly transmits or fails to reply, the high-bandwidth mode will fail to work around it. There is a deep rabbit hole we can go down towards optimal behavior, but what is proposed right now is a super minimal change where even if a block is in flight, we’ll still see if we can recover the whole block from just the compact block. And if we can, we take it, and mark the block as complete.

PR #9289 (net: drop boost::thread_group) is holding up the next round of changes for the network refactors.

PR #9262 (Prefer coins that have fewer ancestors, sanity check txn before ATMP) is ready, but there’s some disagreement over the default value. Gmaxwell and instagibbs argue it should default to ‘off’. The transactions will be queued in the wallet, periodically rebroadcast and go out once they’re no longer overlimit. The default can be changed in 0.14 if it’s needed. The most important change of the PR was to avoid those poorly propagating transactions when possible, which isn’t optional. Since this causes actual problems it should be backported to 0.13.2

MarcoFalke wonders if anyone has a strong opinion on his comment in PR #9347 about the fLimitFree flag. He thinks it doesn’t matter much, but would like a second opinion.

meeting conclusion

• Merge #9322 (Don’t set unknown rpcserialversion)
• Review #9262 (Prefer coins that have fewer ancestors, sanity check txn before ATMP) disabled by default and backport to 0.13.2
• Review #9352 (Attempt reconstruction from all compact block announcements) and backport to 0.13.2

Comic relief

instagibbs      better is better
gmaxwell        sometimes better is worse, there is totally like an essay on this. :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.