IRC meeting summary for 2017-04-27

• Link to this week logs
• Meeting minutes by meetbot

Notes / short topics

• BlueMatt has a PR ready that is another step towards libconsensus. It adds a CChainState class to validation.cpp which will hold things like mapBlockIndex chainActive, etc

Main topics

• HD wallet auto-restore
• NODE_NETWORK_LIMITED
• bitcoind expiration

HD wallet auto-restore

background

Bitcoin Core has a Hierarchical Deterministic Wallet (HD wallet/BIP32) since version 0.13. A HD wallet is a system that derives all keys from a single starting point called the ‘seed’. This allows users to only back-up their wallet once and all future generated keys can be re-generated starting from the seed.

To speed up review and deployment the first version of HD wallet in Bitcoin Core was made simple without many bells and whistles. Now new features are being added to the wallet, like this HD wallet auto-restore, which ensures it always checks the keypool when synchronizing with the node and that the amount of unused keys it searches for is large enough.

meeting comments

Jonasschnelli, the author of the PR, has a few question for discussion. He’d like to know whether we should try to always restore funds, or check for the wallet’s best seen block and compare it with the newest block from the node, and only then restore. He thinks we should only restore when the best seen block lacks behind as encrypted wallets may need to unlock to generate new keys and for performance reasons. Achow101 thinks it could prompt the user when the GUI pops up if it needs to generate more keys. However, it should also work in the command line interface, which is harder to solve that way. BlueMatt proposes to stop updating the best seen block when the keypool is small enough and do a re-scan from that height when the wallet unlocks and the keypool is extended. Sipa notes the pruned nodes also need to stop pruning.

Another question is how much the gap limit in the keypool should be. Currently this is 100, but that seems too low. The current bottleneck is the derivation time, which is a problem with Berkeley DB flushing. Fixing the Berkeley DB issue would result in a massive improvement and would allow to bump the keypool to something like 1000 or 10000.

meeting conclusion

• Always scan the keypool and check if the keypool is large enough
• Extend the keypool and gap-limit to 500+
• for encrypted wallets: pause synchronization of the wallet until it’s unlocked
• for encrypted pruned nodes: pause the full node as well

NODE_NETWORK_LIMITED

background

Currently pruned nodes don’t advertise themself as having any blocks, and as a result they don’t serve any blocks to other peers. As the blockchain size continues to grow it’s likely the amount of pruned nodes will rise in the future.

Non-pruned full nodes advertise themself by NODE_NETWORK, Jonasschnelli proposes to make a message that advertise pruned nodes that relay and are able to serve the last 144 blocks (1 day worth of blocks), namely NODE_NETWORK_LIMITED.

meeting comments

Previous discussions on this subject led to the conclusion of using two service bits, for 144 blocks and ~1000 blocks.

The only thing to bikeshed about is how high we need to cutoff, as it should be at least a couple of blocks higher because of reorgs/boundary. Gmaxwell proposes to use the existing pruning minimum of 288 blocks.

Jonasschnelli thinks we should allow the current pruning peers that’ve set prune=550 (550MB, which is the minimum) to signal relay and a limited amount of blocks around the latest block (10), as this would lower the bandwidth requirements by not having to serve historical blocks. Gmaxwell notes there are other ways of limiting bandwidth and we don’t have signaling room to send out every variation of block relay. There’s also been reorgs of more than 10 blocks deep (like BIP50), so this would cause many problems if all your peers only serve 10 blocks.

meeting conclusion

• Jonasschnelli will start writing a draft spec for the two bits NODE_NETWORK_LIMITED

bitcoind expiration

background

Luke-jr proposed to let bitcoind and bitcoin-qt expire after 7-8 years of no updates. As it’s assumed that within 7 years the software will become obsolete, as softforks and maybe hardforks will render it insecure as well as exploits during that time.

It would also give a sort of certainty old nodes will end by a deadline, making any hardfork into a softfork, provided it is planned 8 years before.

meeting comments

Luke-jr clarifies it has an explicit override allowed, so if people want they can use the software beyond the expiration date.

Petertodd thinks any timeframe that’s short enough to really be useful will probably be short enough to raise political risks.

BlueMatt and Wumpus think it would be more reasonable to have the node refuse to start with an error message mentioning the flag to override it, although there’s isn’t much difference at that time scale. It would be simpler to implement and less prone to errors though.

meeting conclusion

• Discussion continued after the meeting, however no consensus was reached

High priority review

• BlueMatt suggests adding #10199 (Better fee estimates) for Morcos, who couldn’t make it to the meeting.
• Sipa likes to swap #10148 (non-atomic flushing with block replay), which needs more tests, with #10195 (Switch chainstate db and cache to per-txout model)
• CFields would like to see #10285 (refactoring) go in, which isn’t urgent, but a first in a long line towards Libevent.

Comic relief

wumpus           #topic libconsensus (BlueMatt)
BlueMatt         yes, so obviously this is all based on #771
jonasschnelli    (19 Jan 2012)
wumpus           archeology?

gmaxwell         I think in the future we'll change it to a limited set of options.
gmaxwell         Maybe all of them named after words for big in different languages, like starbucks. :P
sipa             gmaxwell: "For me a venti depruned node, please"
BlueMatt         sipa: I'm sorry, I dont speak starbucks
sipa             BlueMatt: venti is italian for 20. easy. that's obviously more than "grande" or "tall"
BlueMatt         sipa: ehh, I'll stick with my *good* coffee, thanks

wumpus           heck my nodes do nothing imporant and even I have a one-liner script that sends me a mail on crash or unexpected exit
sipa             my node does something important, and i have a 0-line script that sends me an mail on crash (= people mail me that my website stopped updating)
sipa hides
BlueMatt has a feeling sipa's approach is more common

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.