IRC meeting summary for 2016-12-01
Notes / short topics
- As segwit changes the format of the data from the JSON-RPC API, a pull request is made to add an option to return non-segwit serialization so users who haven’t upgraded their libraries in time can still use the RPC interface.
- JeremyRubin’s Better SigCache Implementation is ready to go in, but lacks some review.
- Main.cpp split
- vchDefaultKey in wallet
- HD restore
TheBlueMatt is working on refactoring main.cpp. This should make the code more accessible for new developers and improve code review and testing.
PR #9183 (Final Preparation for main.cpp Split) is ready to merge, it has a lot of ACKs already.
After the main split, backports can get more complicated. PRs that still need to be backported to 0.13.2 are:
- #9253 (Fix calculation of number of bound sockets to use)
- #9229 (Remove calls to getaddrinfo_a)
- #9194 (Add option to return non-segwit serialization via rpc)
- #9188 (Make orphan parent fetching ask for witnesses)
- #9239 (Disable fee estimates for 1 block target)
- #9252 (Release cs_main before calling ProcessNewBlock, or processing headers (cmpctblock handling))
- Merge #9183 (Final Preparation for main.cpp Split)
- Focus review on the “needs backport” tag
- Split main after backports are done
vchDefaultKey in wallet
vchDefaultKey is a leftover from the “default address” concept, which was removed in the ancient 0.4.0. Wumpus opened an issue concerning this behavior.
It is currently unused except for determining whether a new wallet was just created.
Sipa would like to get rid of this, however if we do that, a downgrade to an older wallet version would result in failing to rescan.
Given this is not really urgent there’s no need for hacks like dummy keys etc. 0.14 could stop relying on vchDefaultKey, but still write it, and then in 0.15 delete the vchDefaultKey and increase the minimum version to 0.14 so 0.15 wallets will never be openable with 0.13.
- Use versioning to get rid of vchDefaultKey by 0.15
Since 0.13 newly created wallets will use hierarchical deterministic key generation according to BIP32. Wallet dumps will contain the HD seed, however it’s not yet possible to import this seed.
Jonasschnelli thinks it should be a separate tool to restore HD seeds. The tool would create a new wallet.dat and run a rescan after that. The tool could interact with RPC and the UTXO set to detect the gap limits.
Wumpus proposes to first review and get the current wallet PRs merged before doing additional work. PR #9143 (Refactor ZapWalletTxes to avoid layer violations), #9256 (Fix more CWallet/CWalletDB layer violations) and #8723 (Add support for flexible BIP32/HD keypath-scheme) could use some review.
Gmaxwell thinks we should avoid adding more complexity to the HD support until the path split issue is fixed. The issue being the change output which is on the same chain as receiving keys, so you can end up giving out change keys as addresses for people to pay (hiding their payments from you) or have change show up as payments if you have wallets recovered from hd data.
Low hanging fruit is probably adding a ‘used’ marking in the keypool and increasing the default keypool for HD wallets to 1000, as the current 100 is really small.
- Review #9143 (Refactor ZapWalletTxes to avoid layer violations), #9256 (Fix more CWallet/CWalletDB layer violations) and #8723 (Add support for flexible BIP32/HD keypath-scheme)
- Focus on splitting the keypath
|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.