IRC meeting summary for 2016-11-10

• Link to this week logs
• Meeting minutes by meetbot

Main topics

• Hybrid SPV
• Multithread ProcessMessages
• 0.14

Hybrid SPV

background

Jonasschnelli is working on a pull request which adds a full block SPV mode to the wallet.

It would have 2 options: -spv and -spvonly, -spv being used to enable the user to send and receive transactions while the blockchain is still being downloaded/verified. -spvonly would not verify blocks at all.

The current limitations of the PR: - No SPV 0-conf transactions - Fallback fee for SPV transaction (as there’s no mempool/fee estimator) - It has only a simple spv re-org handing - currently incompatible with pruning

meeting comments

Jonasschnelli was wondering if this idea is worth pursuing, as he hasn’t received any conceptual ACKs.

Everone finds this a good feature. BlueMatt thinks it might not be worth the effort to include an spv-only mode, however there’s no extra cost to it as the code is needed for the hybrid mode. It would also be the only SPV-client that uses full blocks.

meeting conclusion

• Continue to work on hybrid full block SPV mode

Multithread ProcessMessages

background

Currently Bitcoin Core does message processing in a single thread. BlueMatt asks for some feedback and general concerns with multiple message processing threads.

meeting comments

BlueMatt elaborates it’s currently not as useful as most messages use cs_main, but he’d like to see the plumbing for it sooner rather than later. As example: adding multithread messaging would allow nodes to respond to getblocktxn while a block is processing, something he really wants for FIBRE-based relay networks. Wumpus adds being able to service multiple nodes at once would also be very useful, and should reduce block relaying delays.

Morcos notes it’s going to be important to do a thorough review of synchronization issues first, as issues might not be detected now because they are only accessed from the single thread.

Gmaxwell thinks making process message concurrent may create greater exposure for data races around the nodestats, so he proposes to run tests with valgrind DRD and try to be data race free.

meeting conclusion

• Work on adding multithread message processing

0.14

background

Bitcoin Core 0.14 is scheduled to be released around 2017-03-01.

meeting comments

MarcoFalke wonders what the priorities are to get into 0.14.

Splitting main.cpp is pretty much guaranteed to get in at this point.

Sdaftuar would like to see the validation speedups from JeremyRubin get in.

Jonasschnelli thinks there’s not much left for the multi-wallet support, although he’s not sure if it will be ready by 0.14. There’s a github project opened for multiwallet support.

For the network refactors Cfields is aiming to get the net.h/cpp split done next week.

Bumpfee should get some review.

The groundwork for mempool stats is made in #8501, but it has no review so far.

meeting conclusion

• prioritize review on wallet changes

Comic relief

gmaxwell      we should say hello to all the americans that missed the timezone change.
gmaxwell      and are just arriving now. :P
gmaxwell      Hi guys.
achow101      hi
petertodd     gmaxwell: canadians too :)
btcdrak       petertodd: you mean snow mexicans right?
gmaxwell      Welcome to the end of the meeting.
wumpus        yes, welcome
sipa          kthxbye
wumpus        #endmeeting
MarcoFalk_    Maybe trump drops DST

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.