IRC meeting summary for 2016-12-22
- Link to this week logs
- Meeting minutes by meetbot not available
Notes / short topics
- Bitcoin Core 0.13.2 Release Candidate 1 is available for testing.
- Jl2012 asks people to read and maybe reply to his BIP proposal.
- It would be nice to get some BIP comments posted now that BIP2 is active. The idea behind it being to provide users with a central location to differentiate between inadvisable and recommended BIPs. More info on format and procedure can be found in the ‘BIP comments’-section.
- sipa did some more testing since last week’s meeting on the per-txout UTXO cache approach. It turned out that in the earlier benchmarks some debug code was left that resulted in a database read for every txin, which was killing performance. Now it’s around 30% faster to the initial block download. Future speedups are still expected so this will likely be worth it, which means we need to figure out how to make the migration, since this change requires a reindex.
- 0.14 features
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.
Luke-jr and jonasschnelli are working on the multiwallet project which allows running multiple wallets. Since this is an impactful change it might be too late for 0.14. An important change is #9294(Use internal HD chain for change outputs) which will make new wallets use 2 chains of keys, one for internal keys (change outputs) and one for external keys (getnewaddress). Since this change is not backwards compatible it would make sense to batch it with other wallet changes. Jonasschnelli proposes to batch it with #9298(use CHDPubKey, don’t store child priv keys in db, derive on the fly) which doesn’t save the private keys for the HD children, but derives them when needed. Something like this will be needed if we once like to support a process handling the keys like GPG agent or hardware wallet.
Jl2012 would like to see #8755 (Implement excessive sighashing protection policy with tight sighash estimation) and #8654 (Reuse sighash computations across evaluation) in 0.14.
BlueMatt likes to see the refactor work from cfields going in (#9289 (net: drop boost::thread_group)) and his own #9375 (Relay compact block messages prior to full block connection) which improves network propagation speeds greatly.
Luke-jr likes to see #7533 (sendrawtransaction: Allow the user to ignore/override specific rejections) as it’s hard to rebase and maybe #8776 (Wallet refactoring leading up to multiwallet) go into 0.14.
Gmaxwell would like to see some review on #9138 (Improve fee estimation) since there’s not enough testing infrastructure for the wallet and fee estimation, so we count on eyeballs.
- Review #9294(Use internal HD chain for change outputs) and #9298(use CHDPubKey, don’t store child priv keys in db, derive on the fly)
- Review PRs people are working for potentially 0.14
Codeshark started working on a new message type for filtered blocks that includes the path to coinbase and a partial merkle tree for the witnesses. In addition, rather than sending all the transactions as separate messages, it includes them in the same structure. He started working on this code here.
CodeShark doesn’t really like BIP37 however there’s currently not another query mechanism that doesn’t require you to download full blocks. Gmaxwell wonders whether a query like the BIP152 ‘getblocktxn’ message would cover CodeShark’s usecases. People much rather work on a query by index than to invest in a BIP37 approach which is known to be broken.
- CodeShark will look into BIP152 a bit more
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.